[gregoryx]

You guys are killing me. The shelly stuff all looks great, but it is a lot of new, to me, tech that I can completely bypass by loading ESPHome firmware to do what I want. Its easy, very little code (yaml) ultra reliable and feeds directly into HASS w/o any further ado. That said, now that I understand the "light" profile I'll be looking at the HASS integration before going the ESPHome route.

I am just sort of playing with this stuff. I already have a working relay based RPi3 system. I am re-hosting HASS on a RPi5 with LCD screen and it doesn't really support the relay shield (mechanically) so I'm mostly looking at replacing it with the shelly rgbw physically away from the main logic. It is likely never to be placed into permanent service, so, in reality just play-time/science project. In any case I'll report on the results after I get things running.

Certainly moving away from the RPI3 for relays makes sense. Far more power-demand than necessary for that function. And certainly nothing wrong with using RGBW with ESPHome code; just that it has some pretty good functions built-in to the firmware and likely worth at least trying it first. You're not talking to folks unfamiliar or uncomfortable with the necessary YAML; but a few of us are familiar with both and would recommend at least trying it.

Alternatively / additionally, sure sounds like you'd be well served with an ESP32-based board with as many relays as you like on it.

I'm still pondering how to build a single board (or more convenient modular setup) to combine relays and power-monitoring for every individual circuit / load in the van. I have a lot of them covered now and will soon get the rest; but for the next van, a single board with a single ESP32 "brain" handling 30-ish circuits of monitoring and control would be awesome... though I'll keep using RGBWs for lights most likely.


What's your goal / expectation for non-HASS controls? Hard switches? Any cross-connectivity between RGBWs? Or just direct manual switches in 4x4 per unit? I assume you're planning something hard-wired to avoid the situation you have now?

 

[larry barello]

What's your goal / expectation for non-HASS controls? Hard switches? Any cross-connectivity between RGBWs? Or just direct manual switches in 4x4 per unit? I assume you're planning something hard-wired to avoid the situation you have now?

Simple arrangement for me, local pushbutton on/off with viewing status and override via hass dashboard.

I only have three or four loads that could benefit from this arrangement. Everything else is in automation that is irrelevant if the server is down or something that manual switch is more than adequate like overhead lights.

 

[larry barello]

So, after knocking off a few other projects, I get back to the Shelly. The RGBW is a fantastic doodad, but it natively doesn't do what I want. Do you suppose I could ask Shelly to add "relay" mode to the output and then "toggle" mode to the pushbutton input?

The shelly 1, of course, is very simple and does what I want. But I am really keen on trying the RGBW idea.

Is there a way to restore a shelly to the original firmware after hacking with ESPHome?

 

[Irontent]

So, after knocking off a few other projects, I get back to the Shelly. The RGBW is a fantastic doodad, but it natively doesn't do what I want. Do you suppose I could ask Shelly to add "relay" mode to the output and then "toggle" mode to the pushbutton input?

The shelly 1, of course, is very simple and does what I want. But I am really keen on trying the RGBW idea.

Is there a way to restore a shelly to the original firmware after hacking with ESPHome?

The challenge with reflashing the original Shelly Firmware is obtaining It. There is a site in Germany which has some older code-loads, but I haven’t found a source of the most current firmware for the gen 2 and gen 3 devices. If you find a source, please let us know.

 

[BadWolf]

If you want a real low power relay solution i found an 8 relay hat.(3amp limit per relay)

Requires HACS for the gpio program but then it was just a few lines of code in the config yaml

Not on amazon anymore.

8 SPST-NO RPi IoT Power Relay... Amazon.com

 

[larry barello]

