OH2 Z-Wave refactoring and testing... and SECURITY

Thank you @sihui. After I updated to newest snapshot I could install dev version of the binding and I’m running the 201807032158 version ATM, and I have 2 remarks and 1 question:

  1. The binding doesn’t seem to receive a scene numbers from Fibaro buttons however - not in the events.log at least ( parameter 1 in configuration is set to 127 - all scene IDs should be sent).
    Keyfob (also Fibaro) works straight ahead as it used to.
    It’s not a big deal for me because I managed to use associations for all I needed, but I thought it’s better to mention in case it’s important. (@chris you’re awesome btw :slight_smile: )

  2. Aside from that 6 of my 7 Fibaro door sensors changed their channels from sensor_door to sensor_binary, which required some reconfiguration.

  3. All my Danfoss thermostats configure well, but they all display E5 after a while, which seems to be a communication problem. Habmin however doesn’t seem to notice that. 2 or 3 of 6 altogether are being initialised. I can’t say if they work now, as it’s summer where I live and the heating is turned off elsewhere. Is there something I can / I should do about it?

openHAB 2.4.0 Build #1307

If there’s “build #” on the bottom of the screen, does it mean it’s SNAPSHOT? I have an OpenHABian running elswere and it says “Release Build” - does it mean STABLE?

I don’t have one but I guess it should work like all other Fibaro devices:
link a Number item to the scene_number channel and catch it in a rule like Item FibButton_Scene received update XX

Yes.

Yes.

I recall recently someone else mentioned that their system was not polling, and there were no “channel linked” messages in the log. Maybe there’s an ESH bug that sometimes doesn’t notify the binding that a channel is linked?

Yeah, I was thinking the same thing. Something that occurs on startup. Maybe a dependency issue, or a race condition… I looked through the recent ESH commits to see if something changed recently – no luck.

From your log I don’t see any problem in the binding. It seems that you have removed the association -:

This will stop the device reporting.

There were several door sensors that were all cleaned up in the database. This involved changing some of their channels.

These changes also included adding the external switch. Great for use as a leak sensor, or with a pressure sensitive mat, or with a relay to make a dumb device smart, etc.

(Fibaro buttons)
Well it did before but, unless I’m doing something wrong, it does not any more. The scene IDs used to show up in the events.log just like the scene IDs of the keyfob did. Now, keyfob’s scene IDs do still show up, buttons’ scene IDs don’t. I haven’t check if the scenes would work though. Once I’ve noticed no reaction in the events.log, I just made the associations. As a side effect I hope it to be more reliable, as there will be no need to pass through the controller but they will talk directly to associated devices instead.

Is anybody aware of changes in Danfoss thermostats? Why do they keep displaying Error 5 * while the binding says all is fine? They did work surprisingly well before (some users found them unreliable or sluggish but I had no problems). Now they not seem to know which temperature they are set to… Any hints?

* E5 = “The thermostat is not receiving the expected replies from the control system”

Have you deleted and rediscovered your zwave Things after updating?

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).

I didn’t remove the assosciation. I definitly changed only the Location in the paperui. But all settings are sent.
So maybe here is the problem.

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 :blush:
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 :slight_smile: )

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 :sunglasses: I also do really hope the associations will make it more reliable :slight_smile:
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 :wink: )
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 :thinking:

For reference, it’s this.

For reference, it’s this.

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 :confused: .

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 :frowning: . 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.

@hoomee https://github.com/openhab/org.openhab.ui.habmin/issues/279 Maybe it’s good to know that paperUI deals with the associations as intended.
@Chris, do you know why habmin is no longer developed? Is it a project choice in favor of paperUI or is it a lack of interested developers?

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.

If only there were more hours in the day…

@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.

1 Like

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 :wink: ) 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.