Microcontroller based power switching revisited in 2024

[MikeSharp01]

9 hours ago, SteamyTea said:

Do they want a little project as I have just about given up getting my Python scripts to read my MLX90614s.

(can post the kits if needed)

They are already kicked off on their projects, if only I had known in December we could have arranged that.

[SteamyTea]

Just now, MikeSharp01 said:

They are already kicked off on their projects

Most of them won't have started yet.  What Easter break is for.

[MikeSharp01]

1 minute ago, SteamyTea said:

Most of them won't have started yet.  What Easter break is for.

Don't be daft I have been seeing my dissertation students all year and the Easter break is after their hand in - its cruel out there these days!

 

 

 

[SteamyTea]

11 minutes ago, MikeSharp01 said:

I have been seeing my dissertation students all year

Does it take them that long to learn a few punctuation marks

 

() : .     ==! 

 

You can see why I can't get it to work.

Edited February 2 by SteamyTea

[TerryE]

I've now got the 4-relay ESP32 board that I discussed in an earlier post.  I've still to test it out, but the general design and build quality is very good.  I bought it on Amazon with Amazon delivery for ~£50.  The same board is available form AliExpress (plus other variants and options) for around half that, but on a ~2 week delivery.

 

It comes with a pre-installed Tasmota firmware that was vendor-built and configured to its hardware setup.  This build includes some components that I don't want (e.g. Alexa integration) and missing some that I do (e.g. the on-device simple scripting).  Nonetheless, it is easily usable out "of the box", so a good way to get started.  However, there is quite a learning curve to being able to build your own custom Tasmota binaries -- enough to deter me and I have a lot of experience of building custom ESP8266 and ESP32 binaries, so I guess that only a few % of board users would be confident to go down this path.

 

The other main OS firmware route is to use ESPHome.  It's strengths and weaknesses pretty much compliment and contrast those of Tasmota: you can't get prebuilt standard binaries for ESPhome, so you need to configure and build your own.  However, because everyone has to do this, the whole process is a lot slicker and simpler.  If you use Home Assistant, then a couple of clicks will install the ESPHome add-on and this adds a docker container to HA that includes a complete build environment.  You configure each ESPHome device through a YAML file that follows the HA configuration guidelines, and the add-on includes a Python script that converts this YAML and orchestrates the device firmware build.  So doing these builds is pretty pain-free.  

 

For this board, the vendor even provides a step-by-step guide on how to configure their boards under HA.

 

By default ESPHome connects back to HA and even uses this connection and a health heartbeat, so the board will enter a safe (all relays copen) state if HA dies for more than a configurable timeout.  However this is also configurable and you can run the firmware with optional or no HA integration.  It is also trivial to add simple interlock and other scripting rules.  I will add an update when I have this all working.

 

 

Edited February 5 by TerryE

[TerryE]

On 05/02/2024 at 14:18, TerryE said:

This build includes some components that I don't want (e.g. Alexa integration) and missing some that I do (e.g. the on-device simple scripting).

 

This wrong on both accounts.  All ESP32 binaries include Berry scripting by default, and Alexa integration is disabled by default, though it is configurable.

 

I've just used the out-of-the box Tasmota to wire and test the control path.

Edited February 8 by TerryE

[SteamyTea]

Can you get an ESP32 with a built in micro SD card slot?

[TerryE]

7 minutes ago, SteamyTea said:

Can you get an ESP32 with a built in micro SD card slot?

 

The ESP chip (wiki article) supports microSD (via Quad and Octa SPI) as well PSRAM.  A lot of boards either have an SD slot of module or as an addon.  However you don't need it for most use cases because the firmware is loaded from FLASH, and there is typically a small FlashFS that is used for configuration data.

 

Most standard firmware such as ESPHome and Tasmota just post to MQTT and leave it to another client listener to log the data.  You'd really need to start using MicroPython, Lua or Arduino development to make use of on-module storage.    

