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

[chris (Chris Jackson)]

HABmin shows the delete button when it doesn’t get the thing type. I don’t think it’s changed for this device type, but I did make quite a few changes to the database to fix some xml format errors (the checker wanted things in a different order!) and I also removed a few duplicates - this device at least is still in the database though…

[chris (Chris Jackson)]

Actually - please check that it’s still in the database (or provide the type/id) - I don’t see a version with the 1LZ on the end of the name…

[5iver (Scott Rushworth)]

@chris

Actually - please check that it’s still in the database (or provide the type/id) - I don’t see a version with the 1LZ on the end of the name…

If you look in the comments, I took off the -1LZ. So these would need to find a new Thing Type. Should all things be deleted and rediscovered, or were you able to find a way for the Thing Types to be updated automatically? There were some other zwave Things I needed to do this to in order to get manualy switch updates to start working again, but was saving to test if you managed to get it automagic’d it.

I’m no longer seeing the NPEs in 2.3.0.201801201844.

[chris (Chris Jackson)]

@5iver

If you look in the comments, I took off the -1LZ.

Ah, yep, I remember that now… So it’s your own fault then .

@5iver

Should all things be deleted and rediscovered

Yes.

@5iver

or were you able to find a way for the Thing Types to be updated automatically?

I haven’t looked at this - I’ve been busy over the past week. I’m not sure I would do it automatically, but I’m sure it can be done.

@5iver

I’m no longer seeing the NPEs in 2.3.0.201801201844.

NPEs? Or do you mean the compilation errors above? (either way, it sounds positive ).

[5iver (Scott Rushworth)]

@chris

NPEs? Or do you mean the compilation errors above? (either way, it sounds positive ).

Sorry… I meant the compilation error exceptions.

@chris

I’m not sure I would do it automatically, but I’m sure it can be done.

I think this would be an important feature to add so that users of the zwave binding don’t need to periodically delete and rediscover their Things to get the latest device updates, which they may not know even exist. Not to mention the time it would save for people with a lot of devices!

Or will the zwave binding be redone in the future to be more like the way the zigbee binding identifies the devices?

[chris (Chris Jackson)]

@5iver

I think this would be an important feature to add so that users of the zwave binding don’t need to periodically delete and rediscover their Things to get the latest device updates, which they may not know even exist. Not to mention the time it would save for people with a lot of devices!

Fully agreed - my only concern at the moment is if this should be something that the binding does, or if it shouldn’t be something the framework takes care of.

My thought is that ESH should add a version tag to the thing type. The UI could then do a check if the thingTypeVersion of the thing, is less than the thingTypeVersion, and if it is, then it pops up a box asking the user if they want to update… What do you think? I’m in two minds if I should just implement something simple in the binding to do this (as a bit of a hack) or put in the feature request to ESH (or both!).

@5iver

Or will the zwave binding be redone in the future to be more like the way the zigbee binding identifies the devices?

Well, that’s another discussion… .

I do plan do to something similar to what is done in the ZigBee binding for ZWave. I did actually start this a little while ago, so it’s in the pipeline… On the other hand, I also plan to make the ZigBee binding handle the definitions like the ZWave binding, so the ultimate is a Z-Fusion .

[5iver (Scott Rushworth)]

@chris

My thought is that ESH should add a version tag to the thing type. The UI could then do a check if the thingTypeVersion of the thing, is less than the thingTypeVersion, and if it is, then it pops up a box asking the user if they want to update… What do you think? I’m in two minds if I should just implement something simple in the binding to do this (as a bit of a hack) or put in the feature request to ESH (or both!).

Both. The ESH solution is needed, and not just for the zwave binding. However, an ESH change could potentially take a very long time, or be rejected entirely, so I think a quick and dirty zwave binding solution would be called for in the short-term. I suggest it be included before merging dev to master, since it removes at least one (all?) of the breaking changes.

@chris

The UI could then do a check if the thingTypeVersion of the thing, is less than the thingTypeVersion, and if it is, then it pops up a box asking the user if they want to update

Suggestion… potentially 100+ toast messages, which I may never see if I’m not in a UI, could be annoying. I think a configuration option would be needed, with three settings… Auto (requires no user input when thingTypes have an update), prompt (requires user input in UI before thingTypes are updated), and Never. Default to Auto.

[chris (Chris Jackson)]

@5iver

Both. The ESH solution is needed, and not just for the zwave binding. However, an ESH change could potentially take a very long time, or be rejected entirely, so I think a quick and dirty zwave binding solution would be called for in the short-term.

Yep - this is exactly my thinking at the moment…

@5iver

potentially 100+ toast messages, which I may never see

Maybe a popup is the wrong interface - let’s say an “upgrade icon” in the things list…

The problem with Auto is that if the channels change, then it will stop peoples system from working properly, so I’m a bit hesitant about such an option (not to say it might not be useful, but I can already see the emails coming in ).

[5iver (Scott Rushworth)]

