[SOLVED] GIPO looses state after items file edited

Setup, Configuration and Use Beginners
1

Hello,

when I edit a items.file that contains my GIPO items they loose there state and fall back to the default value.

I tried to solve this with a rule but this rule dosen’t get triggered when I change the rules file.

//rule "Initialize GIPO after restart"
rule "set GPIO after restart"
when
    System started
then
    logInfo(filename, "Set GPIO")
    if(Unbound_Heizung_Wohnzimmer.state == ON){
         GPIO_Heizung_Wohnzimmer.sendCommand(ON)
    } else {
        GPIO_Heizung_Wohnzimmer.sendCommand(OFF)
    }
end

This is how my heaters.items file looks like

Switch GPIO_Heizung_Wohnzimmer "Heizung GIPO" (LivingRoom) { gpio="pin:19 activelow:yes initialValue:high" }

Logfile:

2018-09-06 19:36:42.094 [INFO ] [el.core.internal.ModelRepositoryImpl] - Refreshing model 'heaters.items'

2018-09-06 19:36:42.125 [vent.ItemStateChangedEvent] - GPIO_Heizung_Wohnzimmer changed from ON to UNDEF

2018-09-06 19:36:42.635 [vent.ItemStateChangedEvent] - GPIO_Heizung_Wohnzimmer changed from UNDEF to OFF

I do run the latest stable openhabian on a Raspberry PI 2.

Any idea how to solve this?

Thanks!

2

Do you have persistence set up for all the GPIO items?

3

Yes I have.

GPIO_Heizung_Wohnzimmer: strategy = everyChange, restoreOnStartup

I use MySQL as storage and the values are saved in the DB as they should.

4

I assume the GPIO pins are the ones on your RPI, that’s also running OH. Use debug or trace in the logs to see if you can tell whats occurring when you edit a GPIO items file. Maybe open another terminal with a system log running aslo.

5

Probably worth a read of this thread
Your refreshed Items should start out as state NULL

6

Thank for the link.

I now use a changed to UNDEF rule and just check the heating condition again to set the correct state.

7

UNDEF - that’s interesting. I thought Items were created initially with NULL state, and a binding might set UNDEF e.g. in the case of a device read error.

Experimenting (OH 2.3.0), reloading an .items file doesn’t change the state of an Item that you haven’t edited. The existing state is preserved.

If you have edited the Item, it does get set to NULL. But does not trigger any rule listening for change on it.

I suspect what is happening is that the GPIO binding is somehow involved. Maybe reloading an Item bound to a binding looks for a ‘refresh’ value from the binding. And here the binding responds with UNDEF, which gives what you see.

(Just as a comment for later readers - I believe Group Items behave quite differently on an .items file reload.)