No, Raspberry Pi isn’t microcontroller it is SBC
How can it be that nobody ever wrote a program for this since OH started?
There is a lot of Python scripts to read GPIO, but it’s not good idea to make IB on I2C.
What do you mean? I don’t understand the “IB” acronym.
But this function is a MUST for me.
What I would like to do:
-
have all the function my previous home-control system knew before it broke. (Short+Long press, long-dimming, temperature + light, rules, scenes = moods, roller sh., timers.)
-
and extend with some new functions. (Tablet + mobile GUI, maybe voice control, IR control, etc)
-
Having lot’s of cheap inputs and outputs (min. 64+48)
I need this USB>I2C cable because the Raspberry will be at my Bedroom (at 24.5 °C) but ALL the wires and dimmers and relays are at the attik 2 meters above it:
IB = Intelligent Building or Home automation if you like. One more thing, why USB to I2C when you have I2C on GPIO?
Does it have to be? The chips you are using have an interrupt output that would make it much easier to do. I can get MQTTany to handle everything you want if we can access the interrupt signal from the chips directly. You say you don’t want the Pi in the attic or any direct GPIO connections, but if you want this level of real-time response you won’t be able to do that. If what you really want is the galvanic isolation so that a lightning strike doesn’t take your system down, putting the Pi in your bedroom and connecting via USB won’t protect it.
First [Successes] 
-
I was able to flash the Firmware to the Digispark USB AtTiny85 chip!
The trick was: found a modified (Forked) version of miraculeus.exe to run on my Win7 64bit mashine, which can run with simple WinUSB driver: direct downlad link here… -
I’ve also contacted the creator of miraculeus + RPi forum to ask about RPi Light installation, because I’d like to create tutorial, where EVERYTHING is possible to do on RPi itself to ease the work of the next generation.
-
Found a great topic about the “next steps”, I’ve asked about:
OpenHABian i2c -
From there on, it was easy cake:
- installed everything, have set /boot/ + /modules/ …etc: details here…
- To list I2C devices:
lsmod | grep i2c_ - To list I2C devices and bus numbers:
sudo i2cdetect -l - After that, to list devices in a table on bux “7” :
sudo i2cdetect -y 7
I was happy a bit too soon…
A new problem with this concept appeared:
- ALL these devices have the “same name” and “same ID”
- and they get a sequential I2C Bus number, so they may change depending which one do I plug in first to which USB port!
(Tested, and #7 became #8 and #8 > #7. So they swapped)
Started a new topic on RPi forum for that: link…
I start to believe rossko57, you were right the whole time!
I2C is not really suitable to do all this.
The question is:
- are there any cheap IO-port boards for RS485?
- and plug&Play USB>RS485 adapters that OH can handle “out of the box” ?
It should be possible to assign a fixed name to a USB device. Search this forum for “persistent USB port”.
Based on the speed of responses you want I don’t think RS485 is a good idea. While it is possible to run RS485 at 12Mbps I don’t think you’ll find a device that will run that fast. You’ll also still run into the same problem I have indicated that Linux is not a real-time operating system.
You haven’t answered my previous question about why the Pi must be in the bedroom and can’t be in the attic.
1 Like
Practical comments about using Modbus.
Line speed is the least problem. It’s a polled technology.
Say you have twenty wall switches - you have to poll, ask each in turn, have they been pressed. The time consuming part is going round them in turn, it’s rarely sensible to poll each one more than twice a second.
If of course you can wire your twenty switches to a single i/o module you’ve improved things.
But you’re never going to get sub 500mS response to a button press this way. (Or any other way using openHAB!)
Available devices. It’s an industrial spec, there are very few small-scale devices available for “home automation” as we’d recognise it - dimmers, wall switches etc.
On the other hand, it’s an industrial spec. There are cheap modules from China providing simple binary or analogue channels e.g. 8IO like the OP wanted.
If you’re prepared to make your own, Arduino etc. have Modbus libraries, no problem. Make your own Modbus dimmer interface.
Also, it’s an industrial spec. In this case it will be of interest that most devices feature opto-isolation etc, though the chepest/DIY will not, but even then it’s easy to add RS485 isolators and suppressors.
I use Modbus in a commercial setting - a warehouse. Chose it because it’s an ancient standard - the installed devices will be usable with whatever automation host is available in twenty years. The same may now also be true of e.g. zwave of course.
It’s appropriate there because I’m doing lights on/off, not dimming or colour.
But more importantly, openHAB is supervising, not directly controlling. The wall switches work the light relays almost directly - good user response experience, failsafe against system failure. Taking 1000mS to recognise a motion sensor input is fine, a manual switch isn’t.
Absolutely agree. I would not attempt to make a central system micro-managing all activities.
Have independently working switch/relay or dimmer subsystems, that openHAB can monitor and control. Supervise.
Come on, these things are 3 euros on eBay.
It’s the other end that is more difficult for the home user, if not DIY-ing.
Look at the PLC. they easy handling all sort of clicks. Instead of RS485 you can use modbus via UTP.
Thank you for everyone for all the advises!
Since now I have EVERYTHING needed to wire together at least a simple 8-button + 8-switch scenario:
- I’ll take the next 2-5 days to build it “on my desk”,
- learn about how to configure the basics, (still not clear to me completly)
- test how fast is it = responce time
- than intall Ivan’s MQTT version
- re-test speed
- and finally report back
PS: YES, I’ll use opto isolators and resistors to protect the IO ports and beeing able to run the switches with 12V for long distance too:
I have already bought everthing needed, just need some time to solder them together.
Sounds like a good solution here. PLC usually come with many digi and analogue I/O.
The biggest technical issue might be interfacing to his dimmers, about which we know nothing.
With the hardware you have the most feasible way to do what you want would be to put the Pi in the attic.
Connecting the PCF8574s
Option 1
Connect the PCF8574 via opto-couplers to the I2C port of the Pi (I can provide circuit diagrams if needed) and connect each PCF8574s interrupt pin via opto-coupler to a different GPIO pin on the Pi. Now we have direct connection with the Pi so we can get close to the response speed you need, and we have the galvanic isolation you want in case of lightning strike. You will also need a separate power supply for the PCF8574s, but fewer opto-couplers. (make sure you surge protect the input to the power supply for the Pi!)
Option 2
Connect the I2C and interrupt pins directly from the PCF8574s to the Pi and power them from the same supply. Place opto-couplers on every input/output from the PCF8574s. This method is simpler but requires an opto-coupler for every input/output pin.
Software
MQTTany can already handle MCP230xx devices (same type of IO expander) and I had planned to add support for listening for interrupt signals from them.
If I add the PCF8574 support and interrupt handling, the only thing missing is your direct dimmer control. It is probably possible in MQTTany if I build some custom code for you, but I need to know how your dimmers are controlled.
Dimmers are controlled with OH “ArtNet” Binding through a Ethernet-DMX adapter.
Eth>DMX $90 box
It’s working perfectly fast, nice fade-in fade-out effect if I press “switch” button on PaperUI.
That’s why I still not understand:
- A “baud rate” = I2C bus speed (even through the USB>I2C adapter) is much much higher than user responce time.
128 IO / 20ms = 6400Hz only! (Lower than "standard 9600 baud.)
I have a Raspberry 4 with 4GB RAM.
So checking each IO for push/release the CPU has 1.5GHz x 8 cores. If running only 1 core at 50% we have 110000+ cycles to handle a simple piece of code.
So please let me try it first guys, than I’ll report back in a few days! 
No, sorry. At summer time, when outside is 38°C > at the attick is 60°C+
At my air-conditioned room is max 26°C.
I’m using passive cooling.
… anyway I still don’t understand why it does matter at all? The USB>I2C adapter is running at 12000Hz, converting IO signals very fast.
Or is the problem that your MQTT can not handle any other I2C bus number only #1 ?
Your math doesn’t work. USB adapter running at 12khz means 1.5ms per bit. If there is no overhead that means 27ms per PCF8574 (start bit + read bit + 7 bit address + 8 bit response + stop bit = 18 bits). 27ms x 16 devices (8 IO x16 = 128) gives us 432ms. That gives us 2.32Hz best possible refresh rate. With the non-real-time nature of Linux and possible overhead of the USB-I2C adapters I doubt it would be possible to refresh all ports are 500ms interval.
However, if we let the PCF8574s watch for the pin to change and tell us when one of its 8 pins changes via the interrupt pin, we only have to poll that device to determine which pin changed. The interrupt pins could still be brought to the Pi if we isolate and possibly boost the signal.
MQTTany can control sACN, do your dimmers support that? If so you could offload control to MQTTany and that solves the delay problem on the openHAB side (I would have to write some code to link the lights to the buttons, but it’s possible) you could then still have openHAB send commands to MQTTany to control the lights.
It can handle any port, it’s just a setting you specify in the config.
1 Like
Mate, you are great guy! Really!!
I can not thank you enough for all the time you have invested into this already.
NOW I understand the problem.
Thank you. I enjoy puzzles.
So do your dimmers support sACN?
Do you have the PCF8574s on boards, or are you making your own? If they are already on boards, please attach a picture.
What will be powering the PCF8574s and at what voltage?
Sadly Eth-Dimmer adapter does NOT support sACN 
But dimmered light turn on/off a bit slower anyway, so it’s not a problem, if OH is controlling it.
I’ve bought them as “ready to plug in” 
Don’t really like to solder much.
They will be powered with 5V.
pcf8574-io-expansion-board