@chris

Maybe a popup is the wrong interface - let’s say an “upgrade icon” in the things list…

The problem with Auto is that if the channels change, then it will stop peoples system from working properly

I see what you mean. Is it just channel changes that would break functionality? Maybe ESH could be smart enough to update the links for channels that are changed on Items that were created in the UI. What if the updated thingTypes would come up in the Inbox again, with a highlight of the diff? Hmm… now I question Auto too… the default should be Prompt. It would just be part of the binding upgrade flow… update jar, check UI, manually change item files as needed, accept changes.

[chris (Chris Jackson)]

@5iver

Is it just channel changes that would break functionality?

Yes - it’s really only channels that are the issue. Configuration changes doesn’t require this update as they are read from the XML every time you check the config…

@5iver

Maybe ESH could be smart enough to update the links for channels that are changed on Items that were created in the UI.

I’m not really sure how - if a channel changes type, or a channel is deleted and another added, then there’s no obvious way to realign them I think…

@5iver

What if the updated thingTypes would come up in the Inbox again, with a highlight of the diff?

That would probably be a big change in ESH as at the moment the inbox doesn’t allow entries where a thing exists…

@5iver

the default should be Prompt. It would just be part of the binding upgrade flow… update jar, check UI, manually change item files as needed, accept changes.

Yep - I think this is simplest and safest

[sihui]

@chris

Try now

I saw some unexpected behaviour during first start but after a restart and letting the network settle a bit everything is working fine (as always).

20-Jan-2018 20:02:10.853 [WARN ] [nhab.binding.zwave.discovery.ZWaveDiscoveryService] - NODE 8: Device discovery could not resolve to a thingType! 0002:0005:0003::2.51
20-Jan-2018 20:02:10.857 [WARN ] [nhab.binding.zwave.discovery.ZWaveDiscoveryService] - NODE 10: Device discovery could not resolve to a thingType! 0154:0100:0201::2.1
20-Jan-2018 20:02:10.857 [WARN ] [nhab.binding.zwave.discovery.ZWaveDiscoveryService] - NODE 26: Device discovery could not resolve to a thingType! 0060:000D:0001::1.5
20-Jan-2018 20:02:10.860 [WARN ] [nhab.binding.zwave.discovery.ZWaveDiscoveryService] - NODE 40: Device discovery could not resolve to a thingType! 010F:0501:1002::2.1
20-Jan-2018 20:02:10.862 [WARN ] [nhab.binding.zwave.discovery.ZWaveDiscoveryService] - NODE 33: Device discovery could not resolve to a thingType! 010F:0302:1000::25.25
20-Jan-2018 20:02:10.865 [WARN ] [nhab.binding.zwave.discovery.ZWaveDiscoveryService] - NODE 28: Device discovery could not resolve to a thingType! 010F:0202:1002::2.2
20-Jan-2018 20:02:10.872 [WARN ] [nhab.binding.zwave.discovery.ZWaveDiscoveryService] - NODE 4: Device discovery could not resolve to a thingType! 010F:0600:1000::25.25
20-Jan-2018 20:02:10.877 [WARN ] [nhab.binding.zwave.discovery.ZWaveDiscoveryService] - NODE 41: Device discovery could not resolve to a thingType! 010F:0600:1000::25.25
20-Jan-2018 20:02:10.882 [WARN ] [nhab.binding.zwave.discovery.ZWaveDiscoveryService] - NODE 31: Device discovery could not resolve to a thingType! 010F:0203:1000::3.2
20-Jan-2018 20:02:10.886 [WARN ] [nhab.binding.zwave.discovery.ZWaveDiscoveryService] - NODE 13: Device discovery could not resolve to a thingType! 010F:0302:1000::25.25
20-Jan-2018 20:02:10.900 [WARN ] [nhab.binding.zwave.discovery.ZWaveDiscoveryService] - NODE 23: Device discovery could not resolve to a thingType! 010F:0501:1002::2.1
20-Jan-2018 20:02:10.934 [WARN ] [nhab.binding.zwave.discovery.ZWaveDiscoveryService] - NODE 12: Device discovery could not resolve to a thingType! 010F:0302:1000::25.25
20-Jan-2018 20:02:10.939 [WARN ] [nhab.binding.zwave.discovery.ZWaveDiscoveryService] - NODE 3: Device discovery could not resolve to a thingType! 010F:0800:1001::2.6
20-Jan-2018 20:02:10.944 [WARN ] [nhab.binding.zwave.discovery.ZWaveDiscoveryService] - NODE 34: Device discovery could not resolve to a thingType! 010F:0302:1000::25.25
20-Jan-2018 20:02:10.942 [WARN ] [nhab.binding.zwave.discovery.ZWaveDiscoveryService] - NODE 32: Device discovery could not resolve to a thingType! 010F:0302:1000::25.25
20-Jan-2018 20:02:10.935 [WARN ] [nhab.binding.zwave.discovery.ZWaveDiscoveryService] - NODE 11: Device discovery could not resolve to a thingType! 010F:0302:1000::25.25
20-Jan-2018 20:02:11.133 [WARN ] [nhab.binding.zwave.discovery.ZWaveDiscoveryService] - NODE 36: Device discovery could not resolve to a thingType! 010F:0202:1002::2.2
20-Jan-2018 20:02:11.133 [WARN ] [nhab.binding.zwave.discovery.ZWaveDiscoveryService] - NODE 39: Device discovery could not resolve to a thingType! 0108:0002:000D::1.18
20-Jan-2018 20:02:11.155 [WARN ] [nhab.binding.zwave.discovery.ZWaveDiscoveryService] - NODE 37: Device discovery could not resolve to a thingType! 010F:0102:1000::3.3
20-Jan-2018 20:02:11.155 [WARN ] [nhab.binding.zwave.discovery.ZWaveDiscoveryService] - NODE 30: Device discovery could not resolve to a thingType! 010F:0203:1000::3.2