[TerryE]

On 08/02/2024 at 18:20, TerryE said:

All [Tasmota] ESP32 binaries include Berry scripting by default

 

I've now had a chance to look at this in more detail.  Berry is a fully featured scripting language that is comparable to Javascript, MicroPython and Lua. The language is Python like except that is uses lexical scoping (blocks are terminated with an end keyword like Lua),  rather than indent scoping.  It was initially developed by a Chinese developer, Guan Wenliang (Github: skiar)  2018-2020, with the Tasmota port largely done by another Tasmota developer,  (Github: s-hadinge), though Wenliang is still actively involved.

 

Looks pretty good but yet another language to learn.  The runtime  (under 50Kb) is similar to NodeMCU Lua, and it has got a lot of the IoT friendly features that we added to NodeMCU Lua, such as read-only objects are memory-mapped from ROM so that only true RW variable content gets stored in RAM. 

 

Perhaps the main difference is that Tasmota provides the core API, MQTT and WebUI asn well as all of the I/O device support so you only need to use Berry for event-based triggers etc.

 

Edited February 9 by TerryE

[TerryE]

Better and better.  What does Elon Musk say? "The best part is no part".  I don't need to use Berry at all for what I want to do.  Here is a Node-RED snippet that cycles around the relays turning each on for a defined duration with a 2 second gap between

 

 

The test1 function posts a set of messages to my cmnd/CHrelays/BACKLOG0 topic.  Backlog0 is just a way to do multiple Tasmota commands atomically; PulseTime1 and Power1 set the on-time and power state for relay 1 etc.

 

const DUR=12, N=4;
return [[...Array(N).keys()].map(i=>({
    delay: i*(DUR+2)*1000,
    payload: `PulseTime${i+1} ${100+DUR}; Power${i+1} 1`
}))];

 

[TerryE]

On 31/01/2024 at 12:55, TerryE said:

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.

If you are willing to wait for ~4 wks shipping delay then you can get these direct from the supplier's AliExpress store here at about half the cost of the UK agent through Amazon Prime.  Note that there are various options:

• Internal or external antenna.  In most inside uses the internal variant will work fine.
• Bare board. or with case.
• Two power in variants: 90-240 VAC or 7-36VDC.
• Two ESP32 variants: 4Mb Flash or 16Mb Flash + 8MMb PSRAM.  Tasmota will run on happily on the first.  The second is really only needed if you are doing serious embedded app development on the board e.g. using Berry or reflashing with MicroPython, etc.

 If you need to control more than 4 devices, then there is also an 8-relay extender module.

 

I am using 4Mb Flash version powered by 24 VDC and have ordered a second for spare / testing.  

[TerryE]

Thanks everyone,  @dnb @jack @joth @Mike @MikeSharp01 @ProDave @SteamyTea for your input and advice.   I think I am happy with the solution that I've picked and I will write it all up as a blog post when done.

 

Throughout my build, I must have had maybe 10 or so brainstorming topics from building issues, to plumbing and CH, to home automation where discussing the specific issue in depth with knowledgeable members of our community has enabled to to get my thoughts in order and come up with an effective solution to each of these issues.  This has saved me a ton of grief, and TBH a lot of wasted cost and avoided rework.  In return I do the Sysadmin to keep the forum running smoothly, but this is still a good deal as far as I am concerned.

I've also rescanned the posts to see if I've left and dangling points that I want to pick up on. It is indirectly related to joth's comment, though I also want to respond to this.

  

On 27/01/2024 at 10:12, joth said:

I totally agree the single vendor lock-in is worrisome vs open source, but on the flip side I can leave a miniserver running for 12 months and it looks after itself, whereas with any OSS you need great hygiene on admin work: taking backups and applying security updates (to OS and apps) etc and dealing with the fallout when stuff then breaks. T

 

