Issue of the topic:
I have just installed a new installation of OH3 via balenaEtcher on a micro SD.
I followed the install guide and have everything up and running and I can either SSH into OH3 or I can access myopenhab.org
I programmed everything (bindings, rules, things, items, etc) through the OPenHAB dashboard (http://192.168.0.12:8080/ in my case).
I have 8 relays attached to 8 separate pins on the GPIOs of the Pi that control mains voltage outlets in a ganged electrical box.
Everything works great! I can click the switch and the relay CLICKS and power is applied to that outlet and it says so on my dashboard as well as the Log Viewer.
This issue is when I reboot the Pi (via SSH is the only way I know to safely reboot the device)
The dashboard and everything comes back up saying everything should be the same (I’m guessing because I have RRD4J persistence for a chart I use and MapDB persistence. I have been experimenting with all persistence to see if either can help, so far nothing).
The issue is all my GPIO outputs are inverted but the digital switches on my dashboard indicate no change.
Literally all 8 relays are now opposite of what they were just prior to booting back up.
So I have to toggle the switches on my dashboard twice; once to go to the current ACTUAL position of the GPIOs, and a second time to change them back to what they were prior to boot.
Now this happens not when the device is powered off but rather when the device comes back “Online”
I would like the GPIOs to not change states between boots!
2021-08-13 21:51:27.900 [INFO ] [openhab.event.ItemCommandEvent ] - Item 'AirPump' received command ON
2021-08-13 21:51:27.917 [INFO ] [penhab.event.ItemStatePredictedEvent] - Item 'AirPump' predicted to become ON
2021-08-13 21:51:27.961 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'AirPump' changed from OFF to ON
2021-08-13 21:51:28.522 [INFO ] [openhab.event.ItemCommandEvent ] - Item 'AirPump' received command OFF
2021-08-13 21:51:28.537 [INFO ] [penhab.event.ItemStatePredictedEvent] - Item 'AirPump' predicted to become OFF
2021-08-13 21:51:28.546 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'AirPump' changed from ON to OFF
2021-08-13 21:51:30.501 [INFO ] [openhab.event.ItemCommandEvent ] - Item 'SumpPump' received command OFF
2021-08-13 21:51:30.508 [INFO ] [penhab.event.ItemStatePredictedEvent] - Item 'SumpPump' predicted to become OFF
2021-08-13 21:51:30.531 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'SumpPump' changed from ON to OFF
2021-08-13 21:51:31.512 [INFO ] [openhab.event.ItemCommandEvent ] - Item 'SumpPump' received command ON
2021-08-13 21:51:31.532 [INFO ] [penhab.event.ItemStatePredictedEvent] - Item 'SumpPump' predicted to become ON
2021-08-13 21:51:31.541 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'SumpPump' changed from OFF to ON
2021-08-13 21:51:32.218 [INFO ] [openhab.event.ItemCommandEvent ] - Item 'Fertilizer' received command OFF
2021-08-13 21:51:32.224 [INFO ] [penhab.event.ItemStatePredictedEvent] - Item 'Fertilizer' predicted to become OFF
2021-08-13 21:51:32.235 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'Fertilizer' changed from ON to OFF
2021-08-13 21:51:33.182 [INFO ] [openhab.event.ItemCommandEvent ] - Item 'Fertilizer' received command ON
2021-08-13 21:51:33.199 [INFO ] [penhab.event.ItemStatePredictedEvent] - Item 'Fertilizer' predicted to become ON
2021-08-13 21:51:33.209 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'Fertilizer' changed from OFF to ON
2021-08-13 21:51:33.729 [INFO ] [openhab.event.ItemCommandEvent ] - Item 'Heater' received command OFF
2021-08-13 21:51:33.737 [INFO ] [penhab.event.ItemStatePredictedEvent] - Item 'Heater' predicted to become OFF
2021-08-13 21:51:33.758 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'Heater' changed from ON to OFF
2021-08-13 21:51:34.688 [INFO ] [openhab.event.ItemCommandEvent ] - Item 'Heater' received command ON
2021-08-13 21:51:34.709 [INFO ] [penhab.event.ItemStatePredictedEvent] - Item 'Heater' predicted to become ON
2021-08-13 21:51:34.726 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'Heater' changed from OFF to ON
2021-08-13 21:51:35.506 [INFO ] [openhab.event.ItemCommandEvent ] - Item 'UVLight' received command OFF
2021-08-13 21:51:35.515 [INFO ] [penhab.event.ItemStatePredictedEvent] - Item 'UVLight' predicted to become OFF
2021-08-13 21:51:35.532 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'UVLight' changed from ON to OFF
2021-08-13 21:51:36.217 [INFO ] [openhab.event.ItemCommandEvent ] - Item 'UVLight' received command ON
2021-08-13 21:51:36.230 [INFO ] [penhab.event.ItemStatePredictedEvent] - Item 'UVLight' predicted to become ON
2021-08-13 21:51:36.241 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'UVLight' changed from OFF to ON
2021-08-13 21:51:36.986 [INFO ] [openhab.event.ItemCommandEvent ] - Item 'CO2' received command ON
2021-08-13 21:51:36.991 [INFO ] [penhab.event.ItemStatePredictedEvent] - Item 'CO2' predicted to become ON
2021-08-13 21:51:37.010 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'CO2' changed from OFF to ON
2021-08-13 21:51:37.628 [INFO ] [openhab.event.ItemCommandEvent ] - Item 'CO2' received command OFF
2021-08-13 21:51:37.637 [INFO ] [penhab.event.ItemStatePredictedEvent] - Item 'CO2' predicted to become OFF
2021-08-13 21:51:37.647 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'CO2' changed from ON to OFF
2021-08-13 21:51:38.415 [INFO ] [openhab.event.ItemCommandEvent ] - Item 'SumpLight' received command ON
2021-08-13 21:51:38.425 [INFO ] [penhab.event.ItemStatePredictedEvent] - Item 'SumpLight' predicted to become ON
2021-08-13 21:51:38.456 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'SumpLight' changed from OFF to ON
2021-08-13 21:51:39.091 [INFO ] [openhab.event.ItemCommandEvent ] - Item 'SumpLight' received command OFF
2021-08-13 21:51:39.106 [INFO ] [penhab.event.ItemStatePredictedEvent] - Item 'SumpLight' predicted to become OFF
2021-08-13 21:51:39.125 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'SumpLight' changed from ON to OFF
2021-08-13 21:51:39.845 [INFO ] [openhab.event.ItemCommandEvent ] - Item 'Unused' received command OFF
2021-08-13 21:51:39.851 [INFO ] [penhab.event.ItemStatePredictedEvent] - Item 'Unused' predicted to become OFF
2021-08-13 21:51:39.865 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'Unused' changed from ON to OFF
2021-08-13 21:51:40.549 [INFO ] [openhab.event.ItemCommandEvent ] - Item 'Unused' received command ON
2021-08-13 21:51:40.557 [INFO ] [penhab.event.ItemStatePredictedEvent] - Item 'Unused' predicted to become ON
2021-08-13 21:51:40.565 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'Unused' changed from OFF to ON
Let’s clarify a bit. Restore-on-startup never issues commands. It only updates the internal state of an openHAB Item. It does follow from that, an OH Item state may not reflect reality of a device, but it’s not going to reach out to the device.
Lots of commands in your events.log excerpt, but you haven’t told us when that is happening.
We might need to know a bit more about how you have configured your GPIOs - Things, channels.
It’s not clear if you want your real relays to be changed to match what your persistence last captured, or if you want openHAB just to not interfere with however they happen to be.
Something in your system is issuing commands. It’s not your restore/persistence. Commands usually emanate from rules or from the UI, it is not easy to find out where exactly they come from. A UI is a possibility if you have kept a browser page or similar open during a reboot, I suppose.
What happens between openHAB closing down and openHAB restarting is beyond openHABs control, so that can’t happen.
It is possible to make openHAB restore things as they were last recorded from before a closedown, that’s not quite the same thing (and requires some extra effort).
But I think your problem here is some mystery action after the boot, which is not normal and not expected.
Well, there are a number of choices to made there, and your Items clearly are not called SampleOutput1 etc. If you need to keep your configuration secret, it’s not going to help much.
I am super new to coding and all this with OH3. (Only been using it for about a year)
I’m not sure what you are looking for but all I want is for a reboot to NOT change the state of the GPIO.
Literally all my relays are inverted the moment it boots back up. I can hear all the clicks simultaneously.
That’s harder than it needs to be, but let’s just assume there are Switch Items linked to the channels. Something called profiles can influence the links - and there is a profile (‘follow’) that can generate commands BUT this does not produce logged events, so we can rule that out.
However, you might like to double check each Item<->channel link has a ‘default’ or ‘none’ profile,
While I wouldn’t be surprised at the binding or pigpio script messing about, your events.log shows that it is doing as it is told; obeying commands. So we can rule that out too.
Those commands can only come from limited sources - rules or UI, or a few other bindings configured in unusual ways.
Every channel (8 in total) is linked to to an item and they are all set to “Default” profile.
The only rules I have set are the ones I just made recently that revolve around timers. Basically turning things ON and OFF at given times. But it’s only a few items, not all 8.
As for UIs, I also have Openhab-cloud and I’m using the android app to view/control the GPIOs but they show the same states of switches as the dashboard upon reboot (which is inverted to the actual state of the GPIOs)
Well, something is giving your relays commands and its not easy to find out what. It’s a guessing game. You know that rules might be implicated, you know that UI might be implicated, you can remove for elimination purposes. Especially make sure you have no UI connected at reboot time.
Curious what happens if you do power off the Pi, and boot from “cold”.
Exact same thing! Which is the real reason why I wanted this solved. We have frequent power outages here and I don’t have the money for a UPS and the PiHAT that I have, I would still need to program it to work properly (which is a whole other learning experience).
So yeah, when the power comes back on, my phone and habpanel show all the switches are still in the previous/same state, but every relay-switch is inverted.
I even re-installed OpenHAB on a fresh install 3 days ago and did nothing but do the setup process and follow the GPIO guide to add GPIO connectivity and still the same issue.
In the GPIO guide it says to go here and install this: pigpio library
any information here?
Inverted from what? When you power up the Pi, all the GPIO outputs should be “at rest”. Some of your outputs are configured inverted, some are not. I really don’t know which way an ‘inverted’ output considers “at rest”. Does the pattern of relay actuation follow the pattern of config?
When power is restored and the pi has booted back up, all relays the were off are now on, all relays that were on are now off… even if I never touched them or gave them a command.
Some relays (even though I can control them via the gpio commands) are programmed to be always ON and have changed states (like above) uncommanded now to be OFF
People do have all sorts of trouble with this initial state.
None of which explains why you get commands in your events.log
So far as I can see, the binding never reports state of outputs back to openHAB channel, so there is no way to ‘synch up’ Item state without issuing commands anyway.
I begin to have a bad feeling this binding is poorly designed, and issues commands to channel (instead of state updates) to report status.
This would go a long way to explaining the various observations, and you ain’t going to be able to fix that.
That thread contains a couple of alternative suggestions to avoid the use of the binding altogether.
All I want is to control my relays remotely and add timers to them and only act when commanded by me. I thought GPIO was the only way to do this but I’m willing to do anything to get the end result I’m after.
