Compatible USB>I2C adapter for RPi4

Hardware Home Automation
34

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
35

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.

36

Look at the PLC. they easy handling all sort of clicks. Instead of RS485 you can use modbus via UTP.

37

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:

Raspberry-Pi_opto-in_relay-out
Raspberry-Pi_opto-in_relay-out793×1123 133 KB

I have already bought everthing needed, just need some time to solder them together. :slight_smile:

38

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.

39

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.

40

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! :wink:

41

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 ?

42

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
43

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.

44

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?

45

Sadly Eth-Dimmer adapter does NOT support sACN :frowning:
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” :slight_smile: Don’t really like to solder much.
They will be powered with 5V.
pcf8574-io-expansion-board

46

Maybe I’ll add ArtNet support then, I had considered it in the past.

OpenHAB is too slow for controlling the dimmers and doing a smooth fade while the button is held. We need feedback on the current light level, but we also want to change it at a faster frame rate than openHAB can report the new state back to us.

Also how are you isolating the Pi from the PCF8574s? Are you planning on using opto-couplers on the I2C connections from the USB/I2C?

47

No need to rush ahead!
Please give me a few days first :wink:

About speed:
Stefan said response time was ok even with wireless buttons.
I will try that first, so we may compare it later.

About opto isolation:
see post #37

48

(Bad) News about the project:

Using those AtTiny85 adapters as USB>I2C base was a VERY BAD IDEA :frowning:

  1. It was extremely difficult to Flash them (Until I’ve found THIS Forked “WinUSB driver compatible” micronucleous EXE)
  2. Had to solder those pins/wire myself >> caused shortcut first, was hard to remove the tin.
  3. Using multiple pieces having same serial + name turned out to get random I2C bus address!
  4. And the “final blade” was to find out:

There is a HUGE ERROR known since 2019 dec. in the Firmware: after RPi reboot > it always STOPS working. Only manual unplug / replug helps! :frowning:

49

My next trial will be:
Using an Arduino NANO! As it turns out:

  • It has an USB port,
  • already an I2C pinout (A4+A5)
  • +14 I/O port !!!
  • very well documented user manuals, examples, videos, etc.
  • … and other extras I might be able to use too, like analog inputs, RS232 …

And the best part: it costs only $5 / $8 (depending on the CH340 / FT232 subtype).
So basically it is CHEAPER, than buying separately an I2C adapter + an extension board!

Also it’s possible to attach an Ethernet shield on top for only $5.
(So no more “max 5 meters” limit…)

By Monday I should have the first 2 pieces delivered.

50

Wouldn’t you be able to assign a permanent alias to the USB device? I know it’s possible but maybe not with the same model of device.

Do you have firmware for the arduino? It won’t come programmed.

51

Not if the SAME serial number is being flashed to ALL those devices. If they differ, here is a howto…

No, nothing yet, but as I see, there are LOT’S of examples and nearly “ready-to-use” github codes.
Also I can make firmwares to it myself, because it can be uploaded with Mikropascal codes too, not just C.
(I hate C, but love Pascal :blush: )

52

Well hang on now, I just had a look at the firmware you flashed. VSCode could probably flash that via platformio and you could change the product ID to suit your needs.

53

Don’t worry about that, I’ve dropped AtTiny85 boards completely.
You have maybe missed my 4. bad news:

  • They FREEZE = HALT = DO NOT START after each reboot

So they are useless. Not worth working on them 1 minute longer, because Arduino NANO-s are a much better choice!