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

security
zwave
Tags: #<Tag:0x00007f1826527160> #<Tag:0x00007f1826526f08>

(Chris Jackson) #2391

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 Jackson) #2392

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…


(Scott Rushworth) #2393

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 Jackson) #2394

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

Yes.

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.

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


(Scott Rushworth) #2395

Sorry… I meant the compilation error exceptions.

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 Jackson) #2396

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

Well, that’s another discussion… :wink: .

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


(Scott Rushworth) #2397

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.

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 Jackson) #2398

Yep - this is exactly my thinking at the moment…

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


(Scott Rushworth) #2399

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 Jackson) #2400

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…

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…

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

Yep - I think this is simplest and safest :wink:


(SiHui) #2401

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 Jackson) #2402

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


(Chris Jackson) #2403

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


(SiHui) #2404

After a restart all warnings were gone …


(Jörg Karsten) #2405

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.
fibaro roller shutterUnbenannt

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) #2406

No thing configuration settings Fibaro FGR222
(Jörg Karsten) #2407

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


(Jörg Karsten) #2408

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 Jackson) #2409

Please take a look at this thread -:

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


(Thomas Oberthanner) #2410

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