1.83 -> 2.0.0~b5 upgrade and unknown zwave devices

anon83483981 · January 18, 2017, 9:58am

Hi,

I’ve just upgraded today from 1.8.3 to the Ubuntu package for 2.0.0~b5. It’s gone semi-smoothly, a bunch of stuff still doesn’t work (like most of my zwave devices, until I bind them to the right channel, but all my items aren’t showing up so I can’t seem to do that).

Anyway, some zwave devices (mostly single relay switches) are all showing up as unknown devices. I’ve tried removing them, and adding again (using PaperUI) but they just are added again as unknown.

Strangely, some information has been populated, like below:

I’m using the OH2 zwave addon.

Can anyone suggest what I might do to fix this?

The other issue, is that a certain .item file is causing 500 errors. The error from my browser, which shows up mostly when browsing items, is:

And the item file itself is below. It only occurs when the item file is in place - if I remove it, no errors.

Group   Security
Group:Contact:AND(CLOSED,OPEN)  Doors   "Doors [(%d)]"  <door>  (Security)
Group:Contact:AND(CLOSED,OPEN)  DoorsExternal   "External Doors [MAP(doorsExternal.map):%d]"    <door>  (Doors)

Contact Door_DeckDoor   "Deck door [%s]"    <door>  (DoorsExternal)     { zwave="2:command=SWITCH_BINARY,respond_to_basic=TRUE" }
Number  Sensor_DeckDoorBattery  "Deck door [%.0f %%]"   <battery_full>  (SensorBattery100)      { zwave="2:command=BATTERY" }
Contact Door_FrontDoor  "Front door [%s]"   <door>  (DoorsExternal)     { zwave="18:command=SWITCH_BINARY,respond_to_basic=TRUE" }
Number  Sensor_FrontDoorBattery "Front door [%.0f %%]"  <battery_full>  (SensorBattery100)      { zwave="18:command=BATTERY" }
Contact Door_DownstairsDoor "Downstairs door [%s]"  <door>  (DoorsExternal)     { zwave="41:command=SWITCH_BINARY,respond_to_basic=TRUE" }
Number  Sensor_DownstairsDoorBattery    "Downstairs door [%.0f %%]" <battery_full>  (SensorBattery100)      { zwave="41:command=BATTERY" }
Contact Door_CourtyardDoor  "Courtyard door [%s]"   <door>  (DoorsExternal)     { zwave="5:command=SWITCH_BINARY,respond_to_basic=TRUE" }
Number  Sensor_CourtyardDoorBattery "Courtyard door [%.0f %%]"  <battery_full>  (SensorBattery100)      { zwave="5:command=BATTERY" }
Contact Door_LaundryDoor    "Laundry door [%s]" <door>  (DoorsExternal)     { zwave="21:command=SWITCH_BINARY,respond_to_basic=TRUE" }
Number  Sensor_LaundryDoorBattery   "Laundry door [%.0f %%]"    <battery_full>  (SensorBattery100)      { zwave="21:command=BATTERY" }
Switch  garageDoor_Opener   "plug"  (lights2)       { mqtt=">[mosquitto:home/garage/in/0:command:ON:1],>[mosquitto:home/garage/in/0:command:OFF:0]" }
Number  garageDoor  "Garage [MAP(contact.map):%s]"  { mqtt="<[mosquitto:home/garage/out/0:state:default]" }
Switch  garageDoor_Refresh  "Refresh Garage"    <controller>    (Network)       { mqtt=">[moquitto:home/garage/out/0/refresh:command:ON:1]", autoupdate="false" }
Contact VT_Lock_Locked  "Locked [MAP(VTLockStateMap.map):%d]"   <door>
Number  VT_Lock_State   "Door state [MAP(VTLockStateIDMap.map):%d]" <door>
String  VT_Lock_StateName   "State" <door>
Switch  VT_Lock_BatteryCritical "Battery level" <door>
Switch  VT_Lock_Action  "Lock / unlock" <door>  { http=">[ON:GET:http://nuki-bridge:8080/lockAction?token=aa&nukiId=11&action=2] >[OFF:GET:http://nuki-bridge:8080/lockAction?token=aa&nukiId=11&action=1]" }

