hi
The openhab.cfg contains the config of the io-16 port config (pull-up, output/input…) and sets the io-16 bricklet accordingly whenever openhab boots up. So far so good. But imagine a tinkerforge stack having power loss and gets back up again, the io-16 boots in all pins set to input and further writes from openhab to previously confgured output pins are not working any longer. how can this be solved? As openhab gets notified whenever a tinkerforge stack shows up and knows the config out from openhab.cfg I expect the binding to automatically set the port config accordingly.
2nd question: how is the behaviour on network loss?
3rd question: what’s the magic behind defaultState=keep and keepOnReconnect - this is not really documented deeply enough.
if you don’t use defaultState=keep or keepOnReconnect the pins should be configured to the settings from openhab.cfg every time when the device is discovered. This means normaly on openhab startup but also if the device is reconnected. The state of actuators will be set to the default state HIGH or LOW. If you use defaultState=keep the pin would not be configured in any way even on openhab restarts. If you use keepOnReconnect the pin would not be configured on reconnects (e.g. if the stacks reconnects from a wifi connection).
What’s possible is very limited because of this cheap hardware you will need very complex software - which IMHO is not worth the efforts. If you need more reliability use the industrial bricklets.
ok thanks - this makes sense. I’ll try this immediately.
The io16 is nice as it offers 16 ports and still offering 3 other bricklets per master. How is the software different to a industrial one?
Can you also please shed some light on the lcd_buttons.tactile to detect long_presses? and maybe a short snippet code to detect long_presses also on the io16 and the lcd_buttons?
if restoring the Switch item to a LED on a actuator on the io16 using the persistence restoreOnStartup, shouldn’t the LED light up after a reboot of openhab when the previous stored state what ON? Maybe this is linked to the defaultState thingy.
Thanks so much - I’m 1% away of having a nice wall panel with buttons, led, screen, sensors - the only thing that needs to be reliable are those bottons/leds…
There is no support for long press detection for the buttons. Sorry.
As far as I know there are known issues with restoreOnStartup which is sometimes happening before the binding is activated. May be searching the forum will help.
I searched the forum quite intensively. Still some issues:
restoreOnStartup works but as the binding starts with either defaultState=false (setting the Item to OFF) or defaultState=on (setting the Item to ON) it will never respect the restoreOnStartup value as the binding overwrites the persisted state. I can’t use defaultState=keep as I must configure the ports to be outputs/actuator on startup.
I miss a forth state: defaultState=itemvalue which does not change the value but configures it.
Is there a way to restore the items later in a separate rule (not in “System started”)?
I just want to bring back my LED to on when the Item was saved ON before rebooting openhab and the stack. It doesn’t seem to work no matter what I do.
when removing the defaultState=false at all in the config then the Item value is not affected by the binding, restoreOnStartup works! BUT! the config is not sent! the pins start in input/sensor mode after the tinker stack reboots.
This is just wrong as all information for the config ist in the config but is not applied. It would be an easy fix to either
a) always send the config (except in keep) if the line defaultState is not in the config. This would be preferred.
or
b) the binding SHALL NOT change the Item value on startup - it can send the defaultValue to the IO16 that’s fine but not updating the Item value as this leads exactly into such inconsistency.
If the direction is configured as output, the value is either high or low (set as true or false).
it should have a state “don’t change”.
Even when the API needs a default state the binding should be improved as I accept a defaultState for the pins but post Undefined to the items. This is how the binding should start up. the polling interval will then postUpdate the correct value. Having this, in between the binding start and the next polling interval we have control of how the pins should be from openhab, rather than any hardware settings. This brings back persistence.
As a workaround I created proxy item and restoreOnStartup them, then after the rules as started in the “System started” rule I re-send the value posting an update to the “real” items.
I noticed something else:
the lcd_button have tactile settings which I like very much. They also never fail to catch a press or release - rock solid. However the io16 is bitchy: it sometimes doesn’t catch a press or release (no matter how low I go for the debounce period) and also there is no tactile option. I know the io16 is generalpurpose but many of us use it for buttons and then, tactile would be great! Any pointer as to why the io16 doesn’t catch any rising or falling edge every now and then? my stack is working great - on the same stack there is a lcd with lcd_buttons and they never fail to scan correctly. So it seems to be the io16. I’m on the latest FW btw.