One minor issue though:

20-Jan-2018 20:50:01.669 [INFO ] [col.serialmessage.SerialApiGetInitDataMessageClass] - # Nodes = %d

The node count shows the variable, not the value …

[chris (Chris Jackson)]

@sihui

The node count shows the variable, not the value …

Thanks - I changed a few log entries to fix some static test issues so it’s possible there might be a few errors like this

[chris (Chris Jackson)]

@sihui

20-Jan-2018 20:02:10.939 [WARN ] [nhab.binding.zwave.discovery.ZWaveDiscoveryService] - NODE 3: Device discovery could not resolve to a thingType! 010F:0800:1001::2.6
20-Jan-2018 20:02:10.944 [WARN ] [nhab.binding.zwave.discovery.ZWaveDiscoveryService] - NODE 34: Device discovery could not resolve to a thingType! 010F:0302:1000::25.25

It’s unclear to me - did these sort themselves out or is there a database issue here?

[sihui]

After a restart all warnings were gone …

[jkarsten (Jörg Karsten)]

Hi Chris, i have the same problem with my “Fibaro Rollershutter 2,FGR-222”.
I have 4 and every thing show me the delete button and are grey.

I i forget … i use the zwave Binding from 20.01.18 and the release version 2.2 from Dez 17

Thank you,
Joerg

[sihui]

@jkarsten

problem with my “Fibaro Rollershutter 2,FGR-222”.

Some z-wave things: no description and no config possible in HABmin

The name was changed in the database (from FGRM222 to FGR222): delete the thing and add it again.

[jkarsten (Jörg Karsten)]

Oh sorry havent seen this.
It works … thank you!!

[jkarsten (Jörg Karsten)]

Hi,

i think i have the same problem??
Its a Fibaro Plug

Device discovery could not resolve to a thingType! 010F:0600:1000::25.25

I deleted it and readded … but now its in Habmin a unknown device too.
I deleted it again … and the xml file and readded it again. I upload the new created xml file to chris database
i use the zwave Binding from 20.01.18 and the release version 2.2 from Dez 17

I hope this was the right procedure.
Jörg

[chris (Chris Jackson)]

@jkarsten

Its a Fibaro Plug

Please take a look at this thread -:

Fibaro Wall Plug not recognized (FGWP101 Metered Wall Plug Switch)

Great idea, let me ping some known users of the Fibaro Wall Plug to get more data: Guys, could you please help solving a database issue with the Fibaro Wall Plug and provide the data Chris is asking for? @NCO @GioGio @Rob911 @adb76 @norbert_jordan @Andreh_T @ohmicha @KjetilA @arnold @dakkar Thanks a lot. If you want to use the table this is the “code”: | Data | Value | |--------|--------| | Device name | data goes here | | Device Type | data goes here | | Device Id |…

From looking at your definition, it should work fine though - I’ assuming your device is an FGWP101?

[Thomas_Oberthanner]

Hi,
After upgrading from openhab 2.1 to 2.2 the zwave binding stopped working.

[ERROR] [ding.zwave.handler.ZWaveThingHandler] - NodeID is not set in zwave:..........

my configuration:
raspberry pi 3 with openhab 2.2.0-1
zwave binding installed via paper ui: binding-zwave - 2.2.0

my zwave.things

Bridge zwave:serial_zstick:controller "ZWave Controller" [ port="/dev/ttyACM-433", controller_softreset="false", controller_master="true", controller_inclusiontimeout=60, heal_enable="true", heal_time=2, security_networkkey="xxxx"] {
	Thing nodon_softremote_00_000		node4 "Node 4"  (zwave:serial_zstick:controller) [ zwave_nodeid=4 ]
}

configuring the things via paperui is not an option, i need the manual thing configuration (remote access).
i also tried the latest org.openhab.binding.zwave-2.3.0-SNAPSHOT.jar version from the first post - but same error message.
any ideas?
Thomas