TerryE

@dnb as I mentioned above I was one of the main contributors to the ESP-based NodeMCU-Firmware project which is a Lua based runtime environment that parallels MicroPython. I eventually did a JSH (long-time forum members will get the joke) and stopped contributing because I had an ME/CFS relapse at the time and the project commitments were just taking up too much time and effort that I didn't have the energy for. Anyway back to the point of this. Like Node.js, and NodeMCU Lua, the MicroPython runtime is single-threaded and event-driven in nature. Individual functions run single threaded to completion, so MicroPython makes poor use of the ESP32 multicores and the rich features set of the ESP32 RTOS. For Lua, a lot of the time critical driver code is interrupt driven at a H/W level. I suspect the MicroPython does more inside the Python runtime and hence has more jitters. Incidentally like Mike I've used dozens of high and low level languages in my time (I was even a contributor PHP for a bit, mainly working on Opcache); intellectually Python should be on the preferred ones, but there's something about it that I just don't get on with (I can lump C++ in there too). I like the simplicity and power of Lua, but it just doesn't have the programmer base. All my firmware and driver stuff is done in C still. I like Perl for QnD "hacking", and Javascript / node.js / Node-RED is my preferred platform for IoT and Home Automation.

@MikeSharp01, I am also minded by this wonderful post by @Cooeyswell and to which Jan often refers: "Who the **** is going to fix this **** after your demise?". This is why I now try to avoid doing my own H/W design or firmware development these days. 🤥

Thanks Mike and Jack. For @dpmiller, I note that the board that Mike references uses HLS8L-DC5V-S-C relays which are rated to 10A at up to 30 VDC. Perhaps the main difference between the Pico and ESP32-based boards is that on the ESP-based boards you have a range of options such as Tasmota, ESPEasy (as well full Arduino Runtime and JS, Python and Lua runtimes for higher level scripting) on the Pico for are pretty much constrained to doing your own custom MicroPython firmware development. So for the Pico you have to do firmware development whereas on the ESP you can avoid the need for custom firmware development entirely by using standard OS firmware such as Tasmota which offers and MQTT interface to these type of I/O boards, (as well as having a wider choice of languages/frameworks if you want to go down the custom route). I am comfortable with using custom firmware (I helped develop the Lua runtime for the ESPs, after all) but doing to means that I need to think about long term support options whereas both my son and son-in-law already use Tasmota devices in their own Home Assistant implementations. Here is one example of an equivalent ESP-based 4 channel board that I am considering, and you are spoilt for choice in this space.

An AC load crosses 0V a 100 times per sec. If there is any arcing then the arc will get extinguished after 5 mSec on average, so AC is a lot easier on the contacts that's why relays which support both AC and DC loads will have a max DC load that is typically 10× smaller than the max AC load, so for example the Songle 5VDC coil relays so often found in budget relay boards have a max of 30 VDC vs 250 VAC. Also needing to break DC needs some subtle changes to the contact materials and coil design to minimise risk of cumulative arcing welding the relay contacts closed. Bad news. So the Golden GH-1C-5L relays used in the Sonoff don't have a DC rating and the Sonoff Datasheet therefore specifies AC load only. They would probably work fine given that the switched current is only 50 mA or so, but you would be using then out of manufacturers spec. Not a wise move IMO. The Finder relays that I mentioned an earlier post here draw 50mA coil current at 24 VDC to operate, so using relays to do this is a bit like overkill. Even a basic Darlington diode IC such as the ULN2003A / ULN2803A can drive 7 / 8 channels resp. ( @MikeSharp01 discussed these on an earlier topic linked in my OP), and MOSFETs or reed relays would also switch this fine, but this would involve me going back to my own custom board or some specialist industrial board that would cost a lot more than a basic 4 relay module. Still if anyone has other recommendations then please post. I would appreciate this. BTW the AC Utilisation Categories (AC1 etc.) are a completely different issue and for more on this see the Wikipedia article linked here.

Relays, bloody relays. The Sonoff 4CH PRO R3 unit uses dry contact relays internally, but these are Golden GH-1C-5L relays that are an AC-only design, and so are not rated to drive 24 VDC control logic. ☹️

I run my Home Assistant and the FTP service on an old laptop that I run closed as a server (free battery backup from the laptop battery) using Proxmox as the VM and LXC container host. I could stick a Coral dongle off this.

