Your id’s were added recently, so you need to upgrade your zwave binding to the latest 2.5 snapshot:
Man you are good! Such a simple answer but yet so right . All working now! Fantastic.
Thanks a lot!
Just added a Neo Coolcam Powerplug, Manufacturer 0258, Type/ID 0200:1027.
It is joined in the openhab2 / z-wave network and states the data as above.
Only it’s not fully discovered ?! It says: “unknown device”.
But if I check the database online, the powerplug is in there !
- Openhab2 v 2.3
- Z-wave binding v2.3.0
What to do to fully discover the item?
Would it be possible to only upgrade the version of the z-wave binding to the abovementioned latest 2.5 snapshot ?
This Type/Id was added on January 17, therefore, it’s only in the very latest versions of the binding.
I’m not sure if the 2.5 snapshot version of the binding runs with 2.3 stable. Other will have to weigh in on that.
If you upgrade to a new version of the binding, please be aware that there are breaking changes that will require some work. See here.
Thanks for your quick response !
But … O Boy,
I already did execute the karaf command to load the z-wave 2.5 version you had in a discussion mhilbush.
It was executed but Openhab2 seems to ignore it as in PaperUI it still states z-wave binding v2.3.0…
And the Thing still not discovered…
How easy to upgrade to OpenHab v 2.4 ?
You mean this post?
In the karaf console. what do you see when you run
list -s | grep zwave
I dunno. I’ve only ever used the snapshot releases.
Note that there’s also a 2.5 Milestone 1 release.
Thanks for the reply mhilbush !
Yep, thats the command “bundle:update ….”
I had to restored a backup as after the command z-wave was no longer working and I tried updating to OpenHAB 2.4. So now I’m up and running on OpenHab v 2.3 again.
Only my new thing, the Neo Coolcam powerplug is still in status “unknown device”.
I don’t understand it though, it’s not my first NEO Coolcam device and also not the first powerplug. I’ve got quite a few (powerplug, wall switch and motion sensor) running for months now without any problem…
Updating to v2.4 seems to be quite a problem.
I think I was told the database was queried online, so updating the binding was not necessary for new things? Is that no longer the case or did I misunderstand ?
Anyway, any other ways or suggestions on how to get the NEO Coolcam Powerplug (Manufacturer 0258, Type/ID 0200:1027) working?
Nb.1. I’m running an OpenHabian (RPi) version of OpenHab.
Nb.2. This is the error message:
NODE 23: Device discovery could not resolve to a thingType! 0258:0200:1027::2.32
The database is part of the binding. They are inseparable. To the best of my knowledge, it has always been this way in OH2.
Based on my reading of posts on this forum, many people running openHABian have upgraded from 2.3 to 2.4. You might want to seek some help here on the forum. Unfortunately, I’m not of much help because I don’t run release builds.
Hey @sihui, Can a recent snapshot version of the zwave binding run on the OH 2.3 stable release?
One way or another, in order to use this device, you need to get on a very recent version of the zwave binding. That type:id was added to the binding on January 19, so you need to be running the latest snapshot zwave binding.
As far as I remember from reading a post from Chris I think that is possible. I too never run release versions, though
I think that is the key for success for @LeoVe
You pushed me to the latest snapshot (I was runneing v 2.3), that indeed was the key to success !
Had to delete all z-wave devices and have PaperUI find them again.
Now the devices are all discovered
I also aquired some of the new Neo Coolcam wall plugs with the new device ID. (type/ID 0200:1027). With the latest z-wave binding all the basic functionality works okay. I have however 2 issues:
- KWH usage sometimes reports a large negative number and some hours later it switches back:
PWR_SW_TVLR_KWH changed from -21474834.58 to -21474834.57
2019-02-11 22:24:55.621 [DEBUG] [nal.protocol.ZWaveTransactionManager] - lastTransaction null 2019-02-11 22:24:55.621 [DEBUG] [nal.protocol.ZWaveTransactionManager] - NODE 3: Application Command Request (ALIVE:DYNAMIC_VALUES) 2019-02-11 22:24:55.621 [DEBUG] [ng.zwave.internal.protocol.ZWaveNode] - NODE 3: Incoming command class COMMAND_CLASS_METER, endpoint 0 2019-02-11 22:24:55.621 [DEBUG] [ng.zwave.internal.protocol.ZWaveNode] - NODE 3: SECURITY NOT required on COMMAND_CLASS_METER 2019-02-11 22:24:55.622 [DEBUG] [tocol.commandclass.ZWaveCommandClass] - NODE 3: Received COMMAND_CLASS_METER V3 METER_REPORT 2019-02-11 22:24:55.622 [DEBUG] [.commandclass.ZWaveMeterCommandClass] - NODE 3: Meter: Type=Electric(1), Scale=kWh(0), Value=-21474766.37 2019-02-11 22:24:55.622 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 3: Got an event from Z-Wave network: ZWaveMeterValueEvent 2019-02-11 22:24:55.622 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 3: Got a value event from Z-Wave network, endpoint = 0, command class = COMMAND_CLASS_METER, value = -21474766.37 2019-02-11 22:24:55.623 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 3: Updating channel state zwave:device:cda3604b:node3:meter_kwh to -21474766.37 [DecimalType] 2019-02-11 22:24:55.623 [DEBUG] [nal.protocol.ZWaveTransactionManager] - NODE 3: Commands processed 1. 2019-02-11 22:24:55.623 [DEBUG] [nal.protocol.ZWaveTransactionManager] - NODE 3: Checking command org.openhab.binding.zwave.internal.protocol.ZWaveCommandClassPayload@344a62a6. 2019-02-11 22:24:55.623 [DEBUG] [nal.protocol.ZWaveTransactionManager] - NODE 3: Command verified org.openhab.binding.zwave.internal.protocol.ZWaveCommandClassPayload@344a62a6. 2019-02-11 22:24:55.623 [DEBUG] [nal.protocol.ZWaveTransactionManager] - NODE 3: notifyTransactionResponse TID:184 DONE 2019-02-11 22:24:55.624 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 3: Got an event from Z-Wave network: ZWaveTransactionCompletedEvent
Looks a bit like an singed/unsigned issue.
Did anyone experience this, and have any clue on how to fix it?
The other issue I encountered that the switches do not seem to react to any configuration parameter I send. Tried to switch of the lights, tried to disable the on/off button. All is ignored.
Did anyone encounter/experience this?
Same issue here, but no clue how to fix this unfortunately.
Just tested this by disabling and re-enabling the led indicator, works without any problems:
Make sure you are using HABmin to change any configuration parameters.
Also there seem to be no problem with the kwh:
2019-02-12 13:12:36.176 [vent.ItemStateChangedEvent] - Neo_PowPlug_2_kwh changed from 0.67 to 0.68 2019-02-12 22:49:00.414 [vent.ItemStateChangedEvent] - Neo_PowPlug_2_kwh changed from 0.68 to 0.69 2019-02-13 07:39:41.870 [vent.ItemStateChangedEvent] - Neo_PowPlug_2_kwh changed from 0.69 to 0.7 2019-02-13 16:20:55.350 [vent.ItemStateChangedEvent] - Neo_PowPlug_2_kwh changed from 0.7 to 0.71
Are you sure your devices have the same device/type id? 0200:1027? I’ve tried changing the config with paperUI and habmin. Both to no success. All my other devices (Qubino and aeotec) do respond correctly to config changes.
same here…No Config will be accepted and sometimes large negative values…
No, I did not check the device type and id, just the model WR01ZE …
Probably that device has a new firmware version so we need to add it as a separate device.
Please post your xml and check the command classes, association groups and configuration parameters if those are different to the existing database entry.
With the XML, you mean the node XML in /var/lib/openhab2/zwave/.xml?
I attached mine, and tried to compare them, but for me it’s not really clear what to check.
network_ca82ea18__node_7.xml (14.0 KB)
Yes, thx. Will take a deeper look at the weekend. First impression: there are a lot of changes, the new device supports security, the old one not. Also firmware version has changed.
In the meantime could you please compare the configuration parameters and associations groups from your manual to the database?
I’m not sure what to suggest here. Your device has additional command classes:
COMMAND_CLASS_SECURITY COMMAND_CLASS_SECURITY_2 COMMAND_CLASS_TRANSPORT_SERVICE COMMAND_CLASS_MULTI_CHANNEL_ASSOCIATION COMMAND_CLASS_SUPERVISION
and a firmware version of 2.32
where the existing device (at least the one I own) does have a firmware version 3.94:
Are you sure your device model name is NAS-WR01ZE?
@chris, do we probably need a database entry with firmware version
min=2.32 and firmware version
Are the main command classes, parameters and associations the same? Eg all the ones that have channels associated with them. The “management” classes that you list above don’t really matter tooo much I think - the binding will sort this out by itself.
On the other hand, it would not hurt to use a separate database entry either, it might not be required though…