jaydee73 · January 18, 2017, 10:48am

The item error could be related to a bunch of reasons:

You still have the old zwave item definitions (“zwave=…”) in your item file. As you are using the 2.0 binding, you have to change this to “channel=…”.

You are using icon definitions. Are these icon names (door, battery_full etc.) also all available with the OH2 icon set?

Don’t know about the definition of the MQTT items. Are they defined different in OH2?

Do the map files exist in OH2?

Does the http binding use other definitions in OH2?

I think you have to “clean up” your item file first. If the error still persists, remove all items and try adding one item after the other to see, which one produces the error.

Regarding the zwave devices, I’ve no clue. If they are battery based devices, try to wake them up several times. But I think the relays should be mains powered…

DocFraggle · January 18, 2017, 8:12pm

Hi,

as Stefan already pointed out, you have to change the item definition for your Zwave devices like this:

Contact Contact_Haustuer	 "Haustüre [MAP(de.map):%s]"	<frontdoor>	(WS) { channel="zwave:device:bb4d2b80:node14:sensor_door" }

You can find the corresponding string in Paper UI.

Are you referring to battery powered devices which show up as unrecognized? Battery devices take several wake-up cycles until they are fully initiallized. You can speed up the process by triggering the tamper button or the contact itself. You can see the process in the log.

anon83483981 · January 18, 2017, 8:17pm

No - all the devices which are currently unknown are mains powered devices. The strange thing is they were all working prior to the 2.0 upgrade. I really don’t want to have to remove and pair them again.

DocFraggle · January 18, 2017, 8:35pm

Are all of the unknown devices the same type? Would you mind to share which device it is exactly?

anon83483981 · January 18, 2017, 8:41pm

Not all of the same type;

Node 22 and 39 I have tried to remove in the past and couldn’t, so I’m OK that they are offline.

Node 37 Fibaro FGS221. Another which isn’t working which you don’t see above is a Fibaro FGD211, and node 41 is a Fibaro FGK101. Note, some devices of the same type have been detected and are working correctly, which is even more confusing.

One of the devices it says can’t talk to the controller I can switch on and off from my sitemap…

Node 37, for example, I can’t assign channels (hasn’t finished configuration yet) but it almost knows what it is:

anon83483981 · January 18, 2017, 10:07pm

In terms of the 500 errors, I’ve narrowed it down to items using transform maps and %d. Has this changed at all in OH2?

jaydee73 · January 19, 2017, 8:22am

If this are dead nodes, you should finally remove them. If it couldn’t be done with the habmin exclusion, try another way. Which controller are you using? I’m using an Aeon stick Gen5 and was able to get rid of dead nodes using the zensys tool. A good explanation how to remove the dead nodes can be found here:

Same type doesn’t necessarily mean same function: I’ve seen some Fibaro devices lately which got new features but still the same product number. Are the firmware versions really identical?

anon83483981 · January 19, 2017, 8:29am

I’m using an Aeon stick S2. I’ve actually had a Gen5 stick delivered today - are they much better. I was thinking about chucking it in, but I’d really rather not include every single of my 30+ nodes again. Is there a way to transfer them to the new stick?

If I try to remove the node manually using ‘remove failed node’ I get:

Will read the link about excluding ghost nodes, thanks

I’m not sure about firmware versions - for the devices that are currently inaccessible at least. How do I tell what firmware it’s running?

jaydee73 · January 19, 2017, 8:36am

Then G5 stick has a battery. So you can also inlcude devices which are already mounted and not near your old controller. Simply plug the G5 stick out of your system, go to the device and include it there. The stick operates battery-powered.

Yes, sometimes the devices can’t be removed with habmin or paperui. Then you have to use the tool.

I don’t know about a transfer from the old to the new stick. There is a backup tool available from Aeon, but I don’t think that the tools supports the migration from one stick to a different one.

FW version: Well, you can see them in the attributes section of habmin. But you are right, if they aren’t accessible, that probably will not work. Sometimes they are also written on the device or on the package.