But how? Are you using a special interface to generate the 24v pwm?
Noise is my last concern. Perhaps our sleep is to good or the house is so well insulated that when the sweet spot is reached there are no adjustments necessary.
The PWM is done in a node red function running on a 1 second tick and is a slow - 20 second cycle with 1 second granularity. The thermal outputs are driven by mosfets from the 24v Dc supply. I'd have loved the control I would have gained by using motorised valves but the noise and to a certain extent cost, put me off. One key part of the system is wireless sesnor/controller per room. (I made the actuator choice over 4 years ago - maybe motorised TRVs have improved since then.)The sensors are placed in the best spot to sense the room temp rather than being next to the radiator. They have a little display and buttons to and give you quick way to check and/or boost the room without opening an app on the phone. Also linked to Alexa via node red.
Is that a HY368 tuya wifi zigbee TRV ?
Yes. The zigbee2mqtt designation is TuYa TS0601_thermostat.
Mine are the Moes HY369RT ( TRV ZigBee3.0 Smart Radiator Actuator Programmable Thermostatic Radiator Valve on AliExpress) but there are many other suppliers.
1 Like
I have a lot of shellies running on my home router. I felt, if there is to much wifi IOT on the router, there is a risk to overload the thing. I decided to go with z-wave trv's which I integrated in my node-red heating system via zwave-js.
For my floor heating system I use normal electric thermo valves using shelly pro 4s to switch on and off. Some valves are switched with Unipi 1.1 which also acts as one wire interface.
As thermo sensors I took enocean as they are solar powered with a battery backup. 2 years no battery change.
1 Like
Hi Bart,
I was able to get three of the tuya ones for 15ā¬ each from ebay (someone thought it is a good idea to install these in a hotel. Not a good idea!)
First impression:
Pros
- I like the tubular design. Simple and reminds classic valves, compact
- all values are accessible via zigbee (I use zigbee2mqtt)
- seams to be better water protected than my homematic ones (I wish they provided an o ring to seal the battery cover) a pcb sits right next to it, but vertically so perhaps a chance to dry of quickly
- the led display isnāt that bad considering that you barely need it and the design benefits of a monolithic case with no visible display
- time schedules can be loaded easily via zigbee
- link quality (lqi) seams good compared to other zigbee devices nearby
- temperature sensor at the far end behind an opening in the case
Cons:
- the case is spray painted. Wonder how long this lasts. The green house symbol marking the set / wake button can be scratched away easily. Maybe thatās why some distributors donāt have it at all
- no big rotary dial to set the temperature only touch buttons (which donāt react on every button press) Siri will help here.
- typical Chinese English manual - but who RTFM? You only have to get the pairing done.
- usability of the led / touch interface is at least sub optimal- Lucky I recently translated everything to be HomeKit compatible = the family is happy to ask Siri to do stuff - so who needs it at all (except for debugging) I could live without any display / interface
- only battery low is reported, no battery level as my homematic valves and many of my ikea battery powered devices do (so no battery charts to compare)
- no more direct radio connection between my window sensor and the valve (thatās one Homematic advantage) but fixable in software
Noise: as @Buckskin mentioned you can hear the geared dc motor for 1-2 seconds adjusting. But as my old ones if you change the temperature above current the valve don't opens to 100%. It makes an "educated guess" and adjust after a certain time.
Now I have do some long time tests. Curious how they preform and the battery life. Updates on current temperature arrives sparsely. Think pulling data too often will drain the battery. The device spent it's time sleeping. Nice not spamming the broker and my flow with uninteresting data.
comparison Homematic (after 4 Years / Zigbee )
Nice LCD but not needed and the pcb under the buttons is not protected! Even some drops whent directly on the pcb and the battery connector!
Water damage (perhaps repairable for someone with better eyesight and soldering skills)
Morning Chris,
I really appreciate your extensive explanation!!
Can you als describe please the communication part. I suppose you need a gateway device? And does it need/offers repeaters for longer distances? And is internet required? That kind of questions...
Bart
Zigbee needs at least one coordinator. I use zigbee2mqtt together with an sonoff zigbee 3.0 stick
The amount of devices supported by zigbee2mqtt is impressive.
All mains powered devices should (and in my experience do) act as a router. So zigbee sockets, my wall dimmers or powered light bulbs do the job. I have one zigbee dimmer in most rooms and in the staircase two GU10 ikea downlights (10ā¬ each) are always powered (dimmed / switched) with motion sensors. They act as a backbone. If needed Ikea offers USB charges with an zigbee router integrated or the 10ā¬ socket adapters act as routers too.
No internet connection required everything runs on open-source software (inkl. the firmware on the sonoff stick). My home server is in the basement (worst location ever) but I faced no problems even the old Texas Instruments CC2531 stick worked fine
Here is my current network map
Blue are mains powered routers.You clearly see the rats nest in the center of 4 dimmers, 2 GU10 and one wall socket (powering the Christmas tree) as a backbone. All is self organizing so I did nothing that it looks like this)
(note all the "Bad-Decke-*" Devices are powered off. So they fall back to zigbee2mqtt. They are on the 1st floor and will connect to a nearby router when powered on without noticeable lag)
As mentioned before I use zigbee because of:
- well established and supported standard
- no internet connection possible for devices (all wifi device can "call home" if you don't separate them and know how to do that securely)
- mesh network with wide range but still low power (if you have a decent amount of routers available)
- battery powered devices possible (motion sensor - a allways on device - runs on on CR 2032 for 2 years now)
- thousands of devices available in all favors from cheep Chinese over IKEA up to eve, Schneider electric or Phillips hue. But there are bad devices too, like two OSRAM GU10s. In one the switching power supply failed after 2 days (and went into boot loop disco) . Both regularly missed commands or acted weirdly. So do your research
I only use WIFI in my DIY ESP8266 / ESP32 devices if I can't find a decent zigbee of the shelf one or need my own firmware (like my sprinkler system, my pond control or my indoor greenhouses (rare tropical plants not what you might think 
))
Disclaimer: I do not sell, suggest or promote or anything. I share only my experiences.
3 Likes
Another lesson I learned the hard way:
Choose your coordinator "stick" wisely (choose one of the recommended ones). If you later need to change it you might need to repair all of your devices. This can be painful as many of them has to be placed near (5-10cm) the coordinator (like the IKEA ones) for pairing and have a painful reset / pairing mode procedure (really?)
The sonoff stick works flawless (I got mine for 11,84ā¬ via aliexpress in 10 Days) but I didn't got (and didn't needed) range advantage (20dB instead of 5dB). But the bigger NV-RAM will be and advantage in the future - As far as I know are the routing tables a limiting factor per router / coordinator. As every router brings another routing table this is as far I know only a "worst case scenario" but you never know.
The migration didn't work in my case. I tried hard but failed.
My dimmers and the TRVs can pair over a long distance so I don't think I have to uninstall them and carry them down in the basement (where the 
life) for repairing if necessary.
1 Like
Some way off-topic I know but for anyone using a Drayton Wiser system, I'm finally getting round to creating a proper set of nodes rather than just my somewhat clunky node.js module.
Was prompted by the fact that our Heating and hot water unexpectedly went off on Friday. Thanks to the fact that it appears the boiler is connected to the same electricity circuit as the oven. When that decided that it had had enough of us and kept tripping the circuit breaker, we left it off - until we found that the boiler was also off!
Of course, node-red should have warned my via Telegram - but also of course, it didn't because I hadn't actually created a flow for that!
I'll push the code up to GitHub as soon as I've sorted out the Editor panel and taken out the manual settings.
It will be able to give you information about what has changed between calls to the controller (something that is hard to do as the controller itself doesn't provide that), keeps a copy of all of the current data, has commands to get information summaries such as battery state and room temperatures as well as listing the available commands and events. Has a "listener" node that lets you subscribe to any of the updates and errors. It polls the controller on a default 60s cycle.
Initial version will let you set room mode, required room temperatures or room boosts. Later versions will control schedules.
Let me know if you use a Wiser system and if you want anything specific supporting.
I agree with that. I chose the ElectroLama zzh as the recommended device by Zigbee2MQTT. More expensive but not greatly so given its importance.
Another tip if you choose the sonoff stick. Currently only the sonoff branch of the flash python script supports flashing the firmware without disassembling the stick to get access to the flash button:
python.exe cc2538-bsl.py -p COM3 -evw --bootloader-sonoff-usb latestFirmware.hex
At the risk of going off topic - but a warning!
:lol - Had a similar situation, couldn't get our living room lighting to come on, after 45 minutes wife asked if a wall plug was supposed to be off. One of the Grandkids switched off the socket the Shelly modules were powered by.
Now they are pinged every minute!! I have a 'dot. display on the HMI and Telegram sends a message on any status change. In creating the flow, I found that another WiFi module had an intermittent supply (2 pin into adapter), so it was worth doing anyway!
IoT runs on a BT Hub 5 with OpenWRT firmware on a separate network.
Watching this thread with interest, the Shelly TRV would solve a problem in the way the CH system is plumbed.
Colin J
I prefer ESP devices to report their own status and trigger an MQTT offline topic if they don't respond in a set time.
Unfortunately, the Wiser controller isn't terribly IoT friendly and so I do have to poll it. It was my own fault for never getting round to putting a suitable notification into my flows.
Still, it has prompted me to write a proper Node-RED node for the wiser system which will be much nicer than my original node.js module. 
It already has outputs for when the controller goes offline and online and outputs a different error if the server can't contact its default gateway address (indicating that it is a network problem rather than a controller problem).
2 Likes
The ping was quick and dirty, the MQTT Offline topic needs investigation by me!
1 Like
Yes, its a little tricky to get your head around if you've not tried it. If you have a test device to play with, that's a good way to work it out.
Basically, any MQTT connection can define a "Last Will and Testament" msg. The client defines this but it is sent to the broker. Then, if the client stops sending its ping and other messages for a set time, the broker sends the LWT msg.
Similarly, you can have a "birth" msg. This is sent by the client on a new connection.
So if you set the topics the same for both with an "Offline" and "Online" value respectively, you have an automated way of tracking whether the client device is working and connected.
Not all MQTT client libraries support birth msgs but of course you can simply manually send that out anyway.
2 Likes
Thank you Julian.
I see that Client needs to send message to Broker, and Broker sends LWT if Client 'drops out' rather than disconnecting. Subscribed Clients then get to receive the message. Just working out how to get LWT configured in Shelly and Tasmota, documentation seems sparse. Will start new topic for any help needed.
Sadly, the default Shelly firmware doesn't include LWT/Birth messages. I'm sure Tasmota has LWT.
Worse case is that you use Node-RED to create a synthetic LWT based on regular receipt of some other message from the device to the broker.
I have one of those somewhere - can you provide any info on the flashing ?
It is not difficult, just can be a little daunting as a first time 'experiment'. Once done, updates are easier.
