Add i2c gpio support #390

2021-02-05T16:52:24Z

raoulh commented

2021-02-05 16:52:24 +00:00

(Migrated from github.com)

Implement support for i2c gpio devices (GPIO outputs and temp/humidity inputs)

I am using octoprint on a raspberry with a hyperpixel4 screen which is using all the GPIO of the raspi. The only way to have IO is to use the I2C bus. This commit allows to interact with an i2c slave within the enclosure plugin. You can create regular GPIO with the i2c option and choose the register to read/write from for that pin.
You can also add temperature or humidity sensor using the same mechanism.

A simple i2c slave based on an arduino mini pro that I use is available here: https://github.com/raoulh/arduino_i2c_gpio_slave

related issue #323

Implement support for i2c gpio devices (GPIO outputs and temp/humidity inputs) I am using octoprint on a raspberry with a hyperpixel4 screen which is using all the GPIO of the raspi. The only way to have IO is to use the I2C bus. This commit allows to interact with an i2c slave within the enclosure plugin. You can create regular GPIO with the i2c option and choose the register to read/write from for that pin. You can also add temperature or humidity sensor using the same mechanism. A simple i2c slave based on an arduino mini pro that I use is available here: https://github.com/raoulh/arduino_i2c_gpio_slave related issue #323

SNR-Tech-Bytes commented

2021-02-16 16:55:48 +00:00

(Migrated from github.com)

Just want to upvote this pull request. Would be extremely useful for a project I'm working on!

Ivosch commented

2021-02-26 17:44:38 +00:00

(Migrated from github.com)

Same for me. I would like to connect relay for PSU, through i2c and arduino.

wickedbeernut commented

2021-03-23 16:40:58 +00:00

(Migrated from github.com)

Is the implementation flexible enough for the Enclosure plugin to directly control I2C "regular" outputs (i.e., without the need for an I2C proxy)? For example, I'm using three SparkFun Qwiic I2C Quad Relays (12 relays total). Of course, each board has a unique I2C address. You turn on and off the combination of board (I2C address) + relay (1 - 4). Along the same lines, you'd referenced @JaredC01's feature request to support an I2C GPIO expander (MCP23017). Will your implementation directly control an I2C GPIO expander?

Is the implementation flexible enough for the Enclosure plugin to directly monitor I2C temperature and humidity sensors via an I2C mux? For example, I'm using an 8-channel SparkFun Qwiic I2C Mux (TCA9548A) Breakout board in order to leverage five SparkFun BME280 temperature and humidity Atmospheric Sensor Breakout boards (the SparkFun BME280 board only supports two different I2C addresses).

With the master branch, rpi_outputs with an output_type of temp_hum_control
can only control "native" GPIO (i.e., you can only specify a specific GPIO number). With your implementation, can a cooler, heater or dehumidifer controller control I2C GPIO?

I have submitted Enclosure plugin feature requests for,

