That sound very bad! Obviously that would be the most important thing to accomplish.
Everything else is just “extra”.
Do you know about any “real scenarios”, how much delay it takes to handle long-dimming?
sudo apt install i2c-tools
The answer to your next questions is no, OH is not a real-time system. To handle long, short, double clicks etc. you may use microcontrollers or PLC.
That’s very bad news 
Do you mean using those
- next to Openhab or
- instead of?
Of course next/with 
Actually Raspberry Pi4 IS a microcontroller itself. Isn’t it?
I’ve installed it only for this purpose. All the GPIO ports are attached to it “directly” (through these USB>I2C adapters).
So why would it be a problem to run a daemon that is watching short/long-presses and sends signals to OH?
How can it be that nobody ever wrote a program for this since OH started?
How about this:
Raspberry Pi’s are microcontrollers, but Linux is not a real-time operating system. It’s fast enough that you can detect quick changes in GPIO pins by reading their state many times, but if the system is busy or the pulse is too fast it won’t be detected.
It map help to know exactly what you are trying to accomplish and why you need to use this central wiring in your attic. I don’t fully understand why you want to control your lights in this manner either, it seems overly complex. Short press, long press, double click are not too complicated for a script running on the Pi to handle, but the hold to dim is hard to do.
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.