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