I’m guessing that this is a configuration issue of the device if it’s not sending the data. I don’t know the device, and haven’t looked at the configuration to try and work out how it works, but if it’s not sending data then it’s not likely to be a binding issue directly at least.
What devices are these exactly? There are 4 Fibaro door sensors in the database. I looked at the first, and it defines both channels - to work out what’s happening, we’d need to know what version you have.
I don’t know what causes this. I know it means the device hasn’t communicated with the controller, but I don’t know exactly what triggers it. If someone knows, then we can look at it (I do recall some disucssion on this in the past, but I forget the outcome).
From the log, the association was removed. The binding doesn’t do this unless requested from the UI - it doesn’t just send configuration for no reason. Either it comes from the UI, or it is initialised during the initial configuration of the device (which isn’t the case here I believe).
I tried to check the log you sent, but it doesn’t have enough information as the first entry is the command to set the association group - we’d need to see what happens before the command is sent.
What do you mean with “we’d need to see what happens before the command is sent”?
There was only the inclusion process first. After inclusion, the lifeline was ok. Change the location in paperui was the second step which removed the lifeline. I could set the lifeline in paperui and it does work, but if i change any wall plug setting again in paperui, the lifeline is removed again. The zwave binding needs a restart and then i can set the lifeline again.
If i edit the fibaro wall plug, the group 1 in paperui is always empty.
Something triggered the command - it didn’t just send by itself. The very first entry in your log is the sending of the command - to work out why it was sent, we have to see earlier in the log.
Yes - so we need to see what happened here - this is my point.
Ok, so here is where the association was removed then - I think this fully explains why the association is removed at least.
Disclaimer: Sorry for the long post. I don’t mean to waste your time
I’m happy with how the buttons and door sensors work now and write the following only as, let’s say, status quo. The only thing that bothers me are those Danfoss thermostats, so I’ll try to dig deeper into it (on the forum )
I’m not sure if you’re asking me, but I have. I also removed all the xml files in zwave folder.
Fibaro buttons
That’s what I would think, so I checked the configuration several times.
It’s not depending on secure vs. non-secure communication, is it?
I did not change the inclusion way, so I assume it’s “non-secure” by default (the habmin says it’s non-secure).
Parameter 1 (Scenes sent to the controller) says:
Available settings: 1 - Key Pressed 1 time
2 - Key Pressed 2 times
4 - Key Pressed 3 times
8 - Key Pressed 4 times
16 - Key Pressed 5 times
32 - Key Held Down
64 - Key Released
Default setting: 127 (all)
It was set to 127 (default), I changed it to 63 to no avail. It’s not sending scene IDs.
I was actually rather disappointed with the buttons and their scenes anyway, so it’s not something that bothers me much I also do really hope the associations will make it more reliable
I just wanted to mention it as it has changed (it used to send/receive those IDs) and in case someone’s stuck on it in the future.
Fibaro DOOR / WINDOW SENSOR FGK-10x-EN-A-v1.00 & FGK-10x-EN-A-v1.01
They are all definitely version 1 (the one without temperature sensor, not easy to wake-up )
Here is the first one (the one that has not changed and has still sensor_door channel):
> Manufacturer 010f Fibargroup
> Type / ID 0700:1000
> Firmware version 2.1
and its 9 channels: sensor_door, battery-level, alarm_flood, alarm_co, alarm_smoke, alarm_co2, alarm_general, alarm_heat, sensor_temperature2
The others (those with sensor_binary):
> Manufacturer 010f Fibargroup
> Type / ID 0700:1000
> Firmware version 2.5
have only 3 (three) channels: sensor_binary, battery-level, alarm_smoke
They’re just there to report doors/windows open/closed and they work fine after I changed items from "contact" to "switch".
@chris
I’ve read someone mentioning there is some inconsistency in what habmin/binding reports and the real state of the controller, when you said the binding shows only what the controller says. Well, I’ve noticed that sometimes some devices show no active channel in the habmin interface, but those channels are active for sure (and/or there’s no reason they wouldn’t). Refreshing habmin after a while helps.
Also, there are disappearing associations at least in habmin interface, which - I know for sure, do still exist in the network (device?/controller?). The buttons associated to some switches and dimmers work fine despite no associations being shown in habmin or paperUI. I have no clue where’s the culprit
This appears to be a new device, updated for the new firmware (I assume).
Regarding the FGPB -:
I don’t know what changed, but it’s not the binding. If the device is sending something different, then this must be a configuration issue. The binding doesn’t set any configuration in devices automatically other than associations and wakeup. The last change to the FGPB was well over a year ago and even that was only to update some parameters - not channels (that was May 2017). So, I’m not really sure what has changed, but I don’t think it’s linked to the binding .
I don’t know what you refer to here. The controller maintains no state - it just passes the data through to the binding, and the binding can only show the information it is passed.
There is a problem with the widget used in HABmin - unfortunately I can’t fix this as it’s a 3rd party widget that is no longer supported . It causes some associations not to be displayed. There’s an open issue on this, but without significant work I can’t see a way to resolve this.
It is simply availability of my time - you talk of “developers” - unfortunately, the only developer is me, and I also have quite a lot of other things to work on.
@chris What was the rationale for allowing reinitialization only if initialization has completed? It seems like there are cases (such as when troubleshooting an issue with a device) when it would be helpful to reinitialize a device that has not completed initialization.
I wanted to stop people continually reinitialising a device. Eg they think something is wrong, so they reinitialise, and then again, and it never finishes initialisation. This is especially a problem for battery devices which may take a long time to initialise - if people reinitialise without understanding this, then it can cause more problems.
Often the people active on the forum here have a reasonable (or better ) understanding of how things work, but there are a LOT more people with less understanding about some of this, and I wanted to try and avoid such issues.
I agree - there re times when it would be good ti restart the initialisation, so maybe the above isn’t a good idea in all (or any?) instances, but that was the rationale.
True, but “hard reset” is something that most people probably understand is going to have significant consequences .
As with anything, there’s a balance. Generally this is something that shouldn’t be needed, but I could look to change this so that reinitialisation is available as an advanced and critical function.
No worries. As long as there is no technical reason why a node can’t be reinitialized while initialization is in progress, I’m fine using my handy shell script.
I’ve created a test binding here with a couple of experimental changes -:
I’ve added a 200ms delay if the controller returns certain errors. Currently the binding just fires off a retry and we get the same error. Given that the main cause of this error is the controller being busy, resending in 1ms just results in the same response
I now don’t treat some error responses in the DEAD node assessment. Anything linked to the controller is not considered (eg all the heal functions).
@digitaldan and @5iver you might like to try - most of this comes from the assessment of your logs (thanks ).
This version also changes the queuing to ensure the FIFO is respected. I noticed in a log tonight from @borcon that under certain circumstances queued packets can get out of sync which can cause things to not work as expected!
I’ve not been able to test this properly as I don’t see some of the issues I see in other logs, so any feedback welcome.
After loading this version of the binding, I saw several (5 or 6) cases where the controller rejected the command. In all cases, the command was successful on the 2nd or 3rd retry (mostly the 3rd retry).
I also observed a much smaller number of offline nodes (around 3, where in the past I would see a dozen or more).
That’s definitely an improvement - I think in the logs I’ve seen from others, all 3 attempts get rejected as they were sent within a few milliseconds of each other…
Maybe there’s an argument that 200ms isn’t enough…
Why not . If want to provide one, I’ll be happy to take a look.
)
I also do really hope the associations will make it more reliable 
)
.
. It causes some associations not to be displayed. There’s an open issue on this, but without significant work I can’t see a way to resolve this.
).