IMO one bain of budget home automation is the unintended consequences of service dependencies on critic network management functions.   For example if you are using IP services and stack as core components then your devices can depend on services such as DHCP, DNS, NTP to work and may fail if these aren't working.

 

In my case here for example, you need to make sure that everything can restart gracefully after an unscheduled power outage, and in my case I have sorted out service dependencies so that this happens.  But what happens if a critical component such as the main home router fails to restart successfully, then what cascade failures can occur?    Losing the Internet is a hassle, but we can live with this for a few days.  However, losing my CH and DHW systems for a few days during winter would be grim.

 

I think this issue merits a Boffin's topic in its own right, so I will defer further discussion to that.

 

As to the specifics of security vulnerabilities etc. I am a bit more sanguine (maybe falsely so), because I am a reasonably experienced sysadmin.  My home network is pretty well locked down, as I only present my VPN, HTTPS and cert only SSH on the Internet and these are served from pretty locked down LXCs.  I don't use any application cloud services for home automation etc. as everything is served locally.  My LXCs typically run minimal Alpine stacks which only run the internal services needed to support their function.  My CH+HW control runs on its own dedicated RPI which runs a minimal server software stack needed to support its core function, and boots from a read-only OverlayFS.  I typically update this about once / year at the same time as I do functional changes.

 

[Bramco]

4 hours ago, TerryE said:

Losing the Internet is a hassle, but we can live with this for a few days.  However, losing my CH and DHW systems for a few days during winter would be grim.

 

Per-empting a new Boffin's topic Terry, a lot of non sysadmin folks have to rely on off the shelf solutions and often won't realise what the impact of an internet outage or a router failure would be until it happens.  There's a lot to be said for making sure that you aren't relying on cloud based services for critical functions like the CH and DHW.  Having said that, most suppliers aren't stupid and have built their systems so that they will continue to function if there is an issue with the internet/cloud. So apps are there to report on what's happening with the system and to alter settings etc. not to do the real time control.

 

Our CH system which is managed by the ASHP controller and by thermostats would continue to run even if the internet was down. Similarly, the Battery/PV inverter and the PV diverter would also continue to run. OK, I wouldn't be able to use their apps to see the system status or to change any settings but I could get off my backside and go to each of the controllers to make the changes on the device in question.

 

Where we might have a problem is that we use Google Assistant to switch on some lights at dusk and with a spoken command to turn them off at night.  I don't think this would work without the internet connection, so we use Sonoff wifi and zigbee switches in the back boxes behind the switches, so we can always walk round and turn things on and off even if Google Assistant can't do the switching.

 

So I guess generic advice would be to check everything that is automated with standard parts to make sure it will work even if the internet isn't available and for anything that won't, make sure that you have a backup in place, like properly wired light switches.

 

Simon

 

PS Look forward to further discussion in Boffins corner when you make a start.

 

 

Edited February 13 by Bramco

[MikeSharp01]

9 hours ago, TerryE said:

IMO one bain of budget home automation is the unintended consequences of service dependencies on critic network management functions.   For example if you are using IP services and stack as core components then your devices can depend on services such as DHCP, DNS, NTP to work and may fail if these aren't working.

This is classic systems of systems (SoS) territory which tells us that we are involved with an SoS when any two of the systems in the putative SoS have managerial and operational independence. (Maier 1998) It means one of three things which have already been discussed - 1. You need to keep up or 2. Do it all yourself or 3. Some combination of both! I guess its about picking your battles as you cannot avoid it all. Silly little things like a company going bust or the main developer of a product loosing interest in it. No recourse to the developer is also an issue in SoS because most of us have no control of the developer / operator and they are always on the lookout for ways to monetize the offer. Twitter used to have a free API that let you read Tweets all day long - now its paid and rate limited. Most of us, including big corporations who rely on the technology of others are in the same boat we are - no recourse and with vastly expensive teams just keeping up.

 

