today i came back home - and - 3 rooms are heated up to 25°!!! (See screenshots)
Funfact - the integrated heat measurement of the Sprits shows exactly that high temperature - but it seems that they dont close the valve.
That’s really annoying because - in my case - such things are unusable.
Maybe my claims are to high - I’m a passionate Apple user – unbox, setup, working.
Thats the way I want hardware to work.
No need to restart apps, reboot Homey or other things to get a reliable status.
Not sure where to check this, but in the “Z-Wave” section there a some Tx Errors - but only 1%.
That can’t be the reason imho. We got only two floors of 50m². No inteferences – because I dont even have a DECT phone or something like this. Our building is very thankful for wireless communication. One access point feeds the whole building with stable WiFi - and Zwave should be even more stable per se. But it isn’t.
First off, let me say I agree with you. Hardware should ‘just work’. The restarting of the app is not something I find ‘normal’. It was just an observation.
Unfortunately there’s no easy way to tell the current position of the valves. The fact that they measure a high temperature can also be caused by the physical position in your house. One of my valves also gives inreliable measurements due to the fact that the valve is close to a cabinet and a curtain. (the heat ‘hangs’ there)
I use an external thermometer for the measurements.
This is the downside of measuring room temperature closer to the heat source.
From what tot describe, connectivity is not an issue. That means that the flirs technology is also not the issue.
Was the room actually 25 degrees? (did it feel warm if you didn’t look at the measured temperature?)
My best guess is that you are running into the physical positioning of the valves. There’s not much you can do with that other than using other measuring points. (maybe you have motion sensors that measure temperature or something?)
Now that I think of it. You could check the position of the valve especially if the requested temperature is 4 degrees lower than the measured temperature) is by ‘requesting’ 18 degrees. The valve should not (or hardly) move then. And if you set it to 30 it should move open completely. Then you at least know the valve is responding to the measured and requested temperature properly.
The measured temperatures are accurate - I set the offset weeks ago so that the measured temp (as you see in screenshots) match the current temperature. In the maximum there is a deviation of 0,3°.
And yes - because one of the rooms is the “main entry” I recordnized this enormous warmth as soon as I entered my house and the room was actually heated up to 25°
I’ll check your hint with the valve position. It’s very curious, because as you can see in the screenshots, Homey says “cooling down” but when I touch the radiator or the short pipe between the SPIRIT and the RADIATOR it was very hot. So definitly the valve wasn’t shut down - despite of the display saying that is cooling down
Nice to notice! i had the same issue yesterday?? temperature was set correctly but the valve was still open? even the setpoint was reached? I set the valve to OFF completely and then the valve was closed? din’t inspect it any further. will double check again
Hi,
I can’t get my Spirits to include properly. I added the Eurotronic 2.0.7 app to my Homey 3.2.0 but when pairing, it keeps saying that it cannot find a compatible Homey app and adds it as simple Z-Wave device thereafter.
How can I debug this?
A simple zwave device means your version of the valve isn’t supported yet (identification ID’s aren’t implemented), can you give me the id’s so I can add them in a future update?
You can find them if you go to the settings of your simple zwave device, and click “advanced settings”, then under “node information”, I need 3 ID’s:
are you sure it is from Eurotronic Technologies?, and not just a look-a-like, as the manufacturer ID is from a different manufacturer (according to the z-wave alliance the manufacturer is Aeotec Limited).
The “spirit” type of valve has several re-brands, and don’t necessarily work the same
Yes I am. I bought it as Eurotronic Spirit from amazon, the box says Eurotronic Spirit with EAN 4260012711301 and it contains a leaflet from Eurotronic; and the device looks exactly as the Spirit on the Leaflet and on the Eurotronic website.
But kinda second guessing if i should add it into my app, as people that do buy the aeotec version might get the wrong app used.
have checked their documentation, and seem pretty similar except for 1 command class that is different, and as the aeotec’s documentation is a bit lacking makes the decision harder.
i’ll add it to my to-do list to add it, but will have to do more research first, so can’t promise anything.
if they are similar enough, i’ll add it.
Maybe you can share the amazon listing, as that might give more clues, or that they just f*ed up.
According to them, amazon.de randomly ships units from either Eurotronic or Aeotec. And it seems that he was able to get the Aeotec one working as well, the description looks not too complicated.
I have a probleam appearing randomly.
If a window is opened, a flow sets the Eurotronic Spirit to mode “Off”. Closing the window, another flow sets it to “Heating” (or “Comfort” like displayed in the app).
Most times it’s working. But sometimes not.
I had several times the situation, that if the window was closed, the thermostat kept in mode “Off”. But in Homey, the devide has the state set by the flow (Heating). I seems that the flow is changing the device mode in Homey, but only that, not the device itself.
I suspect the error occured since one of the last Athom updates (3.1?), but I’m not sure. Has athom changed something in the Z-Wave framework that the Eurotronic app don’t get a error response if changing the thermostat was not possible (if offline)?
Is there a way to check the error reason (Z-Wave-Reponse/Timeout)?
Would it be possible to add something like a debug mode to the device/app to write a timeline entry if an error appears while changing the thermostat properties?
Not sure if you can see the acknowledge in the zwave log if you go to the developer tools, that’s the easiest way to debug something like this but it does sound like the thermostatic is on the edge of Homey range
Hello,
I read about changes in the Homey messaging from synchronous to asynchronous logic by Athom in another thread. Could that be the reason?
In the past, the app was reacting on send errors and set the device state back to the previous state if an error occoured.
Now the app sets the device state to the on it’s trying to set and it doesn’t change it to previous state if an error orroures. I seens the app doesn’t get/check the result of the send request.
And yes, the thermostat if most far from Homey/repeater. But if there was an error, I could see it in HomeyDash and I could set the mode again (on/off). Now I can only see it when comparing the state in the app/HomesDash and the thermostat display.
It would be nice if you could check if Athom really changed something in the messaging. Thank you.
.
