I do have 2 boxes, from 2 manufacturers, of European z-wave devices that will be getting some love in 2.2.5.
2 Likes
Thanks! I think that these devices defintily deserve some love. 
Have a spare one of them that is not in use by any rule, so I took a heart and tried this driver with it, unfortunately it won't work at all.
As I have been having problems getting this device to work properly I just compared the specs for version 6 and 7 - and they are quite different.
Have a look here under Configuration Parameters:
Version 6
http://manuals-backend.z-wave.info/make.php?lang=en&sku=AEOEZW096-EU&cert=ZC10-15080004
Version 7
http://manuals-backend.z-wave.info/make.php?lang=en&sku=AEOEZW175&cert=ZC10-19066544&type=mini
Yeah, I already had a really close look at the manuals.
You can use the "Basic Z-Wave Tool" to set the parameters and then revert to the Smart Switch 6 drivers.
Works somehow, but reporting according to the thresholds you set seems to be a lottery.
What is the "Basic Z-wave tool" and how do I use it on Aeotec Smart Switch 7 to set parameters?
I have tried to set parameters today and it doesn't seem to happen anything........the parameters seem to stay the same (the power reporting interval stay the same for sure).
I'm pretty this has worked in the past though.
Look here:
You will find a short manual at entry #108.
I don't think that the parameters of Smart Switch 6 and 7 match, so better use this tool.
+1 on the giving love part to the Aeotec Smart Switch 7 EU version, any update on this as I have not seen it in 2.2.7?
1 Like
I've made custom driver for F-plug version for my self. Don't hit me too hard))
It has suboptimal code. (Sorry, I'm mainly c++ programmer. And I'm new to hubitat development environment and groovy). There are some things that I feel can be improved. Besides that the driver lack ability to assign additional z-wave listeners (besides hub itself there are 4 empty slots in the lifeline event group for direct reporting to other z-wzve devices)
Here is the link to get it (updated version with some fixes and color-based parameter groups) https://www.codepile.net/pile/VQXZ2An0
Device internal clock is not battery powered. So after power down it might needs to be reconfigured with 'ValidateClock' or 'Poll' (does both validates clock and reads meter). I'm still thinking on how to handle that better. Ideally some 'onBoot' event from device at power restoration would be cool to have. Internal clock is used only for LED night mode.
1 Like
This is the love the Smart Switch deserves, nice and clear looking drivers, thank you! 
Though there seems to be no driver that lets these devices report value changes according to parameter 91-93.
Finding the drivers for the Fibaro Heat Controller in your repository was really a nice surprise.
Work great with firmware 4.5 and 4.6, too and finally, I can use the TRVs the way I want to.
Also the external sensor battery indicator is what I missed for a long time, Cudos!
I suggest to announce them to the folks in this forum.
The Fibaro TRV driver is not complete yet. (And some changes will be done backward to the SS7 right after). From what I can see the TRV is not reporting most of it's status by itself. So I plan to add configurable polling inside the driver. And I'm moving sensor's battery to a child device (to be able to show it on dashboard)
Also sometimes TRV ignores/skips commands. So I want to implement internal command queue with per-command timeouts and better command acknowledgments (to ensure command acception and execution when possible). Sometime that also may happen to SS7 (while significantly less often), So it is a subject to get those changes too. But I need some time to do that) I just can't spent much in a row:)
As for alarm reaction - it is z-wave level functionality. To get use of it sensors need a way to register SS7 as subscriber. Right now SS7 can register 'child' devices to the retransmit group (up 5 of them). So when you send command to the main SS7 subscribers will get it also without HUB actions needed. So you can make SS7-to-SS7 propagation chain.
Regarding parameters 91-93 (green colored group). I didn't tested that in depth. But it seem to work. Do you have any issues with them? Just to be in sync I have two identical SS7F with firmware 1.02
- protocolVersion: 6.04
- hardwareVersion: 175
- firmwareVersion: 1.02
As for me, I tend to be very careful with polling FLiRS-devices.
But a child device for the sensor sounds tempting, would be nice for battery notifications, too.
This is what I found, too, sometimes they can be very stubborn.
Just take your time.
You mean group association? There's a a community tool for that.
I actually have, never got these switches to report changes reliably, regardless which driver I used.
Also including with no security instead of S2 didn't help.
Since this problem also exists with Home Assistant and Animus Heart I feel this could be a general issue.
I have 3 of them, all the same version as your's.
I've made a bit of local observation about reports. I turned off timed report and sat amperage report to minimal 100mA. When I hear my electric pots relay turned on/off I see amperage and power reports. It is still a question how precisely it measures threshold as few reports were with difference around 30mA. But I can accept accuracy with around 5% deviation range (that would be 500mA in this specific case). I guess even 10% can be (while I can't say I would like it)))
Could you describe your use case?
The SS7 is paired without security and has a direct route to the hub.
I wanted to use it for a notification rule when laundry is ready, but it won't even report changes as high as 1000W, so now it's only purpose is to turn off all my TV-stuff when going to bed.
I have set parameters 91 and 93 to 1.
Turning my AV-Receiver, which drains about 40W, on or off won't issue any report.
According to Aeotec support the switch performs a threshold check once every 5 seconds, but I always have to refresh the device to see the changes.
When turning SS7 on or off, it is reporting the current values.
Timed reportings work, though.
Interesting. Made me curious if threshold may work a bit differently from what we expect 
. Like a level that device checks to be above or below. A threshold crossing event. Will try to play a bit with it later. I doubt it is the case. But who knows
One more thought.. I don't know what type of machine you have. There might be also inductive load type from the motor that may in some cases confuse AC measurement. But it is only a guess. My thermopot is a purely active load (no capacitance or inductance like motors).
Btw. I updated TRV driver. But it also needs a VirtualBatteryPoweredDevice driver to spawn sensor device. (Spawns/removes on 'Refresh' depending on device pairing status). Can't check values for correctness yet as both my batteries are full 
Thanks, looks good, my sensor's values are the same as yesterday, so I take them as accurate. 
Who knows?
Just reviewed the ticket I opened for Aeotec support 2 years ago, the guy sent me a Zniffer log that shows that reporting works for him using a Z-Stick.
Using Animus Heart these days, I started a debugging console and found out, that SS7 didn't send any unsolicited reports, neither timed or by threshold when paired with S2 security.
Paired with S0 or no security, I was able to see meter CC reports, but somehow they had never been processed by the gateway, but this might be a different story.
Also removing the device's association group 1 from the controller and re-adding it didn't help.
Think I tried everything possible, re-including, factory resets of the SS7 and even of the gateway, etc...
Hm, sounds plausible, but 3 devices in 3 different locations that behave exactly the same with different gateways?
Ok, one is plugged directly to a small UPS, which may interfere somehow, but the others are not placed close to a magnetic field. 
I'm using both SS7 in S2 mode.
This is weird.
The only difference I could think is the mains-voltage, how high is your's?
The nominal value here is 230V, but mostly my energy provider delivers more, up to 240V.
According to the specs SS7 should work with an input-voltage up to 250V.
On my side 220v is the official voltage. But in reality it fluctuates around 230
I've played a bit with in-driver command queue. First impressions a pretty promising. First of all I was able to remove most of the command delays making device-driver interaction more responsive. And command loss rate is still lower than was before. All test it some more and apply changes to SS7 driver also.
Idea is pretty simple. But HUBs language adds some difficulties to implementation. It's kinda weird that in the late 2021 I can't declare custom classes inside driver code to make it more readable and better organized.
So the queue takes all commands and dispatches them one by one. If device returns 'Application status' "device is busy" command is resent with either fixed or returned timeout if available. And there is some timeout for the device to have some time to respond in such cases. But it is time smaller then before. 100ms. Actuator-style commands are wrapped with supervision encapsulation. They are awaited up 60s with 500ms re-tries. Values are configurable. And there is a possibility go beyond that and re-encapsulate important commands with new session ID if there were no response after 60s of waiting. It might help with some z-wave locks that cause troubles to some people.
In general such logic is something that can be actually implemented one or more layers closer to hardware (as it is pretty generic thing). Scripted implementation looks not the best way to provide it. I bet HUB has some internal z-wave scheduling. But doesn't seem to make use of such CCs when available (in contrary to S2 encapsulation function)