Even some 'open source' stuff has a no recourse philosophy - Tasmota has this risk, it says on their web site that "Tasmota is not a commercial product and support is limited. You have to be willing to research and solve potential problems yourself." So even there you are likely as not to have to make modifications that only you will be able to follow or you get involved with the development team to support your own ideas until life expires. Node-Red very clever but it's life is limited as is USB - how much do you rely on USB?.

 

In any eco system there is a carrying capacity the system has and we can track it with the S curve and with the S curve, well when one technology looks to supersede another, comes the two opposing mentalities - the defender and the attacker.

 

The defender thinks their technology is fine, that they can change quickly if something challenges, we know the competition and anyway who would challenge such a well found system - Bonkers. Meanwhile the attacker has a hill to climb to get the innovators and early adopters across onto the S curve they think can beat the status quo and make them rich. Knowing when to dump all your investment, and believe me investment challenges change - big time, in a technology and get with the new one is a fine art, fraught with risk - loads of new S curves go nowhere, and it can be expensive. 

 

Personally I am hoping to keep it basically bomb proof by avoiding as many bear traps as I can while being fully aware I cannot avoid still having enough of them to wipe out a lot of bears and have fun playing with ideas while my mind is up to it.

 

So the wiring is all traditional everywhere and at the flick of a din mounted lever isolator you can switch out the computer and connect the switch directly to the lamp - yes you get full brightness but hey you don't need to maintain the DMX dimmer, the RPi server, the switch monitoring circuitry and host of other bits and pieces.  I hope to use this approach everywhere I can - as an old friend - Bill, now departed, was fond of saying - 'Mike it's supposed to be F.U.N' lets just have fun. 

 

Maier, Mark W, Architecting principles for systems-of-systems, Systems Engineering Journal, 1998

[TerryE]

I've been burnt by a mindfart when wiring up the new UVC installation -- or at least decommissioning the previous 5V switched SSRs box because the UVC pipe runs have to go along where it is mounted  I've been reusing the existing dedicated redials but repurposing some of them.  Unfortunately they were wired 2 + 1 onto the two sides of the consumer unit (protected by separate RCBs), so the Neutrals were wired likewise 2+1 -- except that I swapped the role of one of the cables so that a LH Live was returning to a RH Neutral.  Powering it up trips both RCBs.  Duurrrrhhh!  Idiot.  A quick shuffle fixed this.  LH is LH and RH is RH now.

 

It struck me that you could easily fall into the same bearpit with the power monitoring multi-relay boards such as the Shelley and Sonoff ones as these are wet contact. 

 

Edited March 13 by TerryE

[TerryE]

So here is what my CH / UVC Immersion control setup looks like finished:

 

The RH Consumer Unit is as-installed by my electrician.   I've repurposed some of the circuits:

• CH, SunAmp 1, SunAmp 2 → Immersion 1, CH, Immersion 2

(I swapped the CH to the 20A circuit, though this could be downrated to 16A.)  These radials are routed through to the adjacent small CH on the left.  This contains AC→24VDC and 4 Finder 240V / 20A relays(UFH Pump, Willis, Imm1, Imm2).  These 4 run radials to fused DP wall plates, and on to the pump / heaters. 

 

The small box underneath the relays is a commercial off-the shelf unit discussed in a previous post the runs on 24 VDC and switches the 24VDC input used to control the power relays.  This runs standard Tasmota Software (albeit configured with a local autoexec to add a local rule that forces the Willis to turn off (if on) whenever the pump is turned off).  The Tasmota firmware is controllable via MQTT.

 