My system uses a 4 relay hat with the legacy gpio solution (same as yours). The relays are rated 10a and the largest load is 3a, for the starlink voltage converter. I daisy chain one to a 40a auto relay for my solar disconnect. The only other "load" is heater pads for the batteries (self heated batteries didn't exist when I built my van in 2020) that draw another 2-3 A, the other two loads are negligible. The individual and total loads are all well within the limits of the Shelly RGBW.

My project is taking an RPI 5-based OLED display using raspberry os hosting containerized home assistant and AppDamon and using that as a wall display as well as my controller. It will be physically removed from my electrical panel which is where I put the Shelly(s). I could hook it up to my existing relay hat but it require a 40 pin ribbon cable (Well, I only really need 6 conductors) which I do not want to do. Hence looking at the Shelly RGBW as a wireless low power replacement

I may abandon this project after I get it working for a variety of reasons and go back to the RPI 3 based appliance and a low power tablet for the display (in addition to my Android Radio head unit). The primary reason being I don't want to go through the effort to figure out wireless RS485 connection to my Renogy equipment in the electrical Bay and running a long USB cable back from the controller to the equipment bay kind of defeats the point.

Anyway the 1.27mm .4mm pin headers came in yesterday. A touch of solder and I should be ready to flash the RGBW. Whoohoo.

 

[BadWolf]

It’s not as low power as the shelly, but im testing out one of the newer waveshares, with 6x 10a ports. Esphome setup was quick, and easy.

Amazon.com: Waveshare Industrial 6-Channel ESP32-S3 WiFi Relay Module, Supports WiFi/Bluetooth/RS485 Control, Onboard RS485 / Pico HAT Interfaces, with Multiple Isolation Protection Circuits : Electronics

Amazon.com: Waveshare Industrial 6-Channel ESP32-S3 WiFi Relay Module, Supports WiFi/Bluetooth/RS485 Control, Onboard RS485 / Pico HAT Interfaces, with Multiple Isolation Protection Circuits : Electronics

a.co

Currently im switching from having all my wires/relays in my main power spot to little distribution spots in the galley/shower/office areas. It really cleaned up the wiring, simpler to troubleshoot and lowered the voltage drops significantly. A pair of 6awg vs a bundle of 12awg to each area.

i found these 8 spot fuse holes (100a/30a) great for pairing with the 6 port waveshare. Gives 6 fuses for the relays, one to power the wave and a spare. Having all the power out on one side makes the wire condensed and clean.

Rebuild Skills 8-Circuit Fuse Block: Universal Power Distribution for Vehicles & Boats | Waterproof Marine Grade | Easy Installation & Enhanced Safety | Ideal for Lights, Radios, GPS: Amazon.com: Tools & Home Improvement

Rebuild Skills 8-Circuit Fuse Block: Universal Power Distribution for Vehicles & Boats | Waterproof Marine Grade | Easy Installation & Enhanced Safety | Ideal for Lights, Radios, GPS: Amazon.com: Tools & Home Improvement

a.co

 

[gregoryx]

...
i found these 8 spot fuse holes (100a/30a) great for pairing with the 6 port waveshare. Gives 6 fuses for the relays, one to power the wave and a spare. Having all the power out on one side makes the wire condensed and clean.
...

With you on the distribution portion... but I'd want the fuses after the Waveshare... no? I suppose since it's a closed circuit when active it's prolly fine... but seems like the fuses should be on the output side. 🤔

 

[BadWolf]

With you on the distribution portion... but I'd want the fuses after the Waveshare... no? I suppose since it's a closed circuit when active it's prolly fine... but seems like the fuses should be on the output side. 🤔

All the fuses are below the 30a limit of the relays, most are sub 15a. Id hope the fuse blows first.

Correct me if im wrong but putting the fuse before the relay also protect it?

 

[gregoryx]

All the fuses are below the 30a limit of the relays, most are sub 15a. Id hope the fuse blows first.

Correct me if im wrong but putting the fuse before the relay also protect it?

The mantra I'm always replaying is, "fuses protect the wire, not the load." Helps remind me that the fuse is sometimes larger than the load - especially if I'm over-sizing the wire to reduce voltage sag. I don't bother with fuses in super short wire-runs where little-to-nothing could go wrong with the wire (like the panel for our loads - no fuses mid-connections). Then I want the fuse as close to the source (not the load) as possible to the largest length of the wire is protected.

That's all just the thought-process I regularly remind myself. Is it correct? Not sure. But it seems to be?

In the event that a wire gets shorted somehow in the way you've got the layout, I assume it'd pop the fuse once the relay is closed - so probably fine. But it still violates my concept of best-practice. That's why all the automated stuff I keep doing has moved me away from distribution-style fuse-blocks to individual blocks, where each fuse is an isolated pass-through.

It's certainly a bit more troublesome... but seems more appropriate?

Here's the empty fuse holder setup for the panel I built. The fuses are the last thing before heading to the loads.

But no fuses between the distribution / bus-bars and the meter-board nor the relay-board. I figure the most likely thing to go wrong there is me moving wires around, as I did a couple times: the over-populated bus-bar is 12VDC; the under-populated one is 24VDC; I moved a couple things one way or the other.

Similar setup on lights: a fuse per leg; initially, the hot legs were unique and negatives were tied; then it got switched around when I went to the Shelly RGBW-PM units. The essence is the same: a fuse at the earliest point of the +12VDC legs (the upper left box with labels on it).

Maybe I'm just over-killing or over-thinking it? or even just off-track? 🤔

 

[BadWolf]

This was the first setup version under the sink on the underside of the galley shelf, i was trying a kinda 8 port that worked until esp 6.0 came out and now the d1 mini won’t talk to the relay.

 

[gregoryx]

... now the d1 mini won’t talk to the relay.

That's not good... 🤔

 

[KRK]

Just thought I'd mention it in this thread - I was looking for a HEPA/carbon air filter that would reasonably fit in the van, and came upon this tutorial that shows how to modify an Ikea unit to work with ESPHome and Home Assistant. That unit also takes 24V, it seems - perfect for my 24V system. Good addition to the van HA ecosystem, I think? Kind of like the MaxxAir mod, except without the Darlington array or relays - just wires directly to the D1 mini, so simpler to do and no custom PCB needed. Not sure if that's kosher, but seems to work? Ordered one to try.

IKEA FÖRNUFTIG in Home-Assistant

Hi there! Just wanted to show you how I integrated the air purifier into Home-Assistant. Now I’m able to adjust the fan speed, switch it off and on and also see if I need to replace the filter. Inspired by https://www.reddit.com/r/ikeahacks/comments/m0rdlw/förnuftig_but_it_has_rest_api/. Just to...

community.home-assistant.io

 

[Tuckie]

Interesting idea. Personally, I've been tempted to add/design a hepa filter between the blower and condenser on my undermount ac unit.

 

[larry barello]

Uh, I have an ESPHome technical question. I flashed the Shelly RGBW and everything came up roses, but...

(Doh, the output is simply a FET to ground.)
1. The outputs, shown in the web page, are functional and the switch inputs toggle the output BUT I get no output! They are all floating. The samples and documentation are pretty clear:
switch:
- platform: gpio
pin: GPIO25
name: output 1
id: output1

{bad wiring)
2. Got into the bootloader the first time and have been doing OTA since, but I cannot seem to get into the bootloader anymore. Again, this is really straightforward, so I am a bit confused. Is this something special about the RGBW that I was unaware of? I am concerned about this since, on occasion, I have needed to load via the serial when I load bad firmware

 

[Captadv]

I wanted to share another way to organize your configuration files. I used to use a single mqtt config file and imported it into configuration.yaml. Well that was starting to be too big so I've broken all the MQTT sections (binary_sensory, number, sensor, switch (i don't have any mqtt switches)) down into folders and then organized by devices.

