I see you had quite a busy time. 
You mean for security or stability-reasons?
Hm, maybe a dumb question, but one of my TRVs, the one with firmware 4.6, occasionally tends to spin up the valve to fully opened.
While in this state, the deivce won't accept any commands, neither local or via the driver, I always have to re-calibrate it to make it work again.
Using the prior version of your drivers, it did this every night, annoying, but it looks like now I found a pattern, seems always to go nuts at about 03:20 in the morning.
The hub's database cleanup runs at 03:15 every day, do you think there could be a connection between these 2 events?
Stability. Imagine you have some critical emergency vent in case of CO/CO2 critical level. And in 1 of 10000 it might not get started due to some multithreaded access device state corruption. (virtual example just to explain the point)
Hm.. I'd like to say "no". Sounds like a weird connection. But if I'd had such behavior I would definitely investigate it more deeply (by putting tons of logs around all the commands the go to and from the device).
Btw, driver has some attributes related to the topic
attribute "alarmBattery", "STRING" // low, empty, charging, idle
attribute "alarmCannotReachTemp", "STRING" // alarm, idle
attribute "alarmHardwareMalfunction", "STRING" // alarm, idle
attribute "alarmWindowOpened", "STRING" // alarm, idle
alarmHardwareMalfunction is triggered at:
// External sensor error 0x02
// Motor error 0x03
// Calibration error 0x04
But I didn't made actual reason parsing.
Not all of that might be available from the device with fw prior to 4.7
All of those are initiated by device and can be used in RM to send notification
Experimental drivers now have command queue logging/tracing options. It is very verbose. And may show what was sent to the device at specific time. It can be enabled for a specific device.
Will look like this
Execute commands [[delay:0, timeout:100, sessionId:-1, sessionTimeout:60000, commandString:9F0302700501], [delay:150, timeout:100, sessionId:-1, sessionTimeout:60000, commandString:9F0302700502], [delay:150, timeout:100, sessionId:-1, sessionTimeout:60000, commandString:9F0302700503]].
Commands are sent one-by-one first-in/first-out
The very first command 'delay' shows if command will be sent after some time, right now (if '0') or it was already sent ('-1') and timeout for 'Application status report' were reached (device had a chance to ask to retry; subject to remove and proceed to the next one)
There had been addad some functions to parameter 2 with v4.7, but notifications for hardware failures are being reported, I had to return my first TRV due to a hardware / tamper failure, this was during Animus Heart days, but I assume this should also work for the hub?
So I created a rule that would notify me if an event with value 3 or 4 is reported, do you think this will work?
Just installed the new experimental driver, will start debugging this night, thanks for that.
I assume the command string in the debug logs shows the CC and the executed commands?
A general observations regarding the recent and also the former non-experimental drivers:
Triggering my TRVs seems to be clogging my network again, though I added a delay of 8s between each execution.
The behaviour is the same when triggering many devices at a time, at least one won't execute at all, also other automations will be executed delayed or not all.
But I found that now the devices report changes immediately, great job.
The driver translates some fields of parameter3 and notification events into 'alarm*' attributes. 'openedwindow' and 'cannotreachtemp' (with enabled heating medium demand report) are triggered for sure. Others also should. Waiting for battery to discharge to check battery related 'alarms'
2, 3 and 4 are implemented trough hatdwaremalfunction attribute. But currently without specifying which one was the cause. I plan to improve that. Just lacking a bit of info how to extract that number from the notification report to distinguish.
Yes. But in the final encoded form. The way it goes to the z-wave transmitter. I can add unpacked form for debugging.
The command queue behavior can be tuned in terms of timings. There are set of fields for that in the code. All command have 2 timing parameters: delay and timeout. First talks for itself. Second is how much time to wait for possible application status report from the device in case it is busy and wants you to retry later. Supervised command (driver uses them to command device but not for asking reports) have also retry interval. By default driver retries command each second during minute until device gives an answer.
You can try different values.
The main goal is to avoid spamming device with different commands. But it doesn't saves from multiple driver instances spamming rf channel.
Trying to find good formulae to make it work nicely)
commandDelay = 150 // ms; wait before sending command
commandTimeout = 100 // ms; give some time for 'Application status' CC to reply
sessionDelay = 0 // ms; wait before sending command
sessionInterval = 1000 // ms; wait before resending command
sessionTimeout = 60000 // ms; some commands take up to 40 seconds to confirm in some cases
Maybe this would help, or have you already found this, yet?
Summary
https://www.google.com/url?sa=t&rct=j&q=&esrc=s&source=web&cd=&ved=2ahUKEwif_-DEtIT1AhWmQ_EDHdM5DxMQFnoECAkQAQ&url=https%3A%2F%2Fwww.silabs.com%2Fdocuments%2Flogin%2Fmiscellaneous%2FSDS13713-Notification-Command-Class.xlsx&usg=AOvVaw1aqkzUpOdmS66g0DHFzAv4
Would be convinient, but looking for the string "7105" should point me the right way?
I changed the schedule for the daily database maintainance to 00:15, hoping that spinning up the valve would not wake me up in the middel of the night, just if my theory should turn out to be right. 
You mean I could fiddle about with the code?
As for me, I would prefer not to hammer my FLiRS with commands each seconds.
So, if I understood correctly, raising the session interval would do??
Yes.
Sessions are related to supervised commands (set mode, set temp).
After sending supervised command queue goes asleep for 'sessioninterval' time. When it awakes it checks if command were confirmed. If not and 'sessionTimeout' is not zero (expired) send session command one more time, reduce remaining 'sessionTimeout' and go asleep again for 'sessioninterval' time.
Hmm.. Sorry (( This would not be easy to use for non involved person.. Will change that.
Right now it will basically show only command exchange activity if any.
As for the z-wave cc documentation, yes I'm using it. Hub API provides some local implementation. My problem is more about hub API. If I will not figure it out trough the hub API I'll make it by hand)
As always, when under observation, the problem didn't occur last night. 
Also it seems that the logs are being purged during the scheduled database cleanup, so no logs at all to view this morning.
Some time ago I've spotted that if device is spammed with commands it may start to ignore some of them randomly. Besides that z-wave capable microcontrollers seems are pretty slow (if to compare with esp32 for example) in favor of power consumption.
The idea behind using controlled command queue is targeted to throttle commands for each individual device giving it time to handle incoming data packets. And to improve stability in noisy environment. But at the same time to not to stall one device by another.
So there is a small chance it worked out) At least would be good to be))))
Maybe that's why adding a delay in RM between commands seem necessary, especially for FLiRS?
To be honest, your initial drivers for the TRVs was the most reliabale one for my purpose, sorry, no offense, I really appriciate your work, but since queueing was implemented, my networks gets stuck again.
As a cross-check, I re-installed the built-in drivers and network was happy again.
Those driver have other problems, though.
No problem)
I'll just make 2 versions then. A simple pass through driver and command queue based.
Thanks for testing) It helps to see wider picture)
Is basic version OK now? Or there are some issues also?
Glad if I could help.
Just reverted to the basic drivers and played around with my rules, looks good so far, thanks.
Kept the expermintal driver for debugging my bedroom TRV, hoping some error would show up.
But btt, did you get your SS7 to report changes reliably?
Mine still won't, tried several different driver like NeoCoolcam, SS6, also another promising universal community driver, no dice.
Well.. I'm kinda on the opposite side with it. I can't yet get it miss any reports. You seem to have quite some devices while I have only few. So I suspect it might be related to how strongly z-wave network is busy with communications.
Btw, it made me curious how HUB sends commands it self. Pass-trough drivers simply ask HUB to send commands with delays. Commands with delays represent a list of command+delay+command+delay+..+command actions passed to HUB like "here is a list, send it please". I don't know if those delays are basically affecting how rf-modules sends commands globally/directly. If so and delays affect all devices, it may explain connection between big network being busy/clogged with more complex approach but work way better with simpler approach. It would simply mean that those delays add some radio silence periods for other devices to respond. Food for brain)))
Weird. My Qubino Smart Plugs are doing a great job, when doing a laundry they became really chatty, and the notification when done never failed so far.
I can tell I have been very cautious regarding Z-Wave traffic, scheduled reports only once per hour, thresholds for reporting are also set in a reasonable manner, at least I think so.
Also the one SS7 connetced as the only Z-Wave device to my retired Animus which is now located at my girlfriends` shows exactly the same behaviour. 
It it helps, here's an Animus debug log from my SS7.
In my amateurish way of thinking I assume it can't be much different, since both manufacturers are Z-Wave certified. Or am I doing wrong?
So, watch me doing a refresh against an SS7.
Summary
If you like some brainfood, I assume that for a programmer, the SiLabs specs should be easier to understand, I had a hard time draining some understandable information out of them.
Thanks for the log. It's pretty interesting)
The good thing is that commands request acknowledge (mentioned in the spec)
At the same time I see few picky details:
First is that reply took 2 seconds. Status reports are pretty simple. They have no need on some super complex actions. Yet still something happens. Something takes time (device internal logic? negotiation level protocol? something else?)
Second thing is more about timing of sent commands. In the driver commands are arranged with 500 ms delay (or so). It means that 10 commands should have been eat few seconds. But were sent all together (during the very same second; why?).
Interesting. Really interesting))
If you liked this log, here's another more "interactive" motion-to-lighting one.
I was trying to narrow down an issue with (guess?)... SS7, which occasionally, when switch was on turned power off/on in a rapid succession.
I suspected a Fibaro MS (nodeID 21) as root cause.
Summary
In this case it took 4 seconds until SS7 returned it's power state.
Also you can find it sending a metering report, but this made never made it's way to the GUI.
While taking this log my network was rather small, but what seems to take time is the communication of S0-included devices.
Also now I remeber that the Fibaro sensors tended to clog the network, too, when motion, illuminance and temperature sensors are enabled.
But as a single purpose sensor they are doing a great job.
Hm, who knows how this is handled by the hub?
Is this a protocol or a driver or an API- thing?
I really miss such a debuging terminal for HE, would probably spare much time with fiddling about and re-including devices.
Just updated drivers. No behavioral changes (at least nothing worth to mention). Common code it moved to the external libraries. 'Experimental' drivers removed.
ge4d / hubitat-code — Bitbucket
To avoid difficulties while downloading I recommend to download bundle (a zip file in the repo in hubitat-native format/structure)
https://bitbucket.org/ge4d/hubitat-code/src/main/Bundles/Bundle1.zip
P.S:
Few new devices are added. They duplicate drivers already made by hubitat team (but expose more of device functionality and options)
1 Like
New driver update.
Added ability to ptotect button from manual control (local protection)
Added ability to change button color:
SS7 has separate color configurations for different states (On/Off, Day/Night).
Requires LED to be configured to 'On/Off' or 'Night light" modes. If LED mode is set
to disabled color command will be rejected (consistent with the device manual)
With the help of Rule Machine or custom app it is possible now to use LED to change color for example according to power consumption or some timer (indicatin remaining time). Corresponding command accepts '[hue: <my_hue 0..100>, saturation: <my_saturation 0..100>, value: <my_brightness 0..100>]'
P.S.: Fibaro TRV also got Knob Lock/Unlock function