Incidentally above the CU are my BT Infiniband modem, 100Mb Enet patch panel and Wifi hub (this meshes with 3 other Wifi APs to give strong 54Mb Wifi on the 1st and 2nd floors and garden.

 

The CH+DHW upper control used to be hosted in the RPi3 to the right of my Wifi hub, but it is now run on a virtual container on my home Proxmox server (a repurposed Lenovo Laptop which sits on a shelf in the service cupboard that contain my DHW+CH manifolds and used to contain my SunAmps). A bit like a NUC, but with built-in battery backup.  It just sits there always closed, as I manage everything over my LAN using SSH and the Proxmox Portal.  This hosts a VM running Home Assistant, and currently 8 other containers (LXCs) including Pihole, VPN Portal, IoT stack (MySQL, NodeRED, Mosquitto MQTT server, Zigbee2MQTT), an FTP service for my external cameras, a couple of web-servers and 2 test containers. 

  

 

Above it, the small box is one of my DS18B20 IoT devices, but more of that on a separate post.

 

Edited April 3 by TerryE

[TerryE]

A quick update.  The system has been working well (subject to the caveats below) for over 3 months now.  I've stripped out and refined the Node-RED application, and am reasonably happy with it, but a few lessons learnt:

• I have now retired all of my custom ESP code.  I use ESPhome for my Wemos D1 mini based temperature loggers using One-Wire DS18B20s controlled by the ESP8266  chip.  ESPhome just proved the easiest way to configure these and the pre-built environment is available as a Home Assistant add-in.  The relay controller uses Tasmota, though I am considering switching to ESPHome, but am not sure whether this is worth the hassle.
   
• The UVC heating algorithm works really well: once a day I use the average cylinder temperature (from the top and bottom DS18B20s) to heat it to target.  The CH system then schedules this top-up at the cheapest time slots. The relays are powered off early if the top/bottom is at target temperature.  For example, today's top-up was 1.3 kWh at a price of~ (-3p) credit.
   
• The Finder coils are about 0.5H inductance, so the relay contact opens are particularly hard on the little Songle relays on the ESP32 relay board.  Even though they have a nominal electrical life of 100K cycles, the one controlling the circulation pump failed the other day.  I think that I really need to add RC snubbers across the finder coil contacts to get a decent operating life.  Doing the math, the capacitor needs to be ~ 0.3μF and the resistor 1.3 kΩ.  Most pre-made snubbers seem to be designed for 230VAC rather than 24DC.
   
• I killed one finder relay myself as a typo on a small change I was testing.  I accidentally set the relay in blink mode (where it was cycling every second).  Unfortunately, Jan interrupted this with a demand that we leave to go out for the day and I didn't get back and discover this cock-up some 10 hours later.  In the meantime the relay was buzzing like a chainsaw, and by the time I realised I'd worn the poor thing out. Scratch one power relay.
   
• The Finder 22 Series relays do not handle AC7b loads well even a 30W.  I am currently cycling my pump 48 times a day or ~1.5K times a month.  5K cycles at this load has already knackered the power relay controlling it.  I really need to move to a contactor which might increase the snubbing requirement or back to an SSR for controlling this pump. 

 

Edited July 5 by TerryE

[dpmiller]

have you not got a diode across the 24V coils?

[SteamyTea]

For others that may wonder what a Snubber is, or like me, what it does and how.

https://eepower.com/technical-articles/snubber-network-choices-design-and-evaluation/

 

It is really just a bucket with a hole in it, and a one way valve, that can deal with a variable input and produce a steady, but limited, output, without overflowing.

[MikeSharp01]

6 hours ago, TerryE said:

I really need to move to a contactor

Are the Finder 22 series not already classed as contactors? Snubber sounds like a good idea all the same.

[MikeSharp01]

6 hours ago, TerryE said:

I use ESPhome for my Wemos D1 mini based temperature loggers

Wish there was an RpiHOME equivalent of this - I know there are some initiatives out there but it would be good to support our local listed company!

[TerryE]

10 hours ago, dpmiller said:

have you not got a diode across the 24V coils?

 

Precisely.  And the answer is no, not at the moment 😱 but I should have a freewheeling diode across the control contacts of each.  Do the math and Finder relay coil stores about 0.6mJ of energy when closed and as soon as the Sonder relay opens this coil field collapses creating a flyback voltage in the kV range at its contacts which will rapidly degrade the relay. Probably don't need an RC snubber with a freewheeling diode (something like the 1N4007 which are orderable in 5 off quantities from Farnell etc. for pence).

 

What I hate about this was that I really wanted to avoid customise tweaks. I really wanted a compute off-the -shelf module.  I have found a for ~£200 from an AliExpress supplier I've used before but it has  32 channels and is really overkill.  

 

11 hours ago, MikeSharp01 said:

Are the Finder 22 series not already classed as contactors?

 

No the 22.20s are power relays really designed for straight AC1 resistive loads like the immersion heaters. The 22.32s have sensible AC7a rating but the profile is slightly different so I need to check that they fit in my enclosure.

 

If anyone have setter advice then I am more than willing to listen. 

[MikeSharp01]

12 hours ago, TerryE said:

No the 22.20s are power relays really designed for straight AC1 resistive loads like the immersion heaters.

Ah, sorry - it was just I had used a couple of these: https://www.findernet.com/en/croatia/series/22-series-modular-contactors-25-40-63a/ and they may fit in your enclosure. Also f you want off the shelf then you could use a din rail mounted diode setup like this one https://cpc.farnell.com/camdenboss/cim-4w-dioca/4-way-diode-35mm-din-rail-module-common-anode/dp/mc02830?srsltid=AfmBOooS2bLnk8DoI0qYraRRMra3jWc8mtBLjb2h384Kn1RY4MJeeKtCecQ and just wire the diodes across the contacts.

 

 

 

[TerryE]

On 06/07/2024 at 07:07, MikeSharp01 said:

Wish there was an RpiHOME equivalent of this - I know there are some initiatives out there but it would be good to support our local listed company!

 

Mike, it's nice to give back on this one.  ESPhome does now support the Pico W.  See ESPhome - Raspberry Pico W.  The ESPhome environment is layered over RTOS, so I assumes this is just a port of their RTOS build.

 

The standard ESPHome dev environment typically runs in a docker container -- either via the Home Assistant add-on or a standard docker container from the Docker Library running under Docker.  This is just a builder WebUI using a load of Python scripts to wrap around the make environment.   I find it easy to use.  I like it.

 

You configure the particular device using a YAML file which can include C encoded actions using the "lamba" nodes.  It's all pretty straightforward once you are past the initial learning curve.  Update is normally via OTA, so if you need to tweak a config, then you just edit the YAML file and hit deploy.  The build and update takes less than a minute.  If you want to discuss further then why not spin off a specific ESPhome (on Pico) topic?

 

PS.  The Pi Hut 8-relay board that you linked to has a similar form factor to the ESP one that I suggested, but you would need to mod the case slightly to take the external Wifi antenna.  Pi Hut also sells a 4 relay version.

 

It's a pity that I can't find a proper 24VDC relay driver board / hat for the Pico or ESP32.  I see that some designs use PWM relay drivers with RC smoothing and flyback protection.  The idea here is that you set the op to 100% for 50 mSec for force contact close then drop the PWM to 50% dropping the smoothed voltage to ~ 12V which is enough to keep the contactor closed but only a ¼ of the power loss in the relay and if you don't need sharp one, then drop the PWM ratio to 0 over 100 mSec, say, which pretty much dissipates the coil energy before open.

 

Anyone know of / recommend such a off-the-shelf board?

 

PPS.  ESPhome can be configured to act as I/O subsystem for HA or work independent of HA using MQTT as its command interface.

 

   

Edited July 7 by TerryE

[TerryE]

8 hours ago, MikeSharp01 said:

Ah, sorry - it was just I had used a couple of these ... Finder 22 series contactors.

The 20A Power Relay and the 25A Contactor are pretty much identical in form factor.  The contact is far more robust and only about 20% more expensive.

 

I'll just buy 10 1N4007s and make up my own flyback straps.