I’ve got a raspberry pi running OH2 (via openhabian), an Aeotec Zstick Gen 5 attached to it, and a Trane XL850 thermostat connected to it.
So far, so good. I can add other zwave devices to Openhab fine, but the thermostat shows up as Node4 (unknown device.)
I’ve tried a few things:
Excluding and reincluding it
Checking if the device was in the database (it was not)
Taking some of the configuration data from other Trane thermostats and adding it to my jsondb
I’m brand new to this environment, and I feel like maybe I just don’t know the right steps I need to take to add the right information to whatever local copy of the zwave DB is on the pi.
But I wasn’t able to figure out how to experiment with my local install to see if maybe I could pull/push some data to the device. I searched the docs on the openhab site, and found plenty of examples of how to add things manually if they already had DB entries, but not any information on how to manually construct a DB entry/mess with a local install to test the integration, and paper UI basically just tells me to reach out about adding the device to the DB.
Welcome to openHAB.
The database you are talking about is merged into the binding.
To get the latest changes from the online database you need to upgrade your openHAB to the latest zwave snapshot binding.
To add your device to the database we need the xml for that device from your /userdata/zwave folder.
Alright, thanks for the tips! (In case someone finds this later, I found my userdata folder at the path /srv/openhab2-userdata/zwave).
Found the device XML, and it looks like it’s reporting itself as a static controller, which unfortunately makes sense based on what I’ve read elsewhere about the thermostat. (That it has some internal bindings, but maybe isn’t controllable via zwave).
I think your device is not fully discovered.The manufacturer, deviceId, & deviceType looks suspiciously invalid. Trane is id 008d, for instance. The zwave alliance lists many command classes supported by that thermostat.
No need to do that. Delete the Thing and re-discover it. If the device is battery operated you may need to wake it up a number of times until it is fully discovered.
Reinitialize the device via paper UI, ensuring I keep the thermostat awake by interacting with it. Same results. (Though a new zwave xml file is created, based on timestamps. The file is identical.
Delete the Thing and rediscover it. Same result – new xml, same data.
Exclude and reinclude the thermostat, re-add the thing. Same result – a new xml file is generated, but it’s identical to the existing one, just with a new timestamp.
In all cases, the result seems to be that Openhab is attempting to reinitialize, but failing to get data on the device. (Or the device isn’t providing it.)
Thoughts? Happy to dive into debug logs if someone can point me their way.
events.log
2019-12-07 11:40:25.723 [hingStatusInfoChangedEvent] - 'zwave:device:cf946845:node4' changed from UNINITIALIZED to INITIALIZING
2019-12-07 11:40:25.745 [hingStatusInfoChangedEvent] - 'zwave:device:cf946845:node4' changed from INITIALIZING to OFFLINE (BRIDGE_OFFLINE): Controller is offline
2019-12-07 11:40:25.753 [hingStatusInfoChangedEvent] - 'zwave:device:cf946845:node4' changed from OFFLINE (BRIDGE_OFFLINE): Controller is offline to ONLINE
2019-12-07 11:40:25.765 [me.event.ThingUpdatedEvent] - Thing 'zwave:device:cf946845:node4' has been updated.
2019-12-07 11:40:25.779 [me.event.ThingUpdatedEvent] - Thing 'zwave:device:cf946845:node4' has been updated.
2019-12-07 11:40:25.791 [me.event.ThingUpdatedEvent] - Thing 'zwave:device:cf946845:node4' has been updated.
Edit:
Wait, there are some IO exceptions in the logs in openhab.log. Let me see if I can figure out how to enable debug/trace level logging and get more info:
2019-12-07 11:39:54.466 [ERROR] [ing.zwave.handler.ZWaveSerialHandler] - Got I/O exception Input/output error in writeArray during sending. exiting thread.
2019-12-07 11:39:56.643 [WARN ] [wave.discovery.ZWaveDiscoveryService] - NODE 4: Device discovery could not resolve to a thingType! Manufacturer data not known.
2019-12-07 11:40:03.725 [ERROR] [ing.zwave.handler.ZWaveSerialHandler] - Got I/O exception Input/output error in writeArray during sending. exiting thread.
2019-12-07 11:40:05.776 [WARN ] [wave.discovery.ZWaveDiscoveryService] - NODE 4: Device discovery could not resolve to a thingType! Manufacturer data not known.
2019-12-07 11:40:05.787 [INFO ] [g.discovery.internal.PersistentInbox] - Added new thing 'zwave:device:cf946845:node4' to inbox.
2019-12-07 11:40:07.805 [WARN ] [.core.thing.binding.BaseThingHandler] - Handler UniFiControllerThingHandler tried updating the thing status although the handler was already disposed.
2019-12-07 11:40:16.721 [ERROR] [ing.zwave.handler.ZWaveSerialHandler] - Got I/O exception Input/output error in writeArray during sending. exiting thread.
2019-12-07 11:40:18.739 [WARN ] [wave.discovery.ZWaveDiscoveryService] - NODE 4: Device discovery could not resolve to a thingType! Manufacturer data not known.
2019-12-07 11:40:28.651 [WARN ] [.core.thing.binding.BaseThingHandler] - Handler UniFiControllerThingHandler tried updating the thing status although the handler was already disposed.
2019-12-07 11:40:46.721 [ERROR] [ing.zwave.handler.ZWaveSerialHandler] - Got I/O exception Input/output error in writeArray during sending. exiting thread.
(also, aside, the UnifiControllerThingHandler seems to throw lots of warnings…)
There really isn’t anything else in the log. I let it run for ~10 minutes before and after, and it the only things I cut were a ton of UnifiController handler warnings before and afterwards, and the gigantic list of devices that the node is not, a la Checking zwave:leviton_dzpa1_00_000.
I have otherwise not filtered anything from the logs.
That said, I spoke with Trane as well, and just got this response:
Good morning,
In our current state we don’t allow our 824/850/1050 controls to act as a z wave only device.
We have development plans to allow our controls to be treated as a z wave only device.
This may be available Q2/Q3 of 2020.
So it looks like XL824, XL850, and XL1050 are unable to be controlled via a zwave network for the time being, so this might be case closed for now.