Is the implementation flexible enough for the Enclosure plugin to directly control I2C "regular" outputs (i.e., without the need for an I2C proxy)? For example, I'm using three [SparkFun Qwiic I2C Quad Relays](https://www.sparkfun.com/products/16566) (12 relays total). Of course, each board has a unique I2C address. You turn on and off the combination of board (I2C address) + relay (1 - 4). Along the same lines, you'd referenced @JaredC01's feature request to support an [I2C GPIO expander (MCP23017)](https://github.com/vitormhenrique/OctoPrint-Enclosure/issues/323). Will your implementation directly control an I2C GPIO expander? Is the implementation flexible enough for the Enclosure plugin to directly monitor I2C temperature and humidity sensors via an I2C mux? For example, I'm using an [8-channel SparkFun Qwiic I2C Mux (TCA9548A) Breakout board](https://www.sparkfun.com/products/16784) in order to leverage five [SparkFun BME280 temperature and humidity Atmospheric Sensor Breakout boards](https://www.sparkfun.com/products/13676) (the SparkFun BME280 board only supports two different I2C addresses). With the master branch, rpi_outputs with an output_type of temp_hum_control can only control "native" GPIO (i.e., you can only specify a specific GPIO number). With your implementation, can a cooler, heater or dehumidifer controller control I2C GPIO? I have submitted Enclosure plugin feature requests for, - [I2C Boolean Input and Output Support](https://github.com/vitormhenrique/OctoPrint-Enclosure/issues/399) - [I2C Mux Support with BME280 Temperature / Humidity Sensor](https://github.com/vitormhenrique/OctoPrint-Enclosure/issues/391)

raoulh commented

2021-03-26 13:38:12 +00:00

(Migrated from github.com)

@wickedbeernut
I quickly went through the doc of the Sparkfun doc, it seems that the relays would work as they seems standard i2c outputs.

About the temp/hum boards, I fear it will not be compatible. The TCA9548A chip is not a simple read operation on a i2c register (like I did in this PR) but rather multiple read/writes with calibrations values and such. It would be better to implement that a different way.

Here is a screenshot of the config screen in my PR. You are free to configure the data written, read, register, etc...

@wickedbeernut I quickly went through the doc of the Sparkfun doc, it seems that the relays would work as they seems standard i2c outputs. About the temp/hum boards, I fear it will not be compatible. The TCA9548A chip is not a simple read operation on a i2c register (like I did in this PR) but rather multiple read/writes with calibrations values and such. It would be better to implement that a different way. Here is a screenshot of the config screen in my PR. You are free to configure the data written, read, register, etc... ![image](https://user-images.githubusercontent.com/1115950/112639652-cc34de00-8e40-11eb-9cae-504900a9d34c.png)

wickedbeernut commented

2021-03-26 17:17:17 +00:00

(Migrated from github.com)

All of my vitormhenrique / OctoPrint-Enclosure plugin inputs and outputs are I2C. At the moment, I have 10 I2C outputs (relays),

(3) Enclosure Air Purifier Fans (actually, one 3-speed fan)
(1) Enclosure Heater
(3) Filament Dryer Heating Elements
(3) Filament Dryer Circulation Fans

and ten I2C inputs,

(1) Print / Resume Button
(1) Pause / Cancel Button
(3) Filament Sensor Switches
(1) Ambient BME280 Temperature and Humidity Sensor *
(1) Enclosure BME280 Temperature and Humidity Sensor *
(3) Filament Dryer BME280 Temperature and Humidity Sensors *

* - I2C sensors monitored via an I2C mux

I’ve been forced to incorporate the I2C mux support into the Enclosure plugin BME280.py script. It’s only half a dozen lines, but I’m forced to own it.

I assume the screenshot you shared is of an output (on the “Raspberry Pi Outputs” settings page) with an output type of “Regular IO”.

As I mentioned, all of my I2C outputs are controlled using Enclosure plugin heater and cooler controllers (i.e., rpi_outputs of output_type ‘temp_hum_control’ with control_type ‘heater’ or ‘cooler’). In the master branch, “Raspberry Pi Outputs” with output type “Temperature / Humidity Control” only accept GPIO numbers. Are you planning to add I2C support to “Temperature / Humidity Control” outputs or only “Regular IO” outputs?

I’m currently using my own OctoPrint plugin that maps GPIO outputs to I2C outputs and I2C inputs (buttons and switches) to GPIO inputs. It’s completely transparent to the Enclosure plugin. The Enclosure plugin thinks it’s monitoring and controlling GPIO input and output devices when in fact they’re I2C. This works fine, however, it “wastes” GPIO pins. It won’t help guys like you and @JaredC01 that burned all of the GPIO pins on a Hyperpixel 4.0 display.

I’m not sure if you’re familiar with blynk.io. In addition to analog and digital input / output pins, blynk.io supports the notion of “virtual pins”. I think this may be the cleanest approach to supporting my I2C inputs and outputs. For example, let’s assume the Enclosure plugin recognizes pins 32 – 63 as “virtual”. The idea is the Enclosure plugin would treat virtual pins exactly like physical pins except at the lowest (hardware) level.

For example, consider the write_gpio function,

def write_gpio(self, gpio, value, queue_id=None):

For GPIO pin numbers less than 32, the write_gpio function would invoke GPIO.output(gpio, value) as is the case today. However, for virtual pins 32 – 63, the write_gpio function might invoke a user-supplied Python script, passing the pin and value. The underlying Python script would apply the appropriate I2C logic. In most cases, this would involve leveraging existing user-friendly Python libraries for the I2C device being controlled or monitored (rather than performing raw register reads and writes). The simplest approach would be for the user-supplied Python script to hardcode the mapping between the virtual pin and the corresponding I2C address / syntax. The Python script should be able to interface with just about any I2C device. Of course, a Python script may not be as efficient as a more "built-in" solution.

Using virtual pins frees up GPIO pins. In theory, treating the virtual pins like GPIO pins (at all but the hardware level) should minimize the changes to the Enclosure plugin.

I’ll probably stick with my GPIO <-> I2C mapper plugin for now. However, if I run out of GPIO pins, I’ll pursue the virtual pin approach. Please let me know if you plan to support I2C outputs in conjunction with temperature and humidity controllers. That may be an option as well.

All of my vitormhenrique / OctoPrint-Enclosure plugin inputs and outputs are I2C. At the moment, I have 10 I2C outputs (relays), (3) Enclosure Air Purifier Fans (actually, one 3-speed fan) (1) Enclosure Heater (3) Filament Dryer Heating Elements (3) Filament Dryer Circulation Fans and ten I2C inputs, (1) Print / Resume Button (1) Pause / Cancel Button (3) Filament Sensor Switches (1) Ambient BME280 Temperature and Humidity Sensor * (1) Enclosure BME280 Temperature and Humidity Sensor * (3) Filament Dryer BME280 Temperature and Humidity Sensors * * - I2C sensors monitored via an I2C mux I’ve been forced to incorporate the I2C mux support into the Enclosure plugin BME280.py script. It’s only half a dozen lines, but I’m forced to own it. I assume the screenshot you shared is of an output (on the “Raspberry Pi Outputs” settings page) with an output type of “Regular IO”. As I mentioned, all of my I2C outputs are controlled using Enclosure plugin heater and cooler controllers (i.e., rpi_outputs of output_type ‘temp_hum_control’ with control_type ‘heater’ or ‘cooler’). In the master branch, “Raspberry Pi Outputs” with output type “Temperature / Humidity Control” only accept GPIO numbers. Are you planning to add I2C support to “Temperature / Humidity Control” outputs or only “Regular IO” outputs? I’m currently using my own OctoPrint plugin that maps GPIO outputs to I2C outputs and I2C inputs (buttons and switches) to GPIO inputs. It’s completely transparent to the Enclosure plugin. The Enclosure plugin thinks it’s monitoring and controlling GPIO input and output devices when in fact they’re I2C. This works fine, however, it “wastes” GPIO pins. It won’t help guys like you and @JaredC01 that burned all of the GPIO pins on a Hyperpixel 4.0 display. I’m not sure if you’re familiar with blynk.io. In addition to analog and digital input / output pins, blynk.io supports the notion of “virtual pins”. I think this may be the cleanest approach to supporting my I2C inputs and outputs. For example, let’s assume the Enclosure plugin recognizes pins 32 – 63 as “virtual”. The idea is the Enclosure plugin would treat virtual pins exactly like physical pins except at the lowest (hardware) level. For example, consider the `write_gpio` function, `def write_gpio(self, gpio, value, queue_id=None):` For GPIO pin numbers less than 32, the `write_gpio` function would invoke `GPIO.output(gpio, value)` as is the case today. However, for virtual pins 32 – 63, the `write_gpio` function might invoke a user-supplied Python script, passing the pin and value. The underlying Python script would apply the appropriate I2C logic. In most cases, this would involve leveraging existing user-friendly Python libraries for the I2C device being controlled or monitored (rather than performing raw register reads and writes). The simplest approach would be for the user-supplied Python script to hardcode the mapping between the virtual pin and the corresponding I2C address / syntax. The Python script should be able to interface with just about any I2C device. Of course, a Python script may not be as efficient as a more "built-in" solution. Using virtual pins frees up GPIO pins. In theory, treating the virtual pins like GPIO pins (at all but the hardware level) should minimize the changes to the Enclosure plugin. I’ll probably stick with my GPIO <-> I2C mapper plugin for now. However, if I run out of GPIO pins, I’ll pursue the virtual pin approach. Please let me know if you plan to support I2C outputs in conjunction with temperature and humidity controllers. That may be an option as well.

wickedbeernut commented

2021-03-26 17:47:50 +00:00

(Migrated from github.com)

Here's the set_relay_on function of the sparkfun / Qwiic_Relay_Py Python library. It would appear you can only toggle an individual output of a quad relay. Therefore, you must first read the current state of the output. If the current state doesn't match the target state, you then toggle (write) the output. I assume this won't work with your I2C GPIO support?

#define register start positions
DUAL_QUAD_TOGGLE_BASE = 0x00
STATUS_BASE = 0x04
DUAL_QUAD_PWM_BASE = 0x0F
TURN_ALL_OFF = 0x0A
TURN_ALL_ON = 0x0B
TOGGLE_ALL = 0x0C

    def set_relay_on(self, relayNum=None):
        """
            Turn's on a relay,if we're using a single relay, do not pass in a relay number
            :param: The relay to turn on
            :return: successful I2C transaction
            :rtype: bool
        """
        if relayNum is None:
            return self._i2c.writeCommand(self.address, SINGLE_ON)
        else:
            temp = self._i2c.readByte(self.address, STATUS_BASE + relayNum)

            if temp is STATUS_OFF:
                return self._i2c.writeCommand(self.address, DUAL_QUAD_TOGGLE_BASE + relayNum)

Here's the `set_relay_on` function of the [sparkfun / Qwiic_Relay_Py](https://github.com/sparkfun/Qwiic_Relay_Py) Python library. It would appear you can only toggle an individual output of a quad relay. Therefore, you must first read the current state of the output. If the current state doesn't match the target state, you then toggle (write) the output. I assume this won't work with your I2C GPIO support? ``` #define register start positions DUAL_QUAD_TOGGLE_BASE = 0x00 STATUS_BASE = 0x04 DUAL_QUAD_PWM_BASE = 0x0F TURN_ALL_OFF = 0x0A TURN_ALL_ON = 0x0B TOGGLE_ALL = 0x0C def set_relay_on(self, relayNum=None): """ Turn's on a relay,if we're using a single relay, do not pass in a relay number :param: The relay to turn on :return: successful I2C transaction :rtype: bool """ if relayNum is None: return self._i2c.writeCommand(self.address, SINGLE_ON) else: temp = self._i2c.readByte(self.address, STATUS_BASE + relayNum) if temp is STATUS_OFF: return self._i2c.writeCommand(self.address, DUAL_QUAD_TOGGLE_BASE + relayNum) ```

hartmannf commented

2021-04-14 20:02:14 +01:00

(Migrated from github.com)

Hi guys

Well done! Before I start to spend hours and days and finally find out that it is not going to work without hudge coding, I prefer to ask your advice or who knows perhaps somebody got it working.

@ Victor made absolutly a great practical and useful Enclosure plug in, no doupt. and to read that your recovered from your unluck last year... Thanks... for your enclosure....

I really need the temp and humidity gettting into Octoprint to be able to set up a PWM to my External SolidState Relay. I followed allmost as the issues DMT 11 /22 but didn`t get it working in my octoprint.

So my question: if I add a Arduino over I2C where all the Sensors are connected. might I have a chance to get it working? I`ve never done it but I think I should be able to get that communication running up.

What`s your opinion.

Thanks

Hi guys Well done! Before I start to spend hours and days and finally find out that it is not going to work without hudge coding, I prefer to ask your advice or who knows perhaps somebody got it working. @ Victor made absolutly a great practical and useful Enclosure plug in, no doupt. and to read that your recovered from your unluck last year... Thanks... for your enclosure.... I really need the temp and humidity gettting into Octoprint to be able to set up a PWM to my External SolidState Relay. I followed allmost as the issues DMT 11 /22 but didn`t get it working in my octoprint. So my question: if I add a Arduino over I2C where all the Sensors are connected. might I have a chance to get it working? I`ve never done it but I think I should be able to get that communication running up. What`s your opinion. Thanks

wickedbeernut commented

2021-04-14 22:41:47 +01:00

(Migrated from github.com)

By "DMT 11 /22", I assume you mean DHT11 and DHT22. You're saying you were never able to successfully integrate a DHT11 or DHT22 temperature and humidity sensor with the Enclosure plugin?

It sounds like you're looking to leverage an Enclosure plugin temperature controller. I had asked @raoulh whether he planned to add I2C support to outputs of type “Temperature / Humidity Control”. I don't see where I received an answer. I'm assuming the answer is no.

Then there's the question of PWM. Even if @raoulh were to integrate his I2C support with outputs of type “Temperature / Humidity Control”, I don't believe an Enclosure plugin temperature controller currently supports PWM. I believe @raoulh's I2C support is focused on regular (i.e., binary) GPIO. This could be modified to pass a PWM value (rather than binary), however again, an Enclosure plugin temperature controller currently doesn't have the logic to derive (and pass) the PWM value.

Is there a particular reason why you're using I2C, rather than Raspberry Pi GPIO? And are you sure you need PWM? Have you tried to leverage the existing Enclosure plugin temperature controller functionality? This would require you to directly integrate a temperature sensor with the Enclosure plugin. The Enclosure plugin temperature controller would then simply turn your relay on or off (via regular GPIO) based on the target and actual temperature (and an optional deadband).

By "DMT 11 /22", I assume you mean DHT11 and DHT22. You're saying you were never able to successfully integrate a DHT11 or DHT22 temperature and humidity sensor with the Enclosure plugin? It sounds like you're looking to leverage an Enclosure plugin temperature controller. I had asked @raoulh whether he planned to add I2C support to outputs of type “Temperature / Humidity Control”. I don't see where I received an answer. I'm assuming the answer is no. Then there's the question of PWM. Even if @raoulh were to integrate his I2C support with outputs of type “Temperature / Humidity Control”, I don't believe an Enclosure plugin temperature controller currently supports PWM. I believe @raoulh's I2C support is focused on regular (i.e., binary) GPIO. This could be modified to pass a PWM value (rather than binary), however again, an Enclosure plugin temperature controller currently doesn't have the logic to derive (and pass) the PWM value. Is there a particular reason why you're using I2C, rather than Raspberry Pi GPIO? And are you sure you need PWM? Have you tried to leverage the existing Enclosure plugin temperature controller functionality? This would require you to directly integrate a temperature sensor with the Enclosure plugin. The Enclosure plugin temperature controller would then simply turn your relay on or off (via regular GPIO) based on the target and actual temperature (and an optional deadband).

raoulh commented

2021-04-15 07:36:36 +01:00

(Migrated from github.com)

@hartmannf My PR fully support what you want to do. I do exactly that. I have an arduino with temp/humidity + relays on it, and Enclosure plugin controls them using i2c.

@wickedbeernut Temp&hum are supported with my code, but using a specific format, only the value is sent over the i2c bus and all the calibration/configuration of the chip has to be done in the arduino code.
See my example code here https://github.com/raoulh/arduino_i2c_gpio_slave

@hartmannf My PR fully support what you want to do. I do exactly that. I have an arduino with temp/humidity + relays on it, and Enclosure plugin controls them using i2c. @wickedbeernut Temp&hum are supported with my code, but using a specific format, only the value is sent over the i2c bus and all the calibration/configuration of the chip has to be done in the arduino code. See my example code here https://github.com/raoulh/arduino_i2c_gpio_slave

wickedbeernut commented

2021-04-15 15:01:54 +01:00

(Migrated from github.com)

@raoulh Where is your temperature controller logic (i.e., the code that compares the configurable target temperature and the actual temperature)? Are you leveraging an Enclosure plugin output of type "Temperature / Humidity Control" (shown below)?

@raoulh Where is your temperature controller logic (i.e., the code that compares the configurable target temperature and the actual temperature)? Are you leveraging an Enclosure plugin output of type "Temperature / Humidity Control" (shown below)? ![image](https://user-images.githubusercontent.com/47407361/114882639-62fe1600-9dc1-11eb-92a7-10ab31cfdec9.png)

raoulh commented

2021-04-15 15:24:09 +01:00

(Migrated from github.com)

@wickedbeernut
Did you even try my PR??

@wickedbeernut Did you even try my PR?? ![image](https://user-images.githubusercontent.com/1115950/114885434-ee4dca80-9e06-11eb-9c28-93795c094ff7.png)

wickedbeernut commented

2021-04-15 19:53:35 +01:00

(Migrated from github.com)

@wickedbeernut
Did you even try my PR??

No. I had asked you twice (now three times) whether your PR supported I2C in conjunction with Enclosure plugin outputs of type "Temperature / Humidity Control". I never received an answer (until now). I had assumed the answer was no. Clearly, from your screenshot, this is supported. As soon as your PR is folded into the master branch, I will give it shot.

> @wickedbeernut > Did you even try my PR?? No. I had asked you twice (now three times) whether your PR supported I2C in conjunction with Enclosure plugin outputs of type "Temperature / Humidity Control". I never received an answer (until now). I had assumed the answer was no. Clearly, from your screenshot, this is supported. As soon as your PR is folded into the master branch, I will give it shot.

raoulh commented

2021-04-16 07:33:34 +01:00

(Migrated from github.com)

It's written in the main comment of my PR...

hartmannf commented

2021-04-18 19:49:39 +01:00

(Migrated from github.com)

Thank you very much for your answer. At the moment I dont really got time but Ill try that out.

By "DMT 11 /22", I assume you mean DHT11 and DHT22. You're saying you were never able to successfully integrate a DHT11 or DHT22 temperature and humidity sensor with the Enclosure plugin?

You assume absolutely Right of course DHT11/22. I was able to get values on *.py level, so hardware was is working fine.

It sounds like you're looking to leverage an Enclosure plugin temperature controller. I had asked @raoulh whether he planned to add I2C support to outputs of type “Temperature / Humidity Control”. I don't see where I received an answer. I'm assuming the answer is no.

I read the followed message, and now at least it is answerd ;) Yeah hard times for everybody ....

Then there's the question of PWM. Even if @raoulh were to integrate his I2C support with outputs of type “Temperature / Humidity Control”, I don't believe an Enclosure plugin temperature controller currently supports PWM. I believe @raoulh's I2C support is focused on regular (i.e., binary) GPIO. This could be modified to pass a PWM value (rather than binary), however again, an Enclosure plugin temperature controller currently doesn't have the logic to derive (and pass) the PWM value.

I would already be happy to get the actValue to octopi, and send setpoint value out from Octopi to *.py level or arduino over I2C. What and how I am going to control the SolidState Relaiy, is not decided yet. At the moment I got an "old" external Ero Electronic temp controller that controls a SolidState Relay 12V or 24V and as I saw on the osci it is using a PWM. But of course a bit level control might be working as well. On the moment I got the SP value on out of octo I think I am able to get something controling the SolidRelay.

Is there a particular reason why you're using I2C, rather than Raspberry Pi GPIO? And are you sure you need PWM? Have you tried to leverage the existing Enclosure plugin temperature controller functionality? This would require you to directly integrate a temperature sensor with the Enclosure plugin. The Enclosure plugin temperature controller would then simply turn your relay on or off (via regular GPIO) based on the target and actual temperature (and an optional deadband).

Of course it would be also my favor solution to get Gpio directly to in and out to Pi.
Lets say that way, I tried so many things according #368 to get the enclosure plugin to get Read temp an humidity from the sensor (the only thing I missed is that what makes it work bäääääääää). I was only able to get the hardware signal on terminal mode als read the value. I am not so knowledged to get deep into python code to see where it hangs. And honestly also dont have that much time... I am more used to PLC programming and sometimes also some c+ but there is more coping then really writing codes..

Thank you very much for your answer. At the moment I don`t really got time but I`ll try that out. > By "DMT 11 /22", I assume you mean DHT11 and DHT22. You're saying you were never able to successfully integrate a DHT11 or DHT22 temperature and humidity sensor with the Enclosure plugin? > You assume absolutely Right of course DHT11/22. I was able to get values on *.py level, so hardware was is working fine. > It sounds like you're looking to leverage an Enclosure plugin temperature controller. I had asked @raoulh whether he planned to add I2C support to outputs of type “Temperature / Humidity Control”. I don't see where I received an answer. I'm assuming the answer is no. I read the followed message, and now at least it is answerd ;) Yeah hard times for everybody .... > > Then there's the question of PWM. Even if @raoulh were to integrate his I2C support with outputs of type “Temperature / Humidity Control”, I don't believe an Enclosure plugin temperature controller currently supports PWM. I believe @raoulh's I2C support is focused on regular (i.e., binary) GPIO. This could be modified to pass a PWM value (rather than binary), however again, an Enclosure plugin temperature controller currently doesn't have the logic to derive (and pass) the PWM value. I would already be happy to get the actValue to octopi, and send setpoint value out from Octopi to *.py level or arduino over I2C. What and how I am going to control the SolidState Relaiy, is not decided yet. At the moment I got an "old" external Ero Electronic temp controller that controls a SolidState Relay 12V or 24V and as I saw on the osci it is using a PWM. But of course a bit level control might be working as well. On the moment I got the SP value on out of octo I think I am able to get something controling the SolidRelay. > > Is there a particular reason why you're using I2C, rather than Raspberry Pi GPIO? And are you sure you need PWM? Have you tried to leverage the existing Enclosure plugin temperature controller functionality? This would require you to directly integrate a temperature sensor with the Enclosure plugin. The Enclosure plugin temperature controller would then simply turn your relay on or off (via regular GPIO) based on the target and actual temperature (and an optional deadband). Of course it would be also my favor solution to get Gpio directly to in and out to Pi. Let`s say that way, I tried so many things according #368 to get the enclosure plugin to get Read temp an humidity from the sensor (the only thing I missed is that what makes it work bäääääääää). I was only able to get the hardware signal on terminal mode als read the value. I am not so knowledged to get deep into python code to see where it hangs. And honestly also don`t have that much time... I am more used to PLC programming and sometimes also some c+ but there is more coping then really writing codes..

hartmannf commented

2021-04-28 20:47:59 +01:00

(Migrated from github.com)

@hartmannf My PR fully support what you want to do. I do exactly that. I have an arduino with temp/humidity + relays on it, and Enclosure plugin controls them using i2c.

@wickedbeernut Temp&hum are supported with my code, but using a specific format, only the value is sent over the i2c bus and all the calibration/configuration of the chip has to be done in the arduino code.
See my example code here https://github.com/raoulh/arduino_i2c_gpio_slave

@raoulh and @wickedbeernut Thanks guys for work and reply. first test looked promising and i2c worked. once I got coding done I puplish the code for arduino. I got an idee how to regulate the PWM signal

> @hartmannf My PR fully support what you want to do. I do exactly that. I have an arduino with temp/humidity + relays on it, and Enclosure plugin controls them using i2c. > > @wickedbeernut Temp&hum are supported with my code, but using a specific format, only the value is sent over the i2c bus and all the calibration/configuration of the chip has to be done in the arduino code. > See my example code here https://github.com/raoulh/arduino_i2c_gpio_slave @raoulh and @wickedbeernut Thanks guys for work and reply. first test looked promising and i2c worked. once I got coding done I puplish the code for arduino. I got an idee how to regulate the PWM signal

qtemp commented

2021-04-29 06:34:06 +01:00

(Migrated from github.com)

Couple of questions.

What format does the i2c humidity sensor need to return (currently, I'm returning a float but it shows 0)? It also shows with the degrees celsius symbol instead of a percent; can I change this?

How would I add an i2c input for a door sensor (opened/closed)? Currently, I have it as an output but it shows up as a button.

Couple of questions. What format does the i2c humidity sensor need to return (currently, I'm returning a float but it shows 0)? It also shows with the degrees celsius symbol instead of a percent; can I change this? How would I add an i2c input for a door sensor (opened/closed)? Currently, I have it as an output but it shows up as a button.

raoulh commented

2021-04-29 08:35:47 +01:00

(Migrated from github.com)

@qtemp The format is simple as sending the raw 4 bytes of a float. Example arduino code here:

https://github.com/raoulh/arduino_i2c_gpio_slave/blob/master/Prusa3d.ino#L136

union floatBytes
{
    uint8_t bytes[4];
    float value; 
} floatContainer;

floatContainer.value = temperature;
Wire.write(floatContainer.bytes, sizeof(float));

About the celcius/percent symbol, you are right, that's a issue I did not see. I need to figure this out...

For i2c inputs, it's not supported by my PR... You have 2 ways of doing it, polling for the i2c inputs at regular interval (not recommended as you will miss some edge changes at some point), or you need an other pin for an Interrupt pin to tell the code that "something" changed. As I do not have any PIN left to use as an interrupt, I did not implement that...

@qtemp The format is simple as sending the raw 4 bytes of a float. Example arduino code here: https://github.com/raoulh/arduino_i2c_gpio_slave/blob/master/Prusa3d.ino#L136 ```C union floatBytes { uint8_t bytes[4]; float value; } floatContainer; floatContainer.value = temperature; Wire.write(floatContainer.bytes, sizeof(float)); ``` About the celcius/percent symbol, you are right, that's a issue I did not see. I need to figure this out... For i2c inputs, it's not supported by my PR... You have 2 ways of doing it, polling for the i2c inputs at regular interval (not recommended as you will miss some edge changes at some point), or you need an other pin for an Interrupt pin to tell the code that "something" changed. As I do not have any PIN left to use as an interrupt, I did not implement that...

wickedbeernut commented

2021-04-29 17:01:01 +01:00

(Migrated from github.com)

How would I add an i2c input for a door sensor (opened/closed)? Currently, I have it as an output but it shows up as a button.

Are you using a stand-alone, dedicated I2C switch?

You might want to check out a SparkFun Qwiic I2C switch (or button). The SparkFun I2C switch has a built-in FIFO queue. It stores up to 15 switch presses (or clicks) along with the corresponding timestamp. This way you can significantly increase the polling interval without having to worry about missing a switch press. The SparkFun I2C switch is also capable of generating an interrupt if you want to go that route. And, of course, the switch has built-in debounce logic.

If you go the SparkFun Qwiic I2C switch route, make sure the switch has the latest firmware. There was a bug in the queue logic that I fixed. SparkFun has incorporated the fix into the master branch, however, you need to ensure the switch ships with the latest firmware.

I have my own OctoPrint plugin that maps I2C inputs (buttons and switches) to GPIO inputs. It’s completely transparent to the Enclosure plugin. The Enclosure plugin thinks it’s monitoring GPIO inputs when in fact they’re I2C.

> How would I add an i2c input for a door sensor (opened/closed)? Currently, I have it as an output but it shows up as a button. Are you using a stand-alone, dedicated I2C switch? You might want to check out a SparkFun Qwiic I2C switch (or button). The SparkFun I2C switch has a built-in FIFO queue. It stores up to 15 switch presses (or clicks) along with the corresponding timestamp. This way you can significantly increase the polling interval without having to worry about missing a switch press. The SparkFun I2C switch is also capable of generating an interrupt if you want to go that route. And, of course, the switch has built-in debounce logic. If you go the SparkFun Qwiic I2C switch route, make sure the switch has the latest firmware. There was a bug in the queue logic that I fixed. SparkFun has incorporated the fix into the master branch, however, you need to ensure the switch ships with the latest firmware. I have my own OctoPrint plugin that maps I2C inputs (buttons and switches) to GPIO inputs. It’s completely transparent to the Enclosure plugin. The Enclosure plugin thinks it’s monitoring GPIO inputs when in fact they’re I2C.

qtemp commented

2021-04-29 18:55:04 +01:00

(Migrated from github.com)

I'm using an Arduino nano (via https://www.thingiverse.com/thing:2862044) with DHT22 sensors.

I'm using the same floatBytes for returning temperature and humidity. Temperature works.
However, the humidity is always sitting at zero (using the readHumidity function). My temperature stopped responding as well earlier and I had to restart the nano. I'll dig into the values that are getting returned when I get a chance to see what it's trying to send from the arduino.

I was hoping to eventually get into controlling the fan as well as LED lighting from the pi rather than having to open my enclosure door and letting possible fumes escape.

I'm using an Arduino nano (via https://www.thingiverse.com/thing:2862044) with DHT22 sensors. I'm using the same floatBytes for returning temperature and humidity. Temperature works. However, the humidity is always sitting at zero (using the readHumidity function). My temperature stopped responding as well earlier and I had to restart the nano. I'll dig into the values that are getting returned when I get a chance to see what it's trying to send from the arduino. I was hoping to eventually get into controlling the fan as well as LED lighting from the pi rather than having to open my enclosure door and letting possible fumes escape.

qtemp commented

2021-04-30 01:47:49 +01:00

(Migrated from github.com)

So, if I change from "Raw I2C Humidity" to "Raw I2C Temperature" for pulling the humidity it works...other than just displaying the temperature symbol.

So, if I change from "Raw I2C Humidity" to "Raw I2C Temperature" for pulling the humidity it works...other than just displaying the temperature symbol. ![image](https://user-images.githubusercontent.com/22223529/116635247-42d76680-a92c-11eb-8139-315c1b4d2b97.png)

qtemp commented

2021-05-04 04:29:35 +01:00

(Migrated from github.com)

I cobbled my way through it and have it working somewhat in my repository.

I added both 'temp_raw_i2c' and 'hum_raw_i2c' to the list of humidityCapableSensor in enclosure.js.

In init.py changed read_raw_i2c_temp to receive a two floats and return them both to the caller.

    data = bus.read_i2c_block_data(i2caddr, i2creg, 8)
    val = struct.unpack('f', bytearray(data[0:4]))
    fval1 = val[0]
    val = struct.unpack('f', bytearray(data[4:8]))
    fval2 = val[0]
    ...
    return (fval1, fval2)

In my arduino code I build the array of two floats and return them as a byte array.

    float data[2];
    data[0] = (float) t1; // Temp
    data[1] = (float) h1; // Humidity
    Wire.write((uint8_t*) data, sizeof(data));

This really eliminates the need for the hum_raw_i2c, at least for me. Since hum_raw_i2c and temp_raw_i2c shared the same read i2c code, I made the 'humidity' version expect the humidity first and then temp...this of course requires the slave to return the humidity and then zero for the second value if there is no temperature to return.

![image](https://user-images.githubusercontent.com/22223529/116958013-4a1dad80-ac67-11eb-92d5-cbcc37f0b4f0.png) I cobbled my way through it and have it working somewhat in my repository. I added both 'temp_raw_i2c' and 'hum_raw_i2c' to the list of humidityCapableSensor in enclosure.js. In __init__.py changed read_raw_i2c_temp to receive a two floats and return them both to the caller. ``` data = bus.read_i2c_block_data(i2caddr, i2creg, 8) val = struct.unpack('f', bytearray(data[0:4])) fval1 = val[0] val = struct.unpack('f', bytearray(data[4:8])) fval2 = val[0] ... return (fval1, fval2) ``` In my arduino code I build the array of two floats and return them as a byte array. ``` float data[2]; data[0] = (float) t1; // Temp data[1] = (float) h1; // Humidity Wire.write((uint8_t*) data, sizeof(data)); ``` This really eliminates the need for the hum_raw_i2c, at least for me. Since hum_raw_i2c and temp_raw_i2c shared the same read i2c code, I made the 'humidity' version expect the humidity first and then temp...this of course requires the slave to return the humidity and then zero for the second value if there is no temperature to return.

raoulh commented

2021-05-04 12:10:49 +01:00

(Migrated from github.com)

@qtemp Nice 👍 You need to to a new PR as mine was merged in master ;-)

5H3LL3H5 commented

2021-11-10 14:34:43 +00:00

(Migrated from github.com)

Hi all,

short question regarding integration of TI PCF8547 i2c I/O expander. Unfortuntly , this chip is not working against the current enclosure implemention. This is mainly caused by calling write_block_data and read_block_data methods.
This chip does not make use of registers and has a very simple i2c layout. As checked, it can easily driven by the use of write_byte and read_byte methods of smbus2 module.

As second attempt, the integration via the kernel module gpio_pcf853x didn't succeed within the enclosure plugin.
The chip is recognized via the kernel driver and the standard gpio interface is exported via sysfs. Since enclosure uses RPi.GPIO library for gpio access this solution fails also. The RPi.GPIO library accesses gpios over memory mapping via /dev/gpiomem. So external memory/registers are not mapped accordingly.

In my view, best approach would be the usage of WiringPi lib instead of RPi.GPIO to support the standard gpio interface via sysfs. Is this support planned?

Do you see any other option for the integration of PCF8547?

For us, it would be great, we the integratin of the chip goes upstream.

So long

Hi all, short question regarding integration of TI PCF8547 i2c I/O expander. Unfortuntly , this chip is not working against the current enclosure implemention. This is mainly caused by calling write_block_data and read_block_data methods. This chip does not make use of registers and has a very simple i2c layout. As checked, it can easily driven by the use of write_byte and read_byte methods of smbus2 module. As second attempt, the integration via the kernel module gpio_pcf853x didn't succeed within the enclosure plugin. The chip is recognized via the kernel driver and the standard gpio interface is exported via sysfs. Since enclosure uses RPi.GPIO library for gpio access this solution fails also. The RPi.GPIO library accesses gpios over memory mapping via /dev/gpiomem. So external memory/registers are not mapped accordingly. In my view, best approach would be the usage of WiringPi lib instead of RPi.GPIO to support the standard gpio interface via sysfs. Is this support planned? Do you see any other option for the integration of PCF8547? For us, it would be great, we the integratin of the chip goes upstream. So long

👍 1

daveharnett commented

2021-12-02 11:16:09 +00:00

(Migrated from github.com)

Is it fair to say that I2C binary inputs (ie buttons, switches) are not yet supported?

raoulh commented

2021-12-02 11:24:27 +00:00

(Migrated from github.com)

@daveharnett Yes, that is not supported by this PR

daveharnett commented

2021-12-07 13:33:47 +00:00

(Migrated from github.com)

Thanks @raoulh . Do you know if this already on the agenda, or should I make a new feature request?
I'm not conversant with python, but it looks like your PR here should make it a lot easier?

Thanks @raoulh . Do you know if this already on the agenda, or should I make a new feature request? I'm not conversant with python, but it looks like your PR here should make it a lot easier?

5H3LL3H5 commented

2021-12-13 13:30:10 +00:00

(Migrated from github.com)

@daveharnett, @raoulh, @Mcarbuhn . Many thanks for the discussion, what is the current state here? Is a new FR planned?

raoulh commented

2021-12-13 14:32:00 +00:00

(Migrated from github.com)

@daveharnett Actually it's not on my agenda, I don't have time to work on this

@raoulh I have no plan. Enclosure plugin is working the way I need for now

@daveharnett Actually it's not on my agenda, I don't have time to work on this @raoulh I have no plan. Enclosure plugin is working the way I need for now

daveharnett commented

2021-12-13 22:17:23 +00:00

(Migrated from github.com)

@daveharnett Actually it's not on my agenda, I don't have time to work on this
Fair enough raoul. Thanks for getting back to me.

> @daveharnett Actually it's not on my agenda, I don't have time to work on this Fair enough raoul. Thanks for getting back to me.

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: Gandalf/OctoPrint-Enclosure#390