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

security
zwave
Tags: #<Tag:0x00007fd31170f3c8> #<Tag:0x00007fd31170f238>

(Chris Jackson) #3136

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


(borcon) #3137

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.


(Chris Jackson) #3138

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


(Chris Jackson) #3139

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.


(borcon) #3140

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.


(Chris Jackson) #3141

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.


(Harry More) #3142

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:


(Chris Jackson) #3143

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.


(Leo Siepel) #3144

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


(Chris Jackson) #3145

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…


(Mark) #3146

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


(Chris Jackson) #3147

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.


(Mark) #3148

That makes sense. OTOH, you can hard reset your controller, which is an operation not to be taken lightly. :worried:

I wrote a little shell script that sends {"action_reinit":true} to the REST endpoint for node configuration, so I have a way to do it when needed. :+1:


(Chris Jackson) #3149

True, but “hard reset” is something that most people probably understand is going to have significant consequences :wink: .

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.


(Mark) #3150

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


(Chris Jackson) #3151

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

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.


(Mark) #3152

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

Let me know if you want a log.


(Chris Jackson) #3153

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 :wink: . If want to provide one, I’ll be happy to take a look.

Thanks for the feedback.


(Mark) #3154

Sent email with log file.


(Chris Jackson) #3155

Got it - thanks.