I’m in the process of creating my first binding - PCF8574 - https://github.com/openhab/openhab2-addons/pull/5407 and hopefully soon it will be finished.
I’m wondering what binding I should build next.
I’d like to attach two sensors to my Raspberry PI: BH1750 (light intensity sensor) and SHT30/SHT31 sensor (temperature and humidity).
I’m aware there are python scripts that read values from these sensors and they can be used with exec binding, but I’d like to have a native binding that is easy to add and configure.
I’m wondering what might be the best way to build such bindings. Should there be a separate binding for each sensor or maybe there could be one binding called ‘I2C Sensors’ that could handle multiple sensor types.
I’m not sure if this kind of binding (that can handle multiple types of sensors) is even possible to build.
Because I’m new to openHAB and bindings development, I’m searching for a good example showing I2C sensor reading that I could use as a base for building my binding/bindings.
BTW is anyone interested in such bindings?
I’m aware we can use MQTT, esp8266 and ESPEasy, but I want to avoid wireless sensors.
David_Graeff any thoughts?
I’ll wait till binding development will work again and I want to give those two (BH1750, SHT31) a try.
Do You think those will be a useful bindings?
Any binding I can use as a template?
Hello I would appreciated it. I am using now python code + exec binding for reading light intensity from BH1750. There was lot of problem with perissions, …
How it is going with this binding development?
Hi! Does it support only a single i2c chip for now? I’d like to see an I2C bus bridge plus an extendable set of Things. I am planning to add a lot of sensors to my installation and will use PCF8575 GPIO adapters.
< OFF > So, you were forced “into the line” too… I’m sad to hear that.
I still don’t want to give up solving it to be able to use a WIRED system with lot’s of GPIOs!
Everyone is pushing those Wifi + Ethernet + RF + Bluetooth systems…
I think it’s:
a security risk
slower execution of command
unnecessary radio-waves in your house. (There are lot’s of people sensitive to those, even if they don’t know why they have a headache.)
they fill up the routers ARP + IP table and slow down communication a bit
it’s much more difficult to debug a system, if it’s not “plugged in”. (And we should know by now: whatever can be broken > WILL BROKE sooner or later.)
Then look for Java library and try to creating something by your own.
I’m not a Java developer, but it was quite easy to get started with binding creation.
I’m sure that right now it is even easier.
The community is great and if you create a PR you will get a lot of feedback.
Today i decided to try to pick the project up and it looks like pi4j is a no-go as a basis. Too limited and supports only PCF8574. For some reason it’s quite difficult to obtain them here and they are expensive, but we have 8575 easily available, and it has 2x greater number of I/Os . But pi4j doesn’t support it unfortunately.
For such low level bus you might also stick with jdk.dio package. Currently it is not part of Java distro and have to be pulled as external dependency.
Thanks, i didn’t know about diozero. Took a glance, perhaps it’s not exactly what we need, but i’ll look further; and into dio too.
Will need to wait up to 1 week for a USB-I2C adapter board to arrive in order to do the development in a comfortable environment on my Windows PC. And support for such a thing will automatically unstick the user from RPi; you’ll be able to keep using your beautiful server rack.
I started with a gpio binding based on pi4j. I added some i2c things. The binding fully works, but given the uncertain status of pi4j I put it on hold, and haven’t had time to look into it. But it might be a head start for you: https://github.com/Hilbrand/openhab-addons/commits/pigpio
@hilbrand Hi! Looks very similar to an old PR https://github.com/openhab/openhab-addons/pull/5407 ; and i already tried to pick up at that point, I guess his code and yours is 90% the same. And yet it shares the same limitation: no 8575; and no other I2C devices.
Well, adding 8575 to that library would also be an option… May be i should try to contact its author; it would be faster and easier to do.
OTOH the library tries to manage all the GPIOs; it’s unclear how it would interop with generic linux GPIO binding (which i also plan to use)
It’s not a binding, but you could use my MQTTany software. It communicates over MQTT, but will run on any Linux host.
It doesn’t have support for the chips you are using, but I do support MCP230xx chips which I think are basically the same (8 and 16 pin IO expanders). I expect it would be trivial to duplicate the MCP230xx code and modify it to support your chips. If you are interested open an issue and give me some datasheet links and I will take a look.
8575 is the same as 8574, with 16 bits instead of 8. Should be easy yo add.
I’m sad to hear that.