Not sure WTF to start with on RPi home automation setup

[John B]

I'm developing a home lighting controller system based on a raspberry pi as the controller. I'm also trying to keep it fairly simple, reliable and easy to backup. At the moment I plan on having button panels for switches in the rooms, plus motion sensors.

I have made good progress on the hardware side of things. I have made an IO board with 2x banks of parallel outputs, 1x bank of parallel inputs made with shift registers, then a bank of I2C IO expanders giving me 128 parallel inputs with interrupt pins.

I have made some basic python scripts and experimented with node red to check that the hardware works, and I'm able to communicate with the I2C devices and also read/write the shift registers. So far so good.

But the software side is getting rather overwhelming. I'm thinking of using Openhab to handle the lighting side of things, but before I go down any particular road I think I need some advice from everyone.

How are triggers passed to something like Openhab? Here would be a typical sequence of events that I'm trying to achieve:

-Press physical button in a room
-I2C expander registers state change on IO pin, triggers interrupt pin connected to RPi IO pin
-RPi reads IO pin change, then send I2C read message to associated chip(s)
-RPi is able to compare IO pins to previous state to determine if a button has been pressed

Alternatively:
-Scan through input shift registers at some low rate (~5Hz for example)
-Detect state changes (attached devices may be motion sensors for example)

Then each digital input whether on the I2C expanders or shift registers would have some associated trigger/value, eg room_01_ON, room_01_brightness_INCREASE, room_02_MOTION_SENSOR etc etc

Right about now I'm somewhere in phase 2 of the underpants gnome meme. I'm not sure what software to use to process the IO stuff, perhaps node red with scripts that pass values onto openhab? Also, I have seen people recommending organising openhab and everything else like node red into Docker containers, rather than using the OpenHABian pre-made RPi image. Any input or experiences?

Once all the processing is done on the RPi side, the output sequence would involve writing digital outputs to the shift registers. The outputs are grouped into banks of 18 parallel outputs with a total of 288 outputs. The groups of 18 digital outputs connect to separate lighting drivers to set brightness and colour temp, on/off. So to change one light you would need to shift in 288 bits each time. Not all the outputs may be controlling lights either, for example I plan on using a relay board to switch mains power on/off to the various AC/DC converters for each LED driver board.

I'm hoping to keep things simple to start with, but also leaving the option for expansion, for example I'm also looking into MQTT if additional remote control needs to be piped into the system later on, but first things first is seeing whether I can simple turn a light on with a button.

[PlainName]

This sounds like you have each input (button, sensor, ...) connected to a specific IO pin and the same for output. Which implies a star wiring arrangement between controller and everything else.

Have to say that I would tend towards a bus of some kind, so at its minimum you'd have on set of wires (tx,rx,power) snaking around everything. Of course, that can be just as impractical, so typically it would end up as a star of buses. IMO that would be easier to change (add stuff, move stuff, test stuff), though a little more work up front than just flipping register bits.

Apols if I misunderstood your setup and that's how you're doing it anyway

[thinkfat]

MQTT. This will be your central data broker for external hardware.

To add some detail - how you interface with your own hardware on the lowest level is a bit up to taste, you can go with just bareknuckle GPIOs or you can use GPIOs or SPI bus to talk to chained 74HC595 shift registers, or you can use I2C and dedicated GPIO extenders, eventually it doesn't matter.

What matters is, if you decide to go OpenHAB, MQTT is pretty much the only method to get arbitrary data and actions in and out, if you don't want to write an OpenHAB binding for your hardware interface.

In that case, look into the paho MQTT client module for python. Eventually you'll be running a python "service" that talks to your hardware and publishes e.g. button presses over a MQTT broker (like, mosquitto). OpenHAB will be connecting to the same broker and receiving those messages to funnel them into their "things" and "items" model.

Docker - yes. A neat method to containerize your complete application stack without interfering with your OS setup.

[ralphrmartin]

Check out tasmota to go with MQTT.

[John B]

This sounds like you have each input (button, sensor, ...) connected to a specific IO pin and the same for output. Which implies a star wiring arrangement between controller and everything else.

Have to say that I would tend towards a bus of some kind, so at its minimum you'd have on set of wires (tx,rx,power) snaking around everything. Of course, that can be just as impractical, so typically it would end up as a star of buses. IMO that would be easier to change (add stuff, move stuff, test stuff), though a little more work up front than just flipping register bits.

Apols if I misunderstood your setup and that's how you're doing it anyway

Yep it would be a star arrangement for everything. I wasn't confident in setting up a house wide serial bus for switches, plus my needs are modest enough to use a parallel button arrangement (Cat5 wire should suffice and is fairly cheap in rolls). Plus, most importantly the whole system is split into opto isolated blocks to protect the RPi from induced transients like lightning, or backfeeding 36V from the LED drivers if they fail catastrophically.

MQTT. This will be your central data broker for external hardware.

To add some detail - how you interface with your own hardware on the lowest level is a bit up to taste, you can go with just bareknuckle GPIOs or you can use GPIOs or SPI bus to talk to chained 74HC595 shift registers, or you can use I2C and dedicated GPIO extenders, eventually it doesn't matter.

What matters is, if you decide to go OpenHAB, MQTT is pretty much the only method to get arbitrary data and actions in and out, if you don't want to write an OpenHAB binding for your hardware interface.

In that case, look into the paho MQTT client module for python. Eventually you'll be running a python "service" that talks to your hardware and publishes e.g. button presses over a MQTT broker (like, mosquitto). OpenHAB will be connecting to the same broker and receiving those messages to funnel them into their "things" and "items" model.

Docker - yes. A neat method to containerize your complete application stack without interfering with your OS setup.

Thanks, that's a good bit of info to go off. I was hoping to cut out Node Red from the process of interfacing with my hardware, just leaving it for any potential "IoT" stuff later.

Looks like I've got a bunch of python to script...

[rstofer]

Running wire all over the place and having to add relays 'somewhere' seems like the hard way around.

https://www.x10.com/

You can add computer control with one of the Computer Interface modules

https://www.x10.com/products/cm17a?_pos=1&_sid=af4143848&_ss=r