The problem is with initial state of gpio pins - it’s initiate always ON.
I started openHAB in debug mode and I see in logs:
00:24:18.823 [DEBUG] [.rrd4j.internal.RRD4jActivator:31 ] - RRD4j persistence bundle has been started.
00:24:19.246 [DEBUG] [.p.rrd4j.internal.RRD4jService:345 ] - using default configuration only
00:24:19.318 [DEBUG] [.p.internal.PersistenceManager:147 ] - Initializing rrd4j persistence service.
00:24:20.431 [DEBUG] [.p.internal.PersistenceManager:390 ] - Restored item state from ‘2015-08-16 23:54:09’ for item ‘ROL_Maryla_Gora’ -> ‘OFF’
00:24:20.471 [DEBUG] [.p.internal.PersistenceManager:390 ] - Restored item state from ‘2015-08-16 23:54:10’ for item ‘ROL_Maryla_Dol’ -> ‘OFF’
So, it seems to initiate with last state, but few seconds later state is changing:
00:24:22.819 [INFO ] [runtime.busevents :26 ] - ROL_Maryla_Dol state updated to ON
00:24:23.291 [INFO ] [runtime.busevents :26 ] - ROL_Maryla_Gora state updated to ON
There is no reason for state update, but it’s happening.
Why it happens and how can I prevent it?
When you start openHAB is will load the last state of your ROL_Maryla items from the database. However, this is the last state before openHAB restarted. The pins may no longer be in that state when openHAB comes back up. So openHAB first loads the last value and then a few seconds later it is getting the pin’s actual values. You can exclude the ROL_MARYLA items from your restore on startup config in your persistence setup. This will prevent the last known value from being loaded and result in the actual state of the pins being the first state of the pins.
As to why the states are changing between openHAB restarts, I can’t answer you. Perhaps they are going back to a default when openHAB releases them. Did you make the edits to the init.d script the wiki recommends? If so that is probably where the pin is getting reset.
Thank you for your answer, Rich.
As far as I understand, this is a Raspbeery Pi issue, not openHAB, right? When system starting, openHAB just only initiate GPIO pin as output, and LOW or HIGH state depends from RPi?
Andrzej
That is my understanding as well. There is nothing openHAB can do about it. I’ve not done any work with openHAB and GPIO directly so I’m not sure how to help you with this problem. All my GPIO work has been with WebIOPi and python scripts which report their state via MQTT.
this is quite a problem for me, because i want to control a relay that opens my garage door.
when i restart the raspberry pi the door would open automatically
Very interested in this as well. I am getting the exact same scenario. When the Pi boots it turn all of my relays on. Any help here would be appreciated.
True for me too. OpenHAB 1.7.1 on Raspberry 1. Initial state for switches (GPIO output) is Undefined (with persistence deactivated) then changes to OFF or ON depending on activelow set to yes or no (yes=ON as described above, no=OFF).
In general this is same behaviour that wiringpi has (initializing output to ON).
Initialising output pins with the kernel /sys/class/gpio/… doesn’t do that.
So for me it looks like this is a openHAB issue, because openHAB seems to be using the kernel driver for the GPIOs (at least when it comes to numbering pins).
Or as a question: what is the purpose of openHAB restoring previous states when those states are overwritten by initializing the hardware afterwards. And that without having the workaround to set a default initial state in openHAB but rely on every hardware out there to initialize properly (a.k.a. as the user intends)?
It is actually more common for devices to NOT report their state so restoring the previous value persisted is a way to avoid having your Items undefined at OH reboot. Often it is better and/or easier to deal with rules that trigger based on stale data than UnDef types. If you don’t want this behavior for your GPIO Items, exclude them from the restoreOnStartup strategy in your .persist files.
You can initialize the state of an Item to a user defined hard coded value using a System started triggered rule.
As far as I remember, it doesn’t work properly. I had relays on GPIO, and I wanted always have HIGH state on startup.
I’ve tried System started trigger and it worked in this way:
on RPi reboot all GPIO was undefined, but when OH wast started, all used GPIO switched into HIGH states (depending on System started trigger), but after 1-5 (randomly) sec all used GPIO’s switched into LOW state.
RestoreOnStartup strategy also doesn’t works properly with GPIO - booth for including and excluding items in .persist files.
The only way for me is rebuild relay module to initialize it with HIGH state.
I worked around this by adding an additional relay that disables the 5V power feed to all my relays when it is operated. I then use a rule at startup that after a delay sets all the relays into the state I want them in before setting the activation relay.
That way the system sets everything on at startup including the activation relay which only supplies power to the others when its off. I then restore the states of everything before turning the activation relay off which energises the rest.
Its not as elegant as the binding not setting them on in the first place, but it works reliably.
Hi Kevin, My relay goes HIGH on startup and I have been searching for solution for long time. Wanted to try your work around. Can you please post a wiring diagram?
See simple diagram below. You will need to connect the GPIO Enable relay to one of the pins on the Pi, and then have a rule that contains something like this
rule "initialise GPIO Pins on startup"
when System started then
{ Thread::sleep(5000)
sendCommand(Relay1, OFF)
sendCommand(Relay2, OFF)
sendCommand(GPIOEnableRelay, OFF)
}
end
The value for Thread::sleep will need to be changed if the GPIO Pins haven’t finished initialised before the rule starts, this can be seen from openhab.log
lines similar to
2016-06-09 09:47:54.566 [INFO ] [penhab.io.gpio.linux.GPIOLinux] - registering pin with number '6'
need to come before
2016-06-09 09:47:56.270 [INFO ] [c.internal.ModelRepositoryImpl] - Loading model 'startup.rules'
The rule sets all the pins into their wanted states before turning off the Enable Relay, which then provides power to the rest of them.
Obviously make sure you have relays that are compatible with the Pi’s 3.3V GPIO Pins!!!
I have found myself in the same situation described in this topic, except I am using openHAB 2. I can report that the problem persist in version two:(
I am puzzled that seemingly there is an unaddressed bug in OH. Have anyone found a software work around ?
Is the problem being fixed ?
I am also trying to create a rule on this issue I used the rule which @kevin made and removed the extra switch since I don’t want to be putting extra hardware in this project. Now I am looking to find if it is possible to retain a state for a certain time. If this is possible I will retain the off state untill the initialisation of the system is done after which I would let the inputs work again. Since I am using a 16 relay board on a boat which will control a lot of the lighting and other 12V systems I don’t want to activate all lights when the pi is started up and then switch all lights off by rule after 5 seconds. I am using the Sainsmart 16 relay board. Is there any way to retain the state of the GPIO pins to high unless told otherwise (by the buttons), tried finding it in the files in /usr/share/openhab2/runtime/bin but unfortunately I don’t know much about the coding. Is there anybody who can help before I turn the boat in a flickering christmas tree?
16 Jan: I decided to buy an arduino R3 mega to get around the start up issue. I will use MQTT to drive everything, this because you can force the arduino to boot up with GPIO pin state to high and I have no clue were the software setting is to be found in the settings from the Pi.
Strategies {
default = everyUpdate
}
Items {
// persist all items on every change and restore them from the db at startup
* : strategy = everyChange, restoreOnStartup
}
However it does not work. The relays are switched on when OH2 restarts.
When changes to the items files containing the relays are made, the relays are cycled though ON:
10:51:04.342 [INFO ] [el.core.internal.ModelRepositoryImpl] - Refreshing model 'Relays.items'
10:51:04.470 [INFO ] [marthome.event.ItemStateChangedEvent] - RelayModuleK4 changed from OFF to UNDEF
10:51:04.516 [INFO ] [marthome.event.ItemStateChangedEvent] - RelayModuleK3 changed from OFF to UNDEF
10:51:04.538 [INFO ] [marthome.event.ItemStateChangedEvent] - RelayModuleK2 changed from OFF to UNDEF
10:51:06.502 [INFO ] [marthome.event.ItemStateChangedEvent] - GPIO2 changed from CLOSED to UNDEF
10:51:06.524 [INFO ] [marthome.event.ItemStateChangedEvent] - RelayModuleK1 changed from OFF to UNDEF
10:51:08.487 [INFO ] [marthome.event.ItemStateChangedEvent] - GPIO3 changed from CLOSED to UNDEF
10:51:10.500 [INFO ] [marthome.event.ItemStateChangedEvent] - PIR changed from OPEN to UNDEF
10:51:11.007 [INFO ] [marthome.event.ItemStateChangedEvent] - RelayModuleK1 changed from UNDEF to ON
10:51:11.525 [INFO ] [marthome.event.ItemStateChangedEvent] - RelayModuleK2 changed from UNDEF to ON
10:51:12.035 [INFO ] [marthome.event.ItemStateChangedEvent] - RelayModuleK3 changed from UNDEF to ON
10:51:12.553 [INFO ] [marthome.event.ItemStateChangedEvent] - RelayModuleK4 changed from UNDEF to ON
10:51:13.068 [INFO ] [marthome.event.ItemStateChangedEvent] - PIR changed from UNDEF to OPEN
10:51:13.586 [INFO ] [marthome.event.ItemStateChangedEvent] - GPIO2 changed from UNDEF to CLOSED
10:51:14.123 [INFO ] [marthome.event.ItemStateChangedEvent] - GPIO3 changed from UNDEF to CLOSED
10:51:14.160 [INFO ] [el.core.internal.ModelRepositoryImpl] - Refreshing model 'Relays.items'
10:51:14.254 [INFO ] [marthome.event.ItemStateChangedEvent] - RelayModuleK4 changed from ON to UNDEF
10:51:14.275 [INFO ] [marthome.event.ItemStateChangedEvent] - RelayModuleK3 changed from ON to UNDEF
10:51:14.294 [INFO ] [marthome.event.ItemStateChangedEvent] - RelayModuleK2 changed from ON to UNDEF
10:51:16.271 [INFO ] [marthome.event.ItemStateChangedEvent] - GPIO2 changed from CLOSED to UNDEF
10:51:16.281 [INFO ] [marthome.event.ItemStateChangedEvent] - RelayModuleK1 changed from ON to UNDEF
10:51:18.266 [INFO ] [marthome.event.ItemStateChangedEvent] - GPIO3 changed from CLOSED to UNDEF
10:51:19.142 [INFO ] [org.quartz.core.QuartzScheduler ] - Scheduler openHAB-job-scheduler_$_NON_CLUSTERED started.
10:51:20.289 [INFO ] [marthome.event.ItemStateChangedEvent] - PIR changed from OPEN to UNDEF
10:51:20.788 [INFO ] [marthome.event.ItemStateChangedEvent] - RelayModuleK1 changed from UNDEF to ON
10:51:21.289 [INFO ] [marthome.event.ItemStateChangedEvent] - RelayModuleK2 changed from UNDEF to ON
10:51:21.820 [INFO ] [marthome.event.ItemStateChangedEvent] - RelayModuleK3 changed from UNDEF to ON
10:51:22.328 [INFO ] [marthome.event.ItemStateChangedEvent] - RelayModuleK4 changed from UNDEF to ON
10:51:22.842 [INFO ] [marthome.event.ItemStateChangedEvent] - PIR changed from UNDEF to OPEN
10:51:23.360 [INFO ] [marthome.event.ItemStateChangedEvent] - GPIO2 changed from UNDEF to CLOSED
10:51:23.896 [INFO ] [marthome.event.ItemStateChangedEvent] - GPIO3 changed from UNDEF to CLOSED
10:51:47.574 [INFO ] [smarthome.event.ItemCommandEvent ] - Item 'RelayModuleK1' received command OFF
10:51:47.605 [INFO ] [org.quartz.core.QuartzScheduler ] - Scheduler openHAB-job-scheduler_$_NON_CLUSTERED started.
10:51:47.617 [INFO ] [smarthome.event.ItemCommandEvent ] - Item 'RelayModuleK2' received command OFF
10:51:47.644 [INFO ] [smarthome.event.ItemCommandEvent ] - Item 'RelayModuleK3' received command OFF
10:51:47.664 [INFO ] [marthome.event.ItemStateChangedEvent] - RelayModuleK2 changed from ON to OFF
10:51:47.684 [INFO ] [smarthome.event.ItemCommandEvent ] - Item 'RelayModuleK4' received command OFF
10:51:47.689 [INFO ] [marthome.event.ItemStateChangedEvent] - RelayModuleK3 changed from ON to OFF
10:51:47.738 [INFO ] [marthome.event.ItemStateChangedEvent] - RelayModuleK1 changed from ON to OFF
10:51:47.750 [INFO ] [marthome.event.ItemStateChangedEvent] - RelayModuleK4 changed from ON to OFF
Did you add the opanhab to the gpio user? Or did you try to run OH as root?
/ persistence strategies have a name and a definition and are referred to in the "Items" section
Strategies {
everyMinute: "0 * * * * ?"
everyHour : "0 0 * * * ?"
everyDay : "0 0 0 * * ?"
// if no strategy is specified for an item entry below, the default list will be used
default = everyChange
}
/*
* Each line in this section defines for which item(s) which strategy(ies) should be applied.
* You can list single items, use "*" for all items or "groupitem*" for all members of a group
* item (excl. the group item itself).
*/
Items {
// persist all items once a day and on every change and restore them from the db at startup
* : strategy = everyChange, everyDay, restoreOnStartup
// additionally, persist all temperature and weather values every hour
//Temperature*, Weather* : strategy = everyHour
}
It does not work but I think I am not using it correctly. I have copied the code in a file called rrd4j.persistence in the folder /etc/openhab2/persitence. I installed the rrd4j persistence trough the paperui addons and I did add the openhab to the GPIO group. Aso I found this on the github:
NOTE: rrd4j is for storing numbers only. Attempting to use rrd4j to store complex datatypes (eg. for restore-on-startup) will not work.
Also:
I am trying to understand how this code works especially the first part under the strategies I especially what do the 0’s and *'s mean?? and I am trying to understand the first command do I need to add any code to the .items file??
edit: look at the initialValue possibility at the end of this post
it’s some time ago the topic was started but i also searched a solution for this problem. Here I post you my solution to get the GPIO Pins set to HIGH as initial state.
The problem with activelow is that they are set initially to ON, which is LOW - and without activelow they are set to OFF, which is also LOW. That doesn’t work well with activelow Relais, the door will be opened automatically on startup…
So here my solution for this issue:
rule "System start"
when
System started
then
sendBroadcastNotification("The System started!")
executeCommandLine("gpio -g write 17 1") // Set the output to HIGH
executeCommandLine("gpio -g mode 17 out") // Set PIN17 as output (before that it will be a high impedance input, i guess)
executeCommandLine("gpio -g write 17 1") // Set the output again, just to be sure
end
rule "open door"
when
Item DoorOpenButton changed to ON
then
executeCommandLine("gpio -g write 17 0") // set the output to low, to activate the Relais..
Thread::sleep(300)
executeCommandLine("gpio -g write 17 1")
DoorOpenButton.sendCommand(OFF) // that the button is reset automatically
end
note: the output is not configured or declared as an item in openhab! (do not add a Switch with that pin:17 as an item…)
Edit: if not done yet you first need to install WiringPi on the Raspberry:
git clone git://git.drogon.net/wiringPi
cd wiringPi
./build
Edit: now it is easily possible with GPIO binding by setting the initialValue:
