restoreOnStartup persistence doesn't work at my GPIO pins

Setup, Configuration and Use Beginners
, ,
1
  • Platform information:
    • Hardware: Raspberry Pi 3 Model B
    • OS: openHABianPi
    • Java Runtime Environment: openjdk version “1.8.0_152”
    • openHAB version: openHAB 2.2.0-1 (Release Build)

Hallo!
I have set up my OpenHAB installation and added InfluxDB and Grafana as assisted with OpenHABianPi and this topic: https://community.openhab.org/t/13761
That works quite well, I can see item changes with timestamp in Grafana - so I assume that persistence setup for database connection is okay - database entry for my GPIO Switch is:

2018-02-06 21:16:52	1.00

Now I decide to restart my openHAB instance, but the GPIO Switch doesn’t return in previous state, despites I have set restoreOnStartup
Documentation says, that restoreOnStartup just jumps in when item state is UNDEF but my GPIO Pins wake up in NULL state - so to try out I wrote a rule that sets it to UNDEF on startup, but that doesn’t help :frowning:

  • configurations:
    • Items configuration:
Switch DesktopLight_Switch "Desktop Light" (GP_Conn_RPI) {gpio="pin:13"}
  • Sitemap configuration - not relevant, but switch is used there
  • Rules code:
rule "Set correct init state"
when
    System started
then
    DesktopLight_Switch.postUpdate(UNDEF)
end
  • Persistence configuration:
Items {
    DesktopLight_Switch : strategy = everyChange, restoreOnStartup
}
  • logs generated:
2018-02-06 21:16:52.225 [ome.event.ItemCommandEvent] - Item 'DesktopLight_Switch' received command ON
2018-02-06 21:16:52.244 [vent.ItemStateChangedEvent] - DesktopLight_Switch changed from OFF to ON
// now at some point shut down OpenHAB and restart it again
2018-02-06 22:19:40.280 [INFO ] [basic.internal.servlet.WebAppServlet] - Stopped Basic UI
2018-02-06 22:20:08.603 [INFO ] [.dashboard.internal.DashboardService] - Stopped dashboard
2018-02-06 22:20:56.558 [INFO ] [.dashboard.internal.DashboardService] - Started dashboard at http://192.168.0.1:8080
2018-02-06 22:21:03.626 [INFO ] [el.core.internal.ModelRepositoryImpl] - Loading model 'gpio.items'
2018-02-06 22:21:04.313 [INFO ] [el.core.internal.ModelRepositoryImpl] - Loading model 'influxdb.persist'
2018-02-06 22:21:09.666 [INFO ] [el.core.internal.ModelRepositoryImpl] - Loading model 'startup.rules'
2018-02-06 22:21:10.354 [INFO ] [el.core.internal.ModelRepositoryImpl] - Loading model 'full.sitemap'
2018-02-06 22:21:15.010 [vent.ItemStateChangedEvent] - DesktopLight_Switch changed from NULL to UNDEF
2018-02-06 22:21:15.561 [vent.ItemStateChangedEvent] - DesktopLight_Switch changed from UNDEF to OFF

So everything is loaded without an error message, but state restore doesn’t work.
If I skip my test rule, DesktopLight_Switch changes from NULL to OFF (instead of ON which is the last recorded state)

So what am I doing wrong? How can I get additional logs to debug issue?

Thank’s in advance

2

Unless I’m misunderstanding what you mean by “the GPIO Switch doesn’t return in previous state” I think you misunderstand what restoreOnStartup does. It only changes the state of the Item in OH. It does not go out to the binding and restore the state of the device. You need to write a system started Rule for that.

rule "Set GPIOs"
when
    System started
then
    Thread::sleep(1000) // need to experiment to find the right value to ensure all the Items have been restored
    MyGPIOItem1.sendCommand(MyGPIOItem1.state)
    ...
end

You cannot force a restoreOnStartup from your Rules. It only occurs when OH reads in the .items files or restarts.

3

I agree.

@StefanMUC be careful restoring GPIO pins and/or making rules do something on restore. For example, you wouldn’t want to restore your front door to open when your OH reboots:

You open your door -> OH crashes -> you leave the house -> OH reboots and comes back up and opens your door.

4

@rlkoshak
Thank’s for the clarification - the difference wasn’t known to me.
What I want to do in blunt words: It anoys me that OpenHAB turns off my desk lamp every time I change something in my gpio.items file, so I want to restore previous desk lamp (hardware) state after restart.

So thank you for your explanation and that I do have to do a second step - I will do this, but am I right from the logs, that even the first step “OpenHAB restores the item state” doesn’t work? Without any rules I get this logs:

2018-02-07 18:43:23.531 [vent.ItemStateChangedEvent] - DesktopLight_Switch changed from OFF to ON
// triggering OpenHAB restart
2018-02-07 18:44:22.528 [vent.ItemStateChangedEvent] - DesktopLight_Switch changed from ON to UNDEF
// OpenHAB restart done
2018-02-07 18:45:01.745 [vent.ItemStateChangedEvent] - DesktopLight_Switch changed from NULL to OFF

With your explanation I would expect the item state being changed to ON, but GPIO still being off - or what am I now getting wrong?

@luckymallari
Thanks for that one, I know that and will keep that in mind! It can even get worse with watering the plants :wink:
I know how to design that fail-save, and I promise to not connect my front door to OpenHAB (I wouldn’t do that anyways because of security concerns)

5

@rlkoshak
I included your rule, and startup now looks like this:

2018-02-07 19:10:59.720 [vent.ItemStateChangedEvent] - DesktopLight_Switch changed from NULL to OFF
2018-02-07 19:11:01.656 [ome.event.ItemCommandEvent] - Item 'DesktopLight_Switch' received command OFF

This OFF-Command from the rule doesn’t get logged to InfluxDB, but manual ON and OFF commands (e.g. PaperUI / Android App) still get logged to InfluxDB

6

I’m not 100% certain that the restoreOnStartup does not show up on the Event Bus and therefore would not be logged out to events.log.

It is also possible that that the GPIO binding is modifying the Item after the restore on startup.

When I restart OH I see log entries of my Items going from NULL to their restored stated. I never see them going to UNDEF unless I happen to have expire binding configured to do that.

I don’t use the GPIO binding and given the number of problems I see on this forum from people who use it I can’t say I would recommend it.

7

@rlkoshak
Okay… I just started with GPIO because for me that was the first “small step” that I could do without bringing too much complexity into learning OpenHAB. I thought: Do one small step, understand it, do next step.

Here some results of further testing:

I used this rule:

rule "Restore GPIO states"
when
    System started
then
    logInfo("startup.rules", "Executing »Restore GPIO states« rules")
    Thread::sleep(1000)
    DesktopLight_Switch.sendCommand(DesktopLight_Switch.previousState.state)
end

Logging after startup of OpenHAB says:

