That’s interesting. I also tried changing the temperature after using the buttons on the device. Indeed it seems to wake up briefly when you press a button after which I can too change the termperature from the UI.
You are returning them… but don’t you think that the device could be made to work? I mean, I read elsewhere that people are (in varying amounts) satisfied with the device and that it works well with other types of home automation systems. Like Domoticz, Homey and Home Assistant.
Also it’s strange that for some people it works fine whereas for others it does not. If you own the device can you report its firmware version maybe? It could be that some people like me have old stock. I have version 0.15 (seen in PaperUI in the devices properties under “zwave_version”).
In sum, I think the problem is either with OpenHAB or with individual devices. This is very unfortunate, the device gets raving reviews on many outlets and review sites. I guess those people are not using OpenHAB…
Have you guys tried excluding the Spirit and including in close proximity to your controller? I had similar issues when I included the device from another floor - excluded and included within 10 cm of my z-wave stick and now it works perfectly (i.e. responding to updates immediately - obviously there is still no external temp measurement or valve control functionality). So I think there is no issue with the Z-Wave binding in this case…
My devices have firmware version 0.15 as well. I now have 6 devices in active use.
For installing, I carefully used the same sequence:
power on and include in the Zwave network: physically close to the zwave controller (1m-2m), using paper UI
install the valve on the radiator and ensure that the device doesn’t throw an installation error (ER1, ER2 or ER3, see manual). I have the strong impression that valves won’t start transmitting anything until they are installed (in physical sense) properly.
press the middle button just once
paper UI now recognizes the device as a Eurotronic Spirit
in Habmin, change the parameters 5 (“Measured temperature report”) and 6 (“Valve Opening Percentage report”) to 1.
in Paper UI, create items for actual temperature, setpoint and valve opening. After a while, you should see first measurements coming in.
Thanks for both your write ups. I tried setting parameters 5 & 6 to 1. It didn’t help. Next I’ll try completely excluding and include close to the controller… How that could help is beyond me though. (Why would the range at time of inclusion matter for its functioning when it’s installed in its final position???)
I found out a few things. It turns out that it’s certainly a range issue after all. Inclusion and exclusion does not work well from a distance, just like operating the rest of the device. It’s almost always offline and only responds–albeit very unreliably–when pressing the buttons, and only for a few seconds before it goes offline again. Next to the controller everything works perfectly.
When I remove the thermostat after installation and move it close to the controller (while still included) it responds very well to commands and I think it also stays online (difficult to see because it goes into install mode fairly quickly when it detects there’s no valve. Installing on the valve again yields the same problems again. I already suspected that inclusion close to the controller would not make a difference (why would it?). I think that the cause of the routing problem is also a perfect explanation why some people have problems and others do not: for some people there are no routing nodes required, as their direct range from the controller to the Spirit is small enough.
So there you have it, it’s a range issue. And one that is probably caused by the Spirit not taking indirect routes over the mesh network, since it has no neighbours and does not route (as also mentioned earlier).
Dear Gabri. Thanks for testing and confirming my guess. I don’t think that we can fix that because the device is a blackbox. I already talked to eurotronics but the seem not to be very supportiv on this topic.
@chris: You are the expert. Do you see anything we can do here? If I remember correct you have bought a device as well?
Why don’t you think it routes? I would be VERY surprised if that was the case - it’s basic device type is a routing slave, so I think it does route.
Sorry, but can someone summarise in a short post as to what the problem is? There’s a lot of posts here and it’s hard to follow what is working and what is still the problem.
I bought one of these at the end of last year to do some testing, but it didn’t work and had to be returned. I do have a replacement, but I’ve it’s just sitting in the large box of stuff I’ve bought for testing at the moment as I’ve been busy with other things…
To sume it up. The inclusion of the device works fine, so the database seems to be correct. But the device doesn’t report any neighbours to openhab (XML + habmin checked). hansvandamme is using the devices in a short distance to the controller and everything works. Gabri and myself have a longer distance to the controller, so we rely on routing and it doesn’t work for us (several other devices in the same room are working perfectly, at least for me). Gabri moved the device next to the controller for testing purpose and everything was fine as well.
Nevertheless, if we push a button on the device the value is reported to the controller and for a short period of time the device is reacting on changes performed via GUI. (Device will be reported as active but status changes back after a while)
So our conclusion is it must have something to do with routing.
This doesn’t mean it doesn’t route. The controller is responsible for doing the routing and the binding has no knowledge about this. Also, neighbours are not the only method used to establish routes. The system will use (so called) Explorer frames to discover a route to a specific device (this is a ZWave plus feature, so if other devices are not ZWave plus, then it may not work).
Maybe it has to do with routing still - I’m not sure. Really there’s not so much that the binding can do about routing. It just tells the controller to set up routes - the actual routing is done completely by the controller.
If you are not already doing so, I would recommend to use the development version of the binding. See the following thread for installing it.
Other than that I’m not sure what I can suggest as the binding is not really involved with the network layer.
Thanks for your help. I continued the investigation. (I’d really like to be able to turn on my heating when I’m away this winter season ;))
I installed the test Z-wave binding, by first removing the normal one from the latest snapshot in PaperUI, then dropping the .jar file into the /usr/share/openhab2/addons folder. I removed all my items then (needs to be done either forcibly or via HABmin). When discovering new items, everything is found and works, except all the Spirit TRVs!
They are discovered but they just show “Z-Wave Node XXX” as an unknown device, and don’t get initialised.
Also, still they show: “OFFLINE - COMMUNICATION_ERROR Node is not communicating with controller”
One more thought: I think the next step is determining if the device itself is at fault here to try to rule out OpenHAB as the culprit.
It seems unlikely though that it’s the device itself, as for sure Eurotronic would have tested its routing capabilities, but maybe not with OpenHAB. Anyway, if it is a device problem we can all send an e-mail to Eurotronic to let them fix it. I believe this is the first TRV device with FLiRS so perhaps there are teething troubles.
What I can do is trying my whole Z-Wave installation with another system. If time permits I will try to install Domoticz this weekend, which also uses OpenZwave. If it works with Domoticz then we know we have to hunt for the problem in OpenHAB.
As for OpenHAB itself, can a developer (Chris?) shed light on what we could try next?
I tried Domoticz. It makes no difference for the reception of the devices. I don’t see an option in Domoticz to display neighbours or to view a network map as in HABmin though, so I cannot provide evidence, but it seems that the problem remains the same. So I think the device does not contact its neighbours and thus cannot route. To be absolutely sure I will install a powered Z-wave device near the Spirit to see if it works when it is provided with such a close neighbour.
Although I don’t know why, after excluding and including my Spirits, they now route correctly and report neighbours in HABmin. I think I might know where to look in order to understand what was wrong. Namely, the “Show Properties” screen in Paper UI for the Spirit valve has become much more extensive and lists neighbours, routing, beaming and more. I recall that it was much less detailed than it is now:
No idea why this is. Perhaps because I added a new Z-wave mains-powered switch last week? Other than that the only thing I did was re-including the valves. Could a different specification suddenly have become active or something?
In HABmin’s Z-Wave Network Viewer you see that both my Spirit valves now show neighbours:
(Node 11 and 15 are the Spirit Z-Wave Plus valves.)
Which is also visible in the Thing configuration under the Attributes section:
Request: Can another Spirit owner perhaps also show their “Properties” page and their “Attributes” section in HABmin if it’s much different from the above? Especially for someone who has the same problems as I had. (chr1s?)
Maybe we can find out what makes these devices not route at first.
Anyway, I’m happy it is resolved. Fingers crossed it stays this way…
I mentioned earlier that the Spirit I installed was working perfectly - now I take it back, it sporadically lost connection with the controller despite being 5m away in the adjacent room. Two other Spirits I installed downstairs never worked properly either. So I returned all of them and bought a Fibaro Heat Controller instead. I highly recommend this to anyone who is having trouble with their Spirits - it has the same FLiRS tech so responds immediately to commands, is half the size of the Spirit, has a rechargeable Lithium battery and works so much better from further away. Fibaro also sell an external temp sensor for it so you can get it to reference the room temp away from the radiators to make it more accurate. Only thing is its £62 here in the UK vs £50 for the Spirits. Probably worth it if you consider it’s actually working!
I also had trouble with the device not reaching my controller, and the controller declaring it OFFLINE all the time. The device is maybe 5m away through two walls/doors. The controller stick was plugged right into the box running OpenHAB. And in the same corner I also have my DSL/Wifi box, power supplies, network cables… Now I tried putting some USB extension between the controller stick and the box and moved the stick away (less than a meter), trying to rule out possible interferences or shielding. And what should I say, since then the connection seems pretty stable, since then no more OFFLINE.
(Of course I can’t rule out that it’s just coincidence, and that now the controller is just in a little bit better position regarding walls and doors…)
So probably the Spirit has a low range. This would not be a problem if it shows proper meshing behaviour and you have an always listening slave close by for routing messages. Can you both check in HABmin if it does that? (That is, check the same sections as in the screenshots I took above. It should show multiple neighbours in the Attributes section and green lines to other nodes in the Z-Wave Network Viewer.)
