Interesting. Considering I have zero XML files there currently and whole bunch of devices working correctly. I’m running OpenHAB on Docker and I’m using volume mounts. I’m 99% certain that is working as it should since logs etc are all being written as expected. So basically it should write those XML files the moment there’s some kind of communication going on? This is not happening right now.
I also opened a shell directly into the container and checked it’s local filesystem. That too doesn’t have any Z-Wave XML files. So, still open for suggestions
No - not the moment there is any communication - only once the binding starts to recieve data as part of the interview it performs. This is a specific function the binding will perform to initialise devices.
No - don’t unpair it - that will not help and will just cause you more work. The binding will perform the interview when it doesn’t know anything about a device and will then write the XML.
No worries. Just asking if I was doing something obviously stupid. I’m almost 100% certain that I’m looking in the right place but one never knows… Logs at least are being written to that userdata folder and chmod privileges are correct. But I’ll keep on debugging and will write here if I find the reason.
Oh one more thing when you have time (definitely do this only when you are bored or something): could you point me to that piece of code that is responsible of this in Github? Would help debugging a ton if I could read the code that is responsible for this. I can find this myself too but after some time looking around it was not immediately obvious.
I ended up recreating everything from scratch to ensure system is absolutely clean (still had some leftovers from old versions from which I upgraded). All other devices created XML files as expected but not these Telldus Door Sensors. They do appear in the debug logs and they do send command class messages which OpenHAB understands.
I’ve reached out to Telldus support for help in hope that they would feel it important enough to get their devices to work with OpenHAB. I asked for technical manuals which would contain detailed information about their Z-Wave support (especially command classes). Since I’m not a premium customer it might take a while for them to respond. Let’s see how this goes.
Are they battery devices? If yes, at the bottom of the UI Thing page there needs to be a line for “reconfigure the device” above the “heal Device”, if that is missing the device needs to be woken until that appears. The Xml will also appear at that time. If not battery, I have no idea.
Yup they are battery devices. I’ve tried waking up the devices tons of times by now. There is no “reconfigure device” button in the UI for any battery powered device I have. Would be great if there was, I guess that would enforce reinitialization of the device which should end up creating that XML file. All of my other battery devices work fine, it’s just these devices which don’t since OpenHAB doesn’t know them and for some reason the initialization doesn’t succeed.
There should be these lines for all devices, if the device is not in some state of initialization. There are three (after restart, after inclusion and after heal).
I did some work on the battery device initialization and it can “hang” and appear to not make progress, if it does not go through the first time. Sometimes it picks up where it left off, but sometimes not. Usually after MANY wakes it finishes.
As you can see, there is no reinit button. I think Z-Wave implementation in OpenHAB would require a device debugging view. Right now all you see is ONLINE but that doesn’t really tell you anything. For example, this Telldus sensor that is causing all of these problems is also shown as ONLINE.
That being said based on what you said the device should have finished initialization after the XML file has been created and as such it should also show the reinitialisation button - which now doesn’t happen. For the Telldus sensor I tried waking it up at least 30 times. Nothing changed. Messages still come through when I open/close the sensor but the device itself does not get initialized at OpenHAB and no XML file appears.
I’ll look at the Github issue you posted a bit later, cheers for that. Need to look at with thought and right now I’m still working
As noted above, a working (with XML) battery device could also be missing the line if there is a “heal” message pending. Say you are running a Heal at 2am, the battery device will not process the message until it wakes up, say at 4pm. I generally have the heal disabled as I haven’t made changes recently and do not like to scramble my routings. If that line is missing and the XML is missing it’s not fully initialized. See this post when you get off work
Right. Well, all of my battery devices are still missing the reinitialisation button after several days. Old devices are working fine though, they report data as expected. I received a response from Telldus support that my request has been forwarded to their developers. Let’s see what they have to say on this matter.
I’ve received a response from Telldus development team and they confirmed that they have followed the Z-Wave specification to the letter. However, they also mentioned that some controllers seem to have issues with interview process taking too long and the battery device goes back to sleep before this interview cycle proceeds - the very same issue that has been talked here. They also referred to this page https://products.z-wavealliance.org/products/1455 which would imply that the door sensor would actually be TZDW-100 that is already in the database but it is being reported a bit differently so that OpenHAB doesn’t recognize it as one. I’ve asked for confirmation with a photograph of the device I have that if it is indeed TZDW-100 or not. I’ve also linked this discussion to the Telldus support.
In addition to this I started a spin-off project myself on top of Z-Wave JS (GitHub - zwave-js/node-zwave-js: Z-Wave driver written entirely in JavaScript/TypeScript). With that I’ve been successful to get all my devices working but I can confirm that with that too the given Telldus sensor does not finish the interview process and it too does not recognize it as TZDW-100 which it does have in it’s device database. So the grass is not any greener on that side of the fence on that regard. I had to send custom command classes to get things working. However, with the library approach I can just ignore the interview process since I know what device it is. This is a very brittle approach since that way one has to be super careful with device additions to stay sane and one has to know Z-Wave pretty well. So definitely not something I would recommend adding into OpenHAB.
If Telldus support does confirm that it is indeed a new version of TZDW-100 then I guess we can just add the identification this new version reports to that device type and add that directly to the database?
It looks identical in the image with the exception of the branding. And this link came directly from Telldus tech people so I think mystery is now solved. It also has all the necessary information, including command classes and a technical manual.
I’ll look into this a bit more with this new information.
Hi, just wanted to tell you that I finally managed to get this working. I wrote my own little software with NodeJS which worked but had some issues getting it’s serial port library to work in linux. After that setback went back to OpenHAB (being much wiser about the whole thing at this point) and redid my things configuration. I used the manual configuration via things-file and I totally bypass the discovered items (just ignore them). I use the discovery to find out the node IDs and then type all my devices into that things file.
This way I could force OpenHAB to treat my door sensors as hank_dws01_00_000 which seems to work perfectly. All the channels work, messages come through and everything is now working correctly. I actually prefer this things file based non-discovery way of configuring things so I’m not the least worried about this being a hack. Of course it would be nice if OpenHAB would recognize the devices correctly but I’m happy with this solution.