2018-02-07 21:04:13.104 [INFO ] [.dashboard.internal.DashboardService] - Started dashboard at http://192.168.0.1:8080
2018-02-07 21:04:20.186 [INFO ] [el.core.internal.ModelRepositoryImpl] - Loading model 'gpio.items'
2018-02-07 21:04:20.891 [INFO ] [el.core.internal.ModelRepositoryImpl] - Loading model 'influxdb.persist'
2018-02-07 21:04:26.258 [INFO ] [el.core.internal.ModelRepositoryImpl] - Loading model 'startup.rules'
2018-02-07 21:04:31.652 [INFO ] [smarthome.model.script.startup.rules] - Executing »Restore GPIO states« rules
2018-02-07 21:04:32.673 [WARN ] [nce.extensions.PersistenceExtensions] - There is no queryable persistence service registered with the id 'influxdb'
2018-02-07 21:04:32.680 [ERROR] [ntime.internal.engine.RuleEngineImpl] - Error during the execution of startup rule 'Restore GPIO states': cannot invoke method public abstract org.eclipse.smarthome.core.types.State org.eclipse.smarthome.core.persistence.HistoricItem.getState() on null
2018-02-07 21:04:34.443 [vent.ItemStateChangedEvent] - DesktopLight_Switch changed from NULL to OFF
// manual save of startup.rules to trigger refresh
2018-02-07 21:05:58.076 [INFO ] [el.core.internal.ModelRepositoryImpl] - Refreshing model 'startup.rules'
2018-02-07 21:05:58.307 [INFO ] [el.core.internal.ModelRepositoryImpl] - Refreshing model 'startup.rules'
2018-02-07 21:06:03.530 [INFO ] [smarthome.model.script.startup.rules] - Executing »Restore GPIO states« rules
2018-02-07 21:06:04.696 [ome.event.ItemCommandEvent] - Item 'DesktopLight_Switch' received command ON
2018-02-07 21:06:04.702 [vent.ItemStateChangedEvent] - DesktopLight_Switch changed from OFF to ON

So seems as InfluxDB persistence is very slow until finally started up?

So I solved the problem of restoring the state after bootup, but there still is something wrong about the GPIO binding, because refreshing the gpio.items still turns off my desktop light (and loggs an OFF to InfluxDB). System Startup rule isn’t triggered during refresh.

8

Okay, I did a little research on this topic: It seems as it’s known that GPIO binding doesn’t support restoreOnStartup, comment on Dec 2016 on this bug report from Aug 2016 mentions it: https://github.com/openhab/openhab1-addons/issues/4583

There’s an issue for a new GPIO binding with less bugs: https://github.com/openhab/openhab2-addons/issues/1707
There’s even a pull request: https://github.com/openhab/openhab2-addons/pull/1334 - but it only will continue starting in Jun 2018
It will be based on Pi4J http://pi4j.com/ - but with non-privileged acces for GPIO, there’s no PWM: http://www.savagehomeautomation.com/projects/pi4j-now-supports-non-privileged-access-no-more-rootsudo.html (which is the next thing I planned to do…)

So I guess, for now the best way to do GPIO is using python scripts like in https://community.openhab.org/t/34030

9

Or run a separate Python service. See

10

Thanks for the project - but as far as I can tell from the source https://github.com/rkoshak/sensorReporter/blob/master/rpiGPIOActuator.py it doesn’t support PWM, correct?

11

You would have to implement that. But since you have to implement that anyway why not inherit the MQTT and HTTP REST stuff built in and just have to write the PWM stuff.

12

Have you found any solution to restore GPIO’s items after restart ?

I have exactly same problem:

2018-10-20 23:11:28.694 [INFO ] [el.core.internal.ModelRepositoryImpl] - Refreshing model 'moj.items'
2018-10-20 23:11:28.980 [vent.ItemStateChangedEvent] - CWU changed from OFF to UNDEF
2018-10-20 23:11:28.991 [vent.ItemStateChangedEvent] - GWC changed from OFF to UNDEF
2018-10-20 23:11:32.584 [vent.ItemStateChangedEvent] - GWC changed from UNDEF to OFF
2018-10-20 23:11:33.851 [vent.ItemStateChangedEvent] - CWU changed from UNDEF to OFF

Those changes are only for items connected with GPIO binding.
Using previousState.state doesn’t work in my case, because it set always OFF, since during restart item changed ON->UNDEF->OFF
I tried with historicState but it is tricky.

13

Sorry for not replying in a timely manner: No I didn’t search for a solution, I currently can live with that state and I’m moving away from a Raspberry Pi based solution (Flash memory wears out too fast and I want to do more with my server).

If you really need it I would recommend you to use an external script like https://github.com/rkoshak/sensorReporter from @rlkoshak, and connect that to OpenHAB via MQTT (or REST). That even continues to run when you restart OpenHAB.