This is what is in my configuration.yaml

mqtt:
binary_sensor: !include_dir_merge_list config_mqtt/binary_sensor/
number: !include_dir_merge_list config_mqtt/number
select: !include_dir_merge_list config_mqtt/select
sensor: !include_dir_merge_list config_mqtt/sensor/
switch: !include_dir_merge_list config_mqtt/switch

And then this is what all my files look like on the HA filesystem.

As you can see, I have more MQTT devices than just Victron' stuff. I find this much easier to manage. Hope it helps others..

 

[mikegoubeaux]

I wanted to share another way to organize your configuration files. I used to use a single mqtt config file and imported it into configuration.yaml. Well that was starting to be too big so I've broken all the MQTT sections (binary_sensory, number, sensor, switch (i don't have any mqtt switches)) down into folders and then organized by devices.

This is what is in my configuration.yaml

mqtt:
binary_sensor: !include_dir_merge_list config_mqtt/binary_sensor/
number: !include_dir_merge_list config_mqtt/number
select: !include_dir_merge_list config_mqtt/select
sensor: !include_dir_merge_list config_mqtt/sensor/
switch: !include_dir_merge_list config_mqtt/switch

And then this is what all my files look like on the HA filesystem.

View attachment 228568


As you can see, I have more MQTT devices than just Victron' stuff. I find this much easier to manage. Hope it helps others..

Have you investigated packages? You can further organize directories by project or idea, so you could keep all of your victron configuration in a "victron" directory!!

 

[Captadv]

Have you investigated packages? You can further organize directories by project or idea, so you could keep all of your victron configuration in a "victron" directory!!

I'm aware .. but I'm not making something reusable for others. But I get it influencers gotta influence...

Links to the docs on these topics:
HA File merges \ Splitting up the config: Splitting up the configuration
HA Packages: Packages

 

[gregoryx]

I'm aware .. but I'm not making something reusable for others. But I get it influencers gotta influence...

Links to the docs on these topics:
HA File merges \ Splitting up the config: Splitting up the configuration
HA Packages: Packages

I've gone more toward packages as well. My first break-apart was by type - mqtt.yaml, for example. Now, I'm doing a single file for everything of a given type: victron.yaml, peplink.yaml, wican.yaml. But I still have more work to do...

 

[IT Nomad]

I've gone more toward packages as well. My first break-apart was by type - mqtt.yaml, for example. Now, I'm doing a single file for everything of a given type: victron.yaml, peplink.yaml, wican.yaml. But I still have more work to do...

@Captadv - Thanks for sharing. There are a few different approaches to managing the ever-growing config and that's certainly a solid way of going about it.

Like a few others here, I've also gone down the route of using packages to manage my own.