#Hi, if anyone has a few minutes, I'd

1 messages · Page 1 of 1 (latest)

wispy cedar
#

WDYM by too much activity?

#

I see both getting controlled and then the state validated (polled). The only odd thing is that they then also send a Hail, causing another poll.

stiff garnet
#

i guess my reason to look at it is that it seems noisy

2023-11-20 14:38:11.130 INFO Z-WAVE: [Node 057] Value updated: 38-0-targetValue 30 => 30
2023-11-20 14:38:11.134 INFO Z-WAVE: [Node 057] Value updated: 38-0-duration 0s => 0s
2023-11-20 14:38:11.137 INFO Z-WAVE: [Node 057] Value updated: 38-0-currentValue 30 => 30
2023-11-20 14:38:11.175 INFO Z-WAVE: [Node 057] Value updated: 38-0-targetValue 30 => 98
2023-11-20 14:38:11.178 INFO Z-WAVE: [Node 057] Value updated: 38-0-currentValue 30 => 98
2023-11-20 14:38:11.247 INFO Z-WAVE: [Node 057] Value updated: 38-0-targetValue 98 => 85
2023-11-20 14:38:11.250 INFO Z-WAVE: [Node 057] Value updated: 38-0-duration 0s => 0s
2023-11-20 14:38:11.252 INFO Z-WAVE: [Node 057] Value updated: 38-0-currentValue 98 => 85
#

and some of these things seem to be doing nothing?

magic crystal
#

what's noisy about it?

#

If you're concerned about network-level commands, you should be looking at the driver logs, not ZUI. Use debug level too, not silly, which is noisy.

stiff garnet
#

ok, that's really the primary concern.

used that because github says to use silly

magic crystal
stiff garnet
#

damn it, did the inverse

magic crystal
#

I don't know what silly ZUI logs even do.

stiff garnet
#

maybe i just wrote it wrong above

magic crystal
#

There can be multiple value updates for a single z-wave report, so seeing targetValue, currentValue and duration all at the same time is normal.

stiff garnet
#

ah, ok. thanks.

magic crystal
#

Also when you set brightness (targetValue), a fake currentValue is returned, e.g. the setting of targetValue from 30 -> 98 causes a fake currentValue 30 -> 98, then the node reports one later with 85.

stiff garnet
#

just trying to tame it a bit. for example, i have an alert that flashes my lights if on: off-on-off-on. it's set to 1 second intervals, but often takes much longer to actually change. 3+ seconds just by my estimation.

magic crystal
#

yeah, I doubt that's going to work well.

stiff garnet
#

is that too fast?

#

of course, similar things happen with my light groups

magic crystal
#

probably depends on the network in general.

#

but it could be

#

how many lights would that be?

stiff garnet
#

2 and 3 per group

#

less pronounced though

#

sometimes i'll have to hit the switch again to get them all to listen

#

but the next thing you're gonna say is probably "prove it with logs" 😅

#

just trying to get a better understanding of best practices to make it feel a little better.

#

do these symptoms get more pronounced as network size increases?

wispy cedar
# stiff garnet just trying to tame it a bit. for example, i have an alert that flashes my light...

but often takes much longer to actually change. 3+ seconds just by my estimation.
Hard to see right now if there is a delay. That said, I have done similar things during testing where I turned a switch on and off a few times in a 100ms interval or so.

It can work, but not if there's a command to a different device being sent that takes 1+ seconds (because of FLiRS):

2023-11-20T14:38:09.726Z DRIVER » [Node 043] [REQ] [SendData]
                                  │ transmit options: 0x25
                                  │ callback id:      28
                                  └─[ThermostatSetpointCCSet]
                                      setpoint type: Heating
                                      value:         62 °F
...
2023-11-20T14:38:10.963Z DRIVER « [REQ] [SendData]
                                    callback id:            28
                                    transmit status:        OK, took 1230 ms
                                    routing attempts:       4
                                    protocol & route speed: Z-Wave, 40 kbit/s
                                    routing scheme:         LWR
                                    ACK RSSI:               -77 dBm
                                    ACK channel no.:        1
                                    TX channel no.:         1
                                    beam:                   1000 ms
#

that's immediately before the SET to 98, so maybe you were experiencing that delay

stiff garnet
#

this is actually not a great chunk of log for the delay.

flirs devices would be things like my tstats, correct?

#

some of them, anyway. can't power them all with AC