Just wading through that now, and had though of the 'spoofing' as a last resort.
EDIT: LWT set as default in Tasmota, Shelly doesn't appear to be available, so looking at configuring from Node-RED.
1 Like
I only have 1 Shelly "live" at the moment and it is sat right next to me here in the office controlling my RGB LED strip that runs around the desk and shelves. So I don't really need to worry about that being on or offline 
1 Like
Hello chaps
I have just discovered this thread and have caught up on the discussion so far. This is a subject very close to my heart as I have been running a fully automated radio controlled TRV system for some years.
My system was originally Eq-3's Max! system. which sadly they don't make any more. It ticked a lot of the boxes discussed above. The valves are quiet except for a couple of the earlier boxy valves which make a bit of noise but I have those in hallways where they are not going to disturb anyone. The newer slimline ones are pretty silent. Battery life is at least two years. I recently replaced a battery and was surprised to see it was a brand I never buy, which means it was original and had probably been in the unit for at least six years.
The 'Cube', the 868MHz device that communicates with the valves and connected to the cloud service or the local app was though a bit unreliable with a lot of valves - I have 17 radiators and seven thermostats so a little while ago I flashed the Cube with CUL firmware and now control it via Homegear on a separate RPi, which gives me an interface with OpenHAB (my main controller - the reason I am here is I use Node Red for all my automation rules. OpenHAB takes care of the comms and channels to devices; NodeRed takes care of the thinking) and also MQTT which I use direct from Node Red because putting OpenHAB into the loop there would just add needless complexity.
I would certainly argue that having individually controllable valves has saved me a small fortune on my heating bills. I live in a 300 year old house that is not well insulated. Since my two sons have left home there is just the two of us and we don't use most of the five bedrooms and three reception rooms from one day to the next. A small subset of rooms warm up in the morning including the bedroom, hallways, kitchen and bathrooms but then the kitchen and the bedroom cool down again. The living room only comes on for a couple of hours at lunctime joined by the kitchen and they then go off again until the evening. The bedroom doesn't heat up again until late evening. Many rooms don't come on at all except for maintaining a sensible temperature so they don't get condensation. I can ping out new schedules though over MQTT using Node Red at the drop of a hat such as guests coming (guest rooms and the dining room heat up on schedules) or sons coming home to visit (guest rooms stay warm much later in the evening and the shower stays warm much later in the morning at weekends!). I like the fact that the schedules are in the TRVs so if something does go down in the control system, at least the house keeps doing what it should and stays warm.
I currently have several schedules set up in Node Red in a nice user friendly JSON format which I can send out to the devices using JSONata to turn the human readable data into machine readable messages. I am working on user interface to make it more of an appliance and easier for my wife to control. The plan is to have 'stackable' schedules whereby activating a higher priority schedule (e.g. guests or holidays) will override lower priority ones only at the times and in rooms that it needs to affect and then the lower priority schedule will take over again when the higher schedule is cancelled. I don't believe any other system does that. I'm also using the concept of "defined times" such as "getting up time" so that if you change "getting up time" temporarily to an hour earlier for an early start, all the schedules based on "getting up time" or an offset from it will change to match without having to edit schedules for umpteen rooms. I'm using JSONata again (very powerful once you've climbed the very steep learning curve) to manipulate the schedule data. I'm having some success but it's not ready to share with the class yet.
I am beside myself with excitement to read that Julian is planning to apply his considerable talents to the Wiser system though. I am conscious that Eq-3 don't make the Max! system any more and the valves are impossible to find at sensible prices even on eBay so when one of the valves inevitably breaks, I will lose control of a room. I need to plan for when that happens. I have looked at Eq-3's Homematic but I don't trust how long Homematic devices will be available as Eq-3 is moving everything to HomematicIP, which Homegear won't talk to and it is looking like never will. Evohome is bloody expensive but Wiser seems to tick all the boxes. If Julian can open up the API with access to the schedules and easy access from Node Red then I shall be happy.
I share a number of contributors' scepticism of wifi as a means of communication but I'm willing to be educated. The Max! system and Homegear especially since I flashed the Cube has proved rock solid with great battery life. Having said that I do run Z-Wave, Philips Hue and EnOcean devices all controlled through OpenHAB and they are solid too.
I am looking forward to following this discussion with interest.
I clearly need to get you to speak at length to my wife!! 
It may be and I've had some recent conflicting information about the reliability of Honeywell systems though I'd have to say that the EvoHome system is a lot more mature than the Wiser one. But I've no actual experience with it.
It did say for a long time that were I to do it over again, I'd probably accept the cost and go with the more mature EvoHome. Now I'm not so sure. I got the Wiser system because it was my first move into smart heating and heating controls in general and I wasn't sure it would be worth it or would be accepted by the family so I wanted to keep the cost as low as feasible.
There are some limitations of the Wiser system certainly. The TRVs are not the most reliable of things. I've had several fail and others fairly regularly (maybe once a year) have to be taken off, completely reset and put back. I'd say that the motor/gear combination is just a little marginal, at least for our old rads. Though who know's how long the bases of the TRVs have been on our rads - we've been in the house over 20 years now and they date from well before that. So maybe not entirely Drayton's fault. Anyway, the TRV reliability and the cost of the smartplugs which you would need on a larger system to extend the Zigbee mesh have to be added to the overall cost.
The other main limitations are no web interface for controls, only an app. The app isn't bad though. Also, no published API, only a fairly noddy API setup makes it feasible to do anything with. Typically, I poll the controller every 60s and then do some processing in Node-RED to create individual change events.
I will do my best to make you happy then 
I'm now at a point with the node that I can push to GitHub so I should be doing that over the next few days. I'll try to at least get some basic controls in place - currently I'm just polling the data, creating the change outputs along with a load of other event outputs. And writing some get..... functions to let you get specific information sets such as offline devices, devices with low or dead batteries, rooms with temperatures above or below a given temperature. Things you can't do or at least not easily with the official app.
I've got some code I can move from my previous library to set room setpoints and do boosts. What I don't yet have is code to mess with schedules, I need to work on that. Shouldn't be too hard, I just never got round to it with the previous library.
I'll set up a different thread when I push the code to GitHub.
Ah yes - trying to explain to the wife the good we do. Mine complains about the time I spend tinkering with stuff but then when we have a powercut, which living in a rural village we often do, she's very happy when her computer and all the wifi and servers and switches and everything keep working because the IT is all powered by a huge UPS wired into wall sockets around the house that keeps everything on. 'Doesn't everybody have that? she asks. No they jolly well don't.
I suspect your system might be suffering from unreliability in the valves themselves rather than the motor units, especially if your valves are old. When I started I had some new Honeywell valves thinking they had a good reputation but they were unreliable as hell. They kept sticking open or closed. When I had some work done later I had all the valves replaced with Drayton TRV4s having been told by the plumber that he was often called out to replace sticking TRVs but never the Draytons. The difference has been remarkable. The system just works.
Sounds like you have a bit of work to do on your Wiser node but I'll follow with interest. Given I have a working system migrating to Wiser is not a priority yet fortunately. My main priority is the user interface and for that I plan to use your slightly daunting but awesome uibuilder node. If only I had more time!
1 Like
That's good to know, thanks. If we have to take any rads out again, I may try to get some new valves. In the meantime, I might try some lubrication again. I've some silicon lube which might work well - at least for a while.
It seems that Danfoss also has a zigbee system
Danfoss Ally
With an open api
Not the cheapest, but a well known player in heating systems
With an open api
Open - cloud - API. Cloud down, no heating.
2 Likes
Sorry, not as much knowledge as you.
But in zigbee2mqtt is this valve enlisted
Danfoss Ally
1 Like
With zigbee it should be good. Then again, never know with these manufacturers. Hopefully they will start to embrace openness.
What do you mean, are there manufacturers who you can trust?
Zigbee specs Ally
Zigbee specs
Well you don't need to take the rads out. It's a pain doing one rad because unless you use one of those freezing systems, you have to drain the whole system to change one valve. But as soon as you do need to drain the system ever, grab the opportunity to do the lot! Do it once then forget about it. When we did that I had the plumber come round and do every single valve in the system in one morning with brand new TRV4s, including the ones I'd already had fitted with the Honeywell valves.
If you've got valves that are a) no-name or cheap brands (or even Honeywell!) and b) 20 years old or more it's perhaps not surprising it's unreliable. I used to think my valve actuators weren't reliable until I discovered it was the valves themselves.
I managed to find a seller that sold just the valve body (i.e. without the wax capsule thermostatic head - which I was just going to chuck away anyway). You can get them for less than Ā£10 each instead of Ā£20 odd with the head. Which was quite a saving on 17 rads.
1 Like
Like on Amazon Drayton TRV4 Classic Thermostatic Radiator Valve TRV Body ONLY - no Head : Amazon.co.uk: DIY & Tools and eBay Drayton TRV4 Classic Thermostatic Radiator Valve BODY ONLY no Head 5016254106004 | eBay - both around Ā£10.
Good tip, thanks.
In the meantime, I'll go round all the rads and give the valve pins a squirt of silicon lube. Less messy than WD40 and better copes with heat.
Ok, found another one while searching for WIFI devices: the Eurotronic Comet WiFi radiotor valve.
They would cost me 92 EUR (incl. VAT) for 3 devices, which is A LOT more cheaper compared to the Shelly's:
Some info about those devices:
- 2.4 GHz WLAN
- No additional gateway is needed
- 2 x 1.5V AA/Mignon/LR6
- Dimensions: (w x h x d) 62 x 68 x 83 mm
- They claim that they somehow use less power compared to zigbee, zwave...?
In their datasheet I don't see anything about an API, so not sure if it can be controlled by Node-RED. In the HomeAssistant forum, somebody confirmes that the API is not ready yet. But in that same discussion you will see that somebody has reversed engineered their API...
Normally I would be VERY excited right now about this device. However I am pretty sure that somebody in this community will see something that makes it completely useles for me 
So, it may simply be Microsoft Edge's translation from German to English but the product page seems very un-German like! Very gushy, more like a Chinese page.
Kalkschutzfunktion = Limescale protection - urm what? Why would - how would - the TRV do limescale protection? A bit weird I think.
"real-time behavior" - Hmm, OK. So that must mean that the TRV is always connected to Wi-Fi. How does that match up with the claim to be lower power consumption than Zigbee? I'm not a power expert by any means but that seems to fly in the face of simple physics if I'm being honest. I notice that they do not include any information on expected battery life, they just make an unsupported claim that it uses less power.
"save up to 30% on heating costs" - OK, lets stop now. I've had to deal with far too much hype in my time.
Perhaps my 40+ years of IT and dealing with vendors has made me especially cynical and distrusting of over-promising marketing blurb, but ...
Oh, oh, check out the customer reviews on Amazon:
All of the German reviews seem to be 1-star 
In Germany, 1 is the best rating, and 5 is the worst. I couldn't find the ratings page to confirm this.
Urm, I don't think that works - translate the review to see what people think of those devices.
Not that weird, I think it means the value is moved if valve has not moved for a period of time, so the valve does not stick due to limescale build up.
2 Likes
Ah, OK, that may make some kind of sense. Strange to call it that though but maybe it makes more sense in German, my German isn't terribly strong I'm afraid.
I am wondering why Discourse didn't automatically assign you the badge of "partystopper"
Hmm I don't mind if the app is crap, because I wouldn't use it anyway. But of course the hardware should be fine...
1 Like
