So, if the setting Wake-Up-Intervall is enabled the changed parameters will be saved at the next Wake-Up-Intervall. That is the theory.
The problem is that after saving the changed parameters the new values are shown immediately in the Homey App and in Developer. So for me it’s not possible to check, for example the next day, if the changed parameters were definitely transmitted and saved after the next Wake-Up-Intervall.
Questions:
Is there a way to check if the changed parameters are definitely saved in the device?
What happens if the Z-Wave device is flagged in Developer as “Unreachable” (I mean not the route). Because even if devices are marked as “Unreachable” in Developer, they still work fine, even battery powered devices.
What happens when Homey is restarted after saving the changed parameters (without waking up the device)? Will the changed parameters still be transmitted at the next wake-up interval?
If a device is added unsecure, then it is relatively easy with raw commands, I’ll edit this post with the right raw command when I get home.
in the z-wave developer tools, there is a raw data input field, under “TOOLS”, type in NODE_ID, 0x70, 0x05, PARAMETER_NUMBER
with the z-wave log open, where you will get the result in back.
Secure it is harder, only possible by editing the app’s code, I’m not going to start on that.
Previous versions it was like this:
Unreachable means that the device in question has been given 3 times the “no ack” (no acknowledge) flag, which means it didn’t repond back (in time).
Not sure when it is reset (should happen on the next command received from the device, but practice shows this isn’t always the case), and any further conditions.
A device with the “Unreachable” flag has no further consequences for the device, in theorie the device will be ignored with commands to the device for a set amount of time (few minutes by default/or when a command is received back), but I believe Homey doesn’t use this ignore timeout.
On restart the queue will be emptied (on previous versions), this is just default behaviour of the z-wave chip.
It also happens after a set timeout (several hours), I don’t know this timeout, never been specified by Athom, it is configurable in the z-wave chip, so hard to say without answer from Athom
And I believe there is a size limitation, but I’m not sure on that one.
Do note, this almost all based on what I’ve seen in practice (up until Homey v4), and might change with every Homey update, even without being mentioned in the changelog.
There is a lot of documentation with default values, but a lot of stuff can be configured in chip firmware and not everything is taken care of by the z-wave chip but is done in Homey’s core where we aren’t allowed to look into. (NDA and stuff)
I know the general meaning of “Timeout”. But I don’t understand the meaning of “Timeout” in the context of “Changing Device Parameters without WakeUp”, sorry.
Maybe it’s just an understanding problem because English is not my native language.
Without wake-up the “change parameter” command will be put into a so called queue (z-wave calls it “mail box”) with a timestamp where the device can retrieve the command from when it wakes up, if that timestamp gets expired it will get deleted from the queue (as the queue has only a very limited amount of space, shared by all devices), or is just down right too outdated. (you might not find that outdated, several hours, but in wireless terms that is just very old, like several weeks old in our terms)
Homey’s advanced settings isn’t linked in any way or form with the z-wave chip or corresponding device(s), it just a “dumb” data file with data.
If a setting has changed from the last time it changed, a z-wave command will be created and send (or put into queue), there is no feedback (2 way communication) or smart functions being used at all with this.
Example:
With a Sensative Strips Guard with a standard wake-up interval of 24 hours, it could happen that the changed parameters are written into the “mail box”, but before the SSG wakes up (e.g. after 21 hours) the “mail box” is already emptied, right?
There is no synchronization performed at the next wake-up interval?
As far as I know, while wake-up interval data (I mean no measured values as temperature or lux…) are also send from the sensor to the gateway. Or not?
If not, this would mean that in the extended device parameters different values and settings would be displayed than are actually set in the sensor.
How do I know which values are actually set?
Btw, maybe I’m too stupid. If I enter the following raw commands:
156, 0x70, 0x05
or 156,0x70,0x05
I get the following info:
|2021-07-14T10:42:38.406Z|Command[1259] start: sendData|
| --- | --- |
|2021-07-14T10:42:38.408Z|[ProcessSendData]: To node: 156 with data: 0x7005 and txOptions: TRANSMIT_OPTION_AUTO_ROUTE,TRANSMIT_OPTION_ACK,TRANSMIT_OPTION_EXPLORE|
|2021-07-14T10:42:38.483Z|Command[1259] end: sendData|
The current parameters are not been shown.
NodeID 156 is a wall plug, so no need to wake up the device.
As i don’t know the timeout, i don’t know if the mailbox already will be invalid time wise.
Is it possible? yes.
Like I said, there is no 2 way connection with parameters and the settings inside Homey in any way.
There is also no bulk parameter send/retrieve command in V1 of parameters (99.9% of the devices use this version), so every parameter would need to be send/get individually, if you have 20 devices all with 20 or so parameters, that’s a lot of data every time a device wakes up, that won’t be good for battery life either.
There are no manufacturers that use the wake-up time to synchronize capabilities or anything else, that wastes way too much battery, sending data is about 65-70% if not more of the battery life already, even without this.
It will need to be implemented by the controller (thus Homey) to retrieve the current data, it is never send on its own, often only changed values are send by the devices, or on a relatively high interval (or combination of).
Woops I forgot that you also need to specify the parameter you want to get: NODE_ID,0x70,0x05,PARAMETER_NUMBER
well… you don’t.
wireless is wireless, that’s just one of the negatives of wireless communication, not just z-wave, you are limited on battery life, people like to have 1 year of battery life, better then 1 month.
)