I've got 3 ReoLink Security Cameras at home. The setup is pretty dumb. They each do simple motion detection and record on a local SD card when the detection fires. The videos are then FTPed to a backup service just in case some thief smashes the camera and takes the evidence. I run a crontab script that purges old data recordings to keep the max FTP share size to a limit (only about 4 days). The biggest triggers are (i) moths and spiders' webs at night (they love the IR), (ii) birds (iii) plants etc. blowing in the breeze. I've never got clever and the thresholds are so low that I will probably miss recording any genuine intruders. 🤣 My son-in-law sets a far looser detection threshold on his cameras and so captures more, but he uses one of these to classify each recording and discard any that doesn't have a person or a moving vehicle in them. The system also picks a good frame to use as a viewing thumbnail of the junk, and he has a nice interface integrated into HA where he can quickly browse these and trash the boring ones. I am still not sure of whether doing the smart postprocessing is worth the hassle. I might get around to doing something like this as a project some day.

I was getting hassled to move this forward and cocked up on the pros and cons of 24 VDC vs 240 VAC. Most relay products totally isolate the coil switch circuit from the line being switched, a.k.a. dry contact or zero-volt contact. The switch itself will have a maximum DC and/or AC switched voltage and current. In the case of AC the load type is also critical as well as the maximum duration of the load. T The issue with devices such as this Shelley and any other power monitoring devices is that the coil circuitry and the switched circuitry are not isolated and share things like a common common so are definitely not dry contact. 😢

@Mike, a Q for you: have you looked at Shelley script yet? As far as I read it the ESP32-based devices such as the 4PRO PM run a firmware build that include a cut-down JS runtime that allows you to do on-device JS scripting (Tutorial) a bit like the ESP32 Lua system that I used to help develop. The main advantage of this as far as I am concerned is that you can add a level of basic on-device safety rules such use "relay X will auto-open X minutes after the last close command". As you say, the form-factor is great and Shelley is manufactured by a Slovenian company so it's CE certification will be solid. These advantages probably outway the lack of OS firmware. My head hurts. 😨 PS. The 4PRO is an ESP8266 device. The latest 4PRO PM model is ESP32 based and runs the Gen2 firmware. I don't need the PM features since all I am doing is switching power relays, but for me the ext £40 is would worth the feature set of the Gen2 firmware. What I am not sure about is switching to 240V control switching

@Mike, thanks I was already aware of this and am monitoring it with interest. I think that Sonoff and Shelley have a somewhat different attitude to OS projects like Tasmota, ESPHome and ESPEasy. Sonoff are fairly open and publish circuits etc., and even application notes such as this on using OS firmware on their products, seeing this as an opportunity to extend their target audience. Shelley are a little more hostile and don't share info and state that using non-Shelley firmware will void their warranty.

I think that it is quite different in scale of impact. In the peak winter months you might need say 40 kWh of heat input into the house at a CoP of somewhere between 3 and 5 so ~10 kWh electricity. The Octopus Agile tariff price today varies from 7.5p to 33p / kWh. That's an over 4× range. You know this 24 hrs in advance and want to be able to schedule the ASHP input across the day to make good use of this, but if you can -- as I can with my current Willis implementation then I see significant cost savings. I currently only have 1 working SunAmp and I just top this up to full at the cheapest rate I can buy. If I think that I am going to run out, I just click a button on my phone and dump another 3 kWh into the SunAmp. OK this might be at a bad time and cost me 50p or so than doing it at the cheapest rate, but who cares? Jan or I only do this maybe half a dozen times a year.

MQTT ?

@Alan Ambrose A good summary, but I also fear that vendor lock-in has a whole range of risks in its own right, especially if the product is using vendor proprietary closed-source applications and firmware. It's over 40 years since I started my career in IT and in that time I've seen dozens of vendors and "best-in-class" product ranges fail and get withdrawn from the market. In my case my test is "what happens if I die or lose my marbles". In my case my elder son and son-in-law both work in IT and automate their own homes using pretty much the same technologies, so could step in or at least provide a soft landing in extremis. Even so, that's why I have split my stuff into two categories: The consumer grade IoT goodies that I control by HA. These are "nice-to-have"s, but if Jan wanted then she could bin the whole lot without impacting her life too much,, as nothing here is critical to lifestyle. The CH and DHW systems. In a sense these are "mission critical", in that life would be grim if they failed even for a few days. It is here that I want to explore if there is a practical and realisable mid-ground; one that could be supported by my sons if needed. Apart from issues of modularity and safety, this is why I suggest splitting out the 240V stuff from the control which should be implemented at 24 VDC or less. The 240V circuit switching should be done by DIN rail mounted devices with the RoHS and BS certification for this use -- something that a typical Part P qualified sparky would be comfortable fitting and signing off. In terms of the "next owner / electrician" such DIN mounted switching devices are simple field-replaceable components, if the owner wishes. In terms of the 24VDC control for these relays, I want a COTS unit that can simply be replaced by a functional equivalent, if necessary. The other thing that is a bit of non-no for me is using a device that has its own closed source firmware, especially if it is "cloud-enabled". I agree with Mike that the Shelly Pro 4PM is a really interesting product but I have real concerns about it's closed-source firmware. That's why I currently prefer the Sonoff equivalent which another ESP32-based device but is Tasmota firmware compatible. In 5 or 10 years either could be simply switched out by whatever the current flavor of device is leading the pack.

