That I can't answer but there is only one entry in the device event log
Meine Damen und Herren,
ich darf Ihnen auch mein Driver vorstellen.
Es werden in voller Maße Funktionen unterstützt, einschließlich manuelle Kontrolle von Valwe-Position in Modus "manufacturer specific". Es ist einiges zu beachten: Modi tragen andere Nahmen. "heat" ist "auto", "energy save heat" ist "cool", "heat" ist "manufacturer specific". Also, damit die Kontrolle über Valwe-Position genommen wird, muss Modus "heat" gewählt werden. Später wird es korrigiert.
[Release Eurotronic Spirit Z-Wave Plus TRV · Aelfot/Aelfot (github.com)]( Aelfot/EurotronicSpiritTRV.groovy at main · Aelfot/Aelfot (github.com))
Still experiencing setpiont issues even with staggered times. Even noticed my MCO HOME MH17 thermostat with the built in generic z-wave thermostat it goes bonkers on occasion. Something funky going on with my c-5.
Switched on logging for all my z-wave devices now. I'm getting duplicates everywhere, so yes, something is wrong with my network. Tweaked the energy monitoring plugs, binned the cheap z-wave plugs which I can't adjust the energy monitoring. It's much better now but still duplicates but much less. All TRV's are now polled only. Just ordered a C7 to test all my thermostats as debugging on the c5 is non-existent.
I had nothing but problems with zigbee trvs.
I now use thermal actuators. Don't miss a beat.
Totally agree and I have started using them But these z-wave ones have flagged up some issues with my network. Thermal actuators are the way to go if you have a socket near by and bloody quiet too.
I actually just run a single socket, 2amp fuse, branched to every actuator via junction boxes around the house. Tiny current, small fuse. No worries.
Well... That looks interesting.
Would you mind talking me through your setup please? The graph looks awesome... But more importantly, I seem to struggle a little with getting an accurate temp in the room. My DHT22's always feel as if they're recording a lower temp than it feels.
I assumed this was down to placement within the room. I have found that, for example, increasing the height of the sensor location can make a considerable difference to the reported temp. I've yet to try to calibrate against say, a 'dumb' source. But also, I assumes it may be down to air movement within the room (I. E it's hotter closer to the rads and takes a while to acclimatise).
Here's a visual. My graph really needs some work. Essentially, the solid reds show when the actuator/heating is on. It appears that when the rad kicks in, the temp (oddly) actually drops for a bit.
The mechanics are sound - everything functions. But the heating control could be better and I'd love to understand it.
The graph is rubbish - need to have a better look at at. Wondered why it was showing as being 'on' through the early hours. My events show that this isn't the case. So I've clearly messed my hubigraphs up! =p
I'm using this app and it's brilliant. Using the temperature from hue motion placed on the other side of room. Then the built in scheduler. Charting is the classic influxes and grafana combo.
Charting using Hubigraphs ( [Release] HubiGraphs 4.2 ) is relatively easy to setup.
New c-7 only my thermostat and 3 try's fitted, still getting repeat messages. Set up is to report change only. I don't want to poll but now it's all 3 of them. So to stop it I've find to open the valve and close it. There is nothing in the z-wave logs, so I can only guess the message is not being processes correctly but I really don't know as it's the back end. It's really strange that each message repeats 1 minute and 1 second after. Always when the valve is at 0%
Also "SwitchMultilevelReport" was set v5 and not v1 but that does not make any difference.
While this is frustrating, I'm finding it interesting too as it's forcing me to think about my network rather than it's pair n play.
It's really weird ... You are using the driver from the first post in this thread, right?
In my opinion the valve level reports are generated every minute by the eTRVs, the z-wave protocol should not allow duplicated events to be sent over and over... no matter if there is a device driver to handle the event or not.
Does this happen also if you configure the driver to poll the eTRVs every 15 minutes for example?
Yes I'm using Simons driver. Polling works fine but I turn off change reporting for temp and valve.
If the trv is generating a report every 61 seconds, why is it not showing in the z-wave messaging logs?
My z-wave logs are showing the messages
But what is on your screenshots is actually the device driver logs ( not events ).
Do you have any Valve / Level events shown when you go to the eTRV device driver page and look at the Events page ?
Your trv's shows 40kbps too. When I was getting those repeat messages my logs were empty. If only hubitat stored those z-wave message I could be able to see what was going at the time of it going crazy and I can not reproduce it either.
Removed all 3 of my Trv's and swapped them for a wired solution. They now reside in my drawer of shame
Definitely know that feeling.
offtopic, I'm now attempting to increase the heating efficiency even more. Issue is that one side of the room is cold whilst the radiator is hot. There's too much of a lag between requiring heat, becoming warm enough, switching off, then continuing to provide heat because the room's warm enough but the rad is still hot.
Thinking along the lines of smart radiator fans, and potentially a 2nd temp sensor to monitor air flow temp....
/ off topic
This topic was automatically closed 365 days after the last reply. New replies are no longer allowed.