Open MarkusThur opened 1 year ago
I see a few issues here.
UID: gpio:pigpio-remote:shoppi label: ShopPi GPIO thingTypeUID: gpio:pigpio-remote configuration: port: 8888 host: 192.168.164.5 heartBeatInterval: 10000 outputConnectAction: REFRESH outputReconnectAction: REFRESH outputDisconnectAction: SETUNDEF inputConnectAction: REFRESH inputReconnectAction: REFRESH inputDisconnectAction: NOTHING
I do not think that a third pin type of gpio-digital-input-output would be beneficial. But, there may be a possibility of establishing a pigpiod listener on an output pin to where the pigpiod daemon on the Raspi would report external changes back to OpenHAB. I have not tested this and do not know if it is possible or if it is supported by pigpiod. I do know that you can poll the state of an output pin, but I am not sure if you can listen for events on an output pin. My current binding just simply polls the state when needed.
Let's start by seeing if you can configure the Connect/Reconnect actions and see if they are working. Then we can see if a periodic REFRESH on the outputs would work for reporting external changes to the outputs.
Regards, Jeremy
As a follow up, the binding does initialize the direction (INPUT/OUTPUT) of a gpio pin. Does this cause flicker? I would think that if the kernel overlay sets a pin to OUTPUT at boot and then OpenHAB re-initializes a pin to OUTPUT there would be no corresponding flicker. I could be wrong though.
Regards, Jeremy
@jeremyrumpf
sorry, that I respond a bit late, as I was very busy.. And I have a lot of thank you and answers for you :-)
Thank you for the thing with the advanced button, didn't see it before.. Yes a timer induced or event induced REFRESH also does do the trick.. Am not sure it is elegant or if it uses more or less ressources, but it definitely works.
Configuring the same pin within openHAB as input and then as output also does do the trick. (that's why I ask for a third PIN Mode (output [read/write]) which would make it possible to do it more easy.
Answer to your question:
Your Environment
openHABian with openHAB in newest release version with GPIO Binding in newest release version on a Raspberry Pi 3B (14.03.2023)
By intention I am using the UI Configuration only and not the configuration by config files.
openHABian shall provide output control over 4 relais connected to GPIO 4, 6, 22, 26, those four get initialized during boot to output mode and state low. The Kernel overlay GPIO-Fan gets loaded and initiaized to use GPIO 26 as the FAN Control pin. pigpiod is up, running and working.
The output pins can be set and read properly with the propriate pigs command. The fan works as exspected turning on at 60°C, turning off at 50°C as by the kernel overlay.
Configuration in UI of openHAB 3, first try
added via UI a thing Identifier: gpio:pigpio-remote:openHAB networkadress: 127.0.0.1 Port: 8888
then added 4 channels for the four output pins 4, 6, 22, 26
which lead to a code looking like this:
Then created Model and items from those channels and added controls for the Items to pages overview:
In this try it in principle worked fine, I could turn on and of the channels with the toggel cards, as well as the oh-cards are representing the status according to the toggle cards. But this starts to fail, once the overlay starts the ventilator on GPIO26 (channel1) or something else turns on or off one of the outputs.. (e.g. I with a pigs command from console or another Raspi using the remoteGPIO Interface). The gui does not represent that. This seems to be, because the channel for a gpio-output is a "write only channel". This maybe right behaviour or not.. I found in the documentations of openHAB both philospophies as well as I found in other plug ins both behaviours.. There are plugins like the Hue Bridge plugin, that updates the channel once the state of a Zigbee device changed (ok, zigbee protocol may send a confirm after a successful command), where pigpio does not automatical send a notification if something changed (but it is possible to read a output pin to get awareness of the actual state, which is also represented in the advanced value of a input-channel delay time, which allows to wait for a configurable time after a command before next read attempt).
<feature request part 1> Furthermore there is the change from @jeremyrumpf , which allows to control a heartbeat, and behaviour of in and outputs on disconnect, reconnect and so on. This is not propagated to the config UI, which could help a bit. As u can see, I manually added heartbeat to the config as u can see, but those values shoud be settable through a advanced option in the UI
After this it tried to work around that by also defining a input-channels on those four channels.. (yes this workaround works, but is critical and instable as I will discribe here).. so my Configuration of the pins and channels looks like this:
This imediately has a issue, as those pins may get initialized as inputs and output by this, as the binding does initialize them. This means you have to take control that the pin is first set to input and then to output and not vice versa. This is not properly controllable by the UI. <feature request part 2> Option that controlls if the binding tries to initialize a GPIO Pin or not, with default behaviour "do not initialize", as someone using GPIOs should have set them to correct operation mode during boot already (e.g. to prevent flicker during boot on outputs).
From those things i created a item pigpio-Gerät, which hosts four Channel items (Kanal 1 to Kanal 4), each of Type: switch Semantic class: point
which are linked to both the input-channel and the output-channel of the corresponding GPIO of the pigpio thing.
This in principle works, but has at least by UI configuration some flaws.
And here we come to <feature request 3> which has two option: Option a, prefered: introduce a third type of channel to the gpio device
gpio-digital-output (in/out)
additional to the existing channel types
gpio-digital-output (in/out)
then could read the state of the GPIO in a controlled manner, which could be set by a parameter {e.g. every 500ms, 1s, 5s, 10s etc) this would be fast enough.Option b, not prefered: change the behaviour of
gpio-digital-output
to be a read / write channel, and update rate 0s would mean it is a outputchannel with the old behaviour.Thank you for reading that much :-)