Possibly as there no technical reason why you couldn't, but the issue here is volume demand and product availability. Industrial control systems typically use 240VAC or 24VDC so that's what the relay manufacturers target -- at least in the UK -- so it's quite hard to find DIN mounted relays with 5V coils that are rated at 240 VAC / 3000 VA AC1. Most modern micros only drive 3.3V GPIOs, so you still need some form of add-on board to drive 5V. Again because 24V is a de facto standard a lot of add-on boards can drive 24V. For my existing implementation, I did my own prototype based boards which used ESP8266s and custom logic to drive my SSRs at 5V. I want to retire these and switch to COTS boards which support an OS firmware build of something like Tasmota.

HA is flexible, easy to customise and the SW + addons are constantly evolving. Another way of saying this is that it is a bit fragile and upgrades sometime break stuff which is why I have split out my CH+DHW control system onto a minimal Raspbian server booting off an overlayFS and just running Node-RED + MariaDB, for HA. And even with HA, I run that as Proxmox VM so that Proxmox snapshots, backup and restore are available to do fast recovery if an HA upgrade fails. I also run Node-RED, MariaDB, Mosquito and Zigbee2MQTT in their own LXC separate from the HA VM so that my Zigbee sequencing is not dependent on HA being up.

I guess that you'd turn off the ASHP only over the summer, though it might do "maintenance" cycling occasionally. Long off periods might affect the ASHP life so there is possibly a trade-off between the annualised standby cost savings v.v. ASHP life. One thing that you to do need if you want to optimize energy use for an Agile / ToU tariff is to have a good estimate of the actual heat output of the ASHP. AFAIK it is quite easy to track the electrical energy consumption but the actual CoP can very quite dramatically depending on load, external temperature and humidity; current ASHPs don't give you this data. I did consider using an ASHP in without buffer tank but with PHE isolation (rather than a lossless header) as this means that the UFH circuits will be driven with constant head (and therefore flow rate. This mans the the heat input to the slab is directly proportional to the delta T between the out and return temperatures a measured at the manifold. However all my ASHP plans have been put on hold because the ToU electricity pricing has dropped my electricity costs for heating by about 50% so installing an ASHP just isn't cost effective for me.

@Mike, FR building codes are another ballgame. You might want to consider running Mosquitto, MySQL and Node-RED as minimal stack on this RPi. These will all run comfortably on a 2 Gb RPi3. You won't need USB3 class performance for the SSD either. It might be worth running a separate Broker on the separate HA system and ping this with a copy of every relay close / open command. That way you can have an independent watchdog on a separate system to open the relays if the CH+DW RPi dies with the Willis Relays closed. The last thing that you want is for the UFH to run away, though worst case I suppose the Manifold TMV will isolate the Willises from the UFH loops and the Willis thermostats will cut in, but even so a critical RPi failure could leave you with the slab on. Bad news. Far better to have an unattended failsafe reset.

@MikeSharp01, the Finder relays discussed above are fine for switching 3kW AC1 loads such as Willis or Immersion heaters as well as lower power AC7b loads such as your UFH manifold circulation pump. The issue is that these use 24V DC coils, so you need to switch 24V DC from your PRi and this is better done with an external Frontend IoT processor such as one of those listed above. One of the nice features that you can implement with a FEP is failsafe shutdown, for example any relay close command automatically times out after 35 min, so any long duration close must be reissued every 30 mins. This is easy to do in HA or Node-RED, but if the RPi dies when any relay is closed, then it will still timeout and shutdown/open safely rather than staying open (potentially for days) until you can do a manual intervention. The Sonoff 4 port switch does have internal relays but these have a decent spec and will far outlast the power relays as they are only switching ~50 mA to power the main relay coils. I don't think it sensible to switch something like a ASHP directly; better to use one with a MQTT or CANbus I/F to do this programmatically. That Kincoy IoT F/E board above includes a built-in CANbus I/F as well as 24V DC MOSFET drivers. If I was using Wifi for such "mission critical" control then I would configure the RPi to act as a MQTT (Mosquito) host and use the Wifi in Station mode and run a private channel for an IoT LAN for the FEP(s) and any other Tasmota devices needed for control. That way, you'd be independent of the main router and Internet.

@joth yes you are correct, these are two separate facets, but there is a third: it would be nice if I could implement and document this as a standard template that others could adopt / tweak as needed. I already have a mature Node-RED app doing my CH + DHW control, etc. This boots a minimal Raspbian server from an OverlayFS root, but with a USB attached SSD for persistent app data. This also interfaces to my Home Assistant set up via MQTT; I've used HA for years, and in the early days it was pretty flakey hence I settled on this split where the lean dedicated Node-RED CH+DHW system is "mission critical", leaving HA for optional goodies such as driving all of my other IoT devices where the world isn't going to end if they are out for a day or two. All of my house services are hosted locally on my LAN, so nothing will break if I lose WAN access. The CH+DHW RPi currently uses a couple of home-brew ESP8266 boards running Lua Firmware as I/O processors. I want to replace these with COTS H/W running a common firmware app such as Tasmota. And yes, the other aspect is how to switch heavy loads in a safe and ideally low certification overhead way that your typical local sparky would be comfortable wiring up and signing off. As far as the relay switching wear is concerned, yes you make a very valid point. The Finder relays have an electrical cycle life of around 50k cycles at 3 kVA, and an upper bound on my switch rate is maybe 10 open/close per day, so this equates to around 30 years -- which will outlast me. The challenge with SSRs is that they typically have around ½-1 % switching loss which is a lot of heat in a small device when you are switching 3 kW. There is also the double whammy that this loss gets worse as the SSRs heat up. The Crydom SSRs have finned heat sinks but still run at 50+ °C, so you really need fan assisted cooling if in a closed enclosure. If I had to use SSRs again, then I'd switch to the surface mount form factor and bolt them to a bloody large steel plate to act as a heat sink. Out of interest, am I in the right ballpark for my estimated Loxone costs? Thanks.

@ProDave, in our case Jan wants to say goodbye to the SunAmps and on balance I've come to the same conclusion. So we have decided to replace them with an OSO Super Xpress UVC which won't fit in our current CH+DHW services cupboard, and worse the DHW pipe runs will have to go through where my instrumentation panel sits, hence I need to relocate this as well. The plumber can do the G3 certification, but the power circuits currently running to the SunAmps will need rerouted and this technically needs to be installed and certified by a Part P approved sparkie. In England, home owners can no longer self-certify Part P work. The scope of English Part P is all fabric wiring, and yes areas like bathrooms have all sorts of extra safety considerations, but the basic principles remain: the wiring should be safe, and it should not introduce fire risks. This usecase is something that a few members here have raised, so I thought it something worthwhile to discuss first here on the Boffins forum and then write up as a blog post.

I started a related topic, IoT / microcontroller based power switching back in 2019, but a lot has changed in this last 5 years both in terms of the commercial off-the-shelf (COTS) products available to approach this; in my own attitude to doing custom development; and lastly in the actors on the forum that might want to input their thoughts. There is also a steady stream of new members who want to implement this sort of approach. There is a spectrum of options here, so let me list three sweet spots, and what I want to do in this topic is to focus discussions on the last one: A full IoT HA installation. Here I am talking about a Loxone-type system, the sort of installation that @jack has and where you want a soup-to-nuts home automation. This sort of system needs professional installation and certification, so you are probably talking about maybe £5K+ for the kit and another £5K for professional services, so quite an expensive option. Consumer-grade IoT devices. At the other end of the spectrum, there is a huge range of end-user kit and devices that are treated as outside the scope of Part P notification and certification. This area has really blossomed in the last 5 years with the explosion of systems such as the RPi-base Home Assistant, a plethora of ZigBee and Wifi smart devices, many also Alexa and Google Home enabled or with other cloud-service enabled functionality. Technically aware homeowners can use these to do a lot of home automation without falling foul of Part P Building Regulations. However, in terms of power devices whilst the standard UK socket is rated for 13A and can comfortably take this load for short durations, I personally would never leave even a 2kW device plugged into one for long term unattended use. Installation falling with the scope of Part P. In my case I have 3 × 3kW resistive heaters and a UFH pump that I want to control safely and legally, and at a sensible cost (that is without needing to install a Loxone system), but this work definitely needs to integrated in the house's wiring fabric and must comply with Part P requirements. So what are my options for work in this last category? (@ProDave @Nickfromwales and the other relevant trades experts on the forum, I would value your views / sanity-check on what I say here.) First some observations. In my case I have a good relationship with an electrician who did my house wiring and is Part P approved for signing off wiring modifications. He is a good but traditional sparky so I would need any mods to be well within his comfort zone for him to sign off. I am more than happy to leave the 240V stuff for him to do. In his case he is quite happy to wire up components such as relays so long as they come from a reputable UK supplier and have the correct certification paperwork, but he definitely would be a lot more unwilling to put his name to some power connectors sourced directly from China such as the SONOFF Smart Stackable Power Meter range even though these do have proper CE certification, and good build quality. As far as I read it, almost any wiring that is part of the building fabric falls within the scope of Part P. The explicit exemptions include coms wiring such as telephone lines, but even PoE is a grey zone. However, the primary aim of Part P is to ensure Fire and Personal Safety and there is a category Extra Low Voltage (ELV) that covers wiring such as 24V DC circuits,, and the risk here is very low (but still not-zero). The main point for me is that my electrician is a lot more relaxed about 24V (or lower) control circuitry. In my last topic on this, I ended up using DIN rail-mounted 240V 20A Crydom SSRs that are driven by 5V TTL logic to do my power switching, but TBH they have proved a total PITA, as they throw out about 60W waste heat at full load and so they run just so hot, which then causes various thermal problems. In retrospect since I am switching 12A AC1 loads, a decent relay is perfectly good enough such as the Finder 22.21.9.024.4000 are fine for this job and they only chuff out 3W. (AC1 includes straight resistive loads such as immersion heaters. Heavy AC7b loads such as motors or ASHPs are a different ballgame and would probably require using a contactor). These relays are driven by 24DC coils, so I can drive all of my control logic from a single 24DC supply. So how do I implement the 24V DC control circuitry? One option would be to add a MOSFET relay driver hat to an RPi, but my preference would be to stick with a dedicated I/O front-end processor, such as the Kincoy KC868-A8M switch, but my current choice is the Sonoff 4CH Pro R3. Both can run off a 24V supply and can drive 24V DC control logic. Being ESP32-based they both can run standard Open-source Tasmota, ESPHome and ESPEasy firmware builds. All three of these connector apps support MQTT as well as allowing you to set up failsafe watchdogs on any relay open commands. I have more to cover, but I'll break his post here for others to comment. @MikeSharp01, that includes you 🙂

Nick, surely any form of efficient ToU heating should rely on a number of factors: Your house as a system should have a reasonable thermal inertia, passive or active, so that you can decouple the timing of heat input from the largely externally-driven heat losses. This BTW is an intrinsic property of my house design with its passive warm-slab, and 30 cm cellulosic wall insulation: I can pretty much top up the heat in the house at any ToD and the worse that I see in room temperature ripple over the day is ~1 °C. To make use of a ToU tariff you must have some predictive model, say covering the next 24 hrs, of what your input needs are going to be based on an external weather forecast for temperature, and possibly other factors such as sunshine, windspeed, etc. plus a corrective feedback trim depending on the delta between your target average room temp, and the historic actual temp over the last 24 hours, say. For us the external temp forecast and a trim correction works fine. If you are using resistive heating then relating heat requirements to electrical input is trivial, but with ASHP you will need a reasonable CoP predictor based on external weather etc. so that you can map your predicted heat requirements to electricity input. I do this type of modelling automatically at 11PM each night and then use the Octopus Agile tariff for the next 24 hours to allocate an optimum heating plan for the coming day. So here was my Agile cost for Christmas Day. OK, we were visiting my daughter and family so this was a "sustain day" where the system was only maintaining the house and HW temperatures, but the 23 kWh the system used only cost me 37p.

Nick, really interesting stuff but I am a little confused about how this relates to "Running an ASHP on a ToU tariff". Perhaps you could link the dots for this old dummy?

Mike, you can get refurbed 8Gb Lenovo M73 Minis for £50-100 on eBay. Set it up as a ProxMox host and run the HA VM on that.

I use a little star connection board with 3 pin connectors one-per-thermo, and run the individual OW thermometers back to this. IIRC, I had to bump the pull-up resistor to get it stable.