SOLVED - MiOS Binding Switch Synchronisation

My VeraEdge is successfully connected to OpenHAB via the MiOS binding. So far I’ve only added one switch to my sitemap (and no rules for any of the MiOS items) just to make sure that everything is working.

The good news is that the switch works. I can successfully control my christmas tree lights via the OpenHAB UI and an Aeon Labs SmartSwitch Energy.

The bad news is that the UI doesn’t consistently show the correct on/off state for the switch. I’ve had the tree lights on all morning. While testing some weather binding settings, I’ve refreshed the sitemap and UI quite a few times, and after a while the switch in the UI started to show as “off,” even though the lights are still on and haven’t been switch via OpenHAB or Vera.

When I clicked it “on,” nothing happened, since the lights we already on. And when I clicked it off, the lights turned off. So ti seems like the control still works as expected, but the sitemap is periodically showing the switch in the wrong state.

Is this expected behavior? Is there anything I can do to fix it?

Do you have persistence setup? If not or if you don’t have the restoreOnStartup strategy set it might be resetting the value of the switch to Undefined or some default (I don’t know the MiOS binding) when you reload your Items files for your other changes.

Look in events.log to see when the switch is changing to OFF and try to correlate that event with what other activities you were doing at the time.

When I reinstalled everything the other day, I followed this tutorial. About 3/4 of the way down the page is a section about setting up My.OpenHAB that said to set persistence in openhab.cfg to :


and to add a file called myopenhab.persist containing the following:

Strategies {
default = everyChange
Items {
* : strategy = everyChange

So, that’s what I did. I don’t know much about persistence, so I haven’t set anything else… at least, not intentionally.

I’ll dig around in the logs now and see if I can find where the switch changed to OFF.

The my.openhab persistence is only to support communication with my.openhab. You need to set up another persistence to store and restore values to their previous state on a restart of openHAB or a reloading of your rules or items.

See the Persistence page for a detailed discussion of how to set up and configure persistence. The rrd4j persistence DB is the default for openHAB but others are available to you.

I didn’t find anything setting the switch to OFF is the events.log. So I ran a tail -f on the events log and then started replicating what I had been doing.

It looks like the switch on the UI gets set to OFF when I resave the .items file. However, nothing shows up in the events.log to indicate the change.

Aha. Well, that makes sense with the behavior I just found. Thanks. I’ll take a look at that link and get persistence set up.

OK, I read the persistence wiki, and I still have a few questions.

Most importantly, there’s nothing in the wiki about the persistence default line in openhab.cfg. Is it possible to have the my.openHAB persistence for my.openHAB to work, and have rrd4j set as a default local persistence engine?

If so, how does that look in openhab.cfg?
If not, how do I give items rrd4j persistence?

I have the rrd4j.persistence file from the demo in my persistence directory, and I’ve added the SmartSwitch (and its associated items) to the list of items to track.

`// persistence strategies have a name and a definition and are referred to in the "Items" section
Strategies {
	// for rrd charts, we need a cron strategy
	everyMinute : "0 * * * * ?"

Items {
DemoSwitch,NoOfLights,Window_GF_Toilet,Heating*,Smart* : strategy = everyChange, everyMinute, restoreOnStartup
	// let's only store temperature values in rrd
Temperature*,Weather_Chart* : strategy = everyMinute, restoreOnStartup

What’s next?

The default persistence in openhab.cfg is for persistence requests. So you can persist with as many persistence services as you want, each item in *.persist will be persisted with the defined strategies. Then if you poll data from persistence, you need to give a parameter for non-default persistence services, e.g. myItem.historicState(now.toDateMidnight,"mysql")
If mysql is the default persistence, you can omit the last term: myItem.historicState(now.toDateMidnight)

A few quick things:

  • With the MiOS Binding each time openHAB is fully restarted, the Binding will pull the origin values over from your Vera, effectively resetting the system to be consistent with MiOS/Vera.
  • If you edit an openHAB Items file, Rules file (etc), the system will blow away any/most/all in-memory state within openHAB - this typically comes as a surprise to MiOS/Vera users… it did to me :wink:
  • Establishing persistence can save some heartache in this space, but not all openHAB Persistence implementations are created equal (RRD doesn’t save all Item types, others require you to setup extra components (like mysql, et-al))
  • The closest approximation to MiOS-style persistence (storage without history) is the MapDB Persistence Binding, this is what I use as my primary. I also have RRD configured for the Numeric/Charted data, so I end up with both a mapdb.persist, and a rrd4j.persist)
  • If you use MapDB Persistence, grab the one from the Cloudbees build (1.8.x) since it has some fixes you’ll want.

Did you use the MiOS Item Generator to build your Items file, or did you built it by hand?

If you change the Switch in MiOS, by scene or MiOS UI, is it changing in the openHAB events.log file?
and for openHAB, if it’s changed there are you seeing it change under MiOS?

Thanks, @guessed.

I’ll take a look at that MapDB persistence binding. It would be nice to have state storage for switches and things, so that they always stay synchronized with the actual relays and dimmers that they control. Although, ideally I won’t be updating .items and .rules indefinitely, and I can let the system chug along without worrying about restarts throwing things off.

I used the MiOS Item Generator to build the items file. It did a great job, and boy was I relieved! I was not looking forward to figuring all of those devices out! Although HTML and CSS came rather naturally to me, I’m finding the more “code” oriented things to be pretty challenging. When I read the wikis for OpenHAB and bindings, I often get the feeling that I’m missing a lot of things that would be instantly obvious to people more familiar with programming languages.

Anyway, as for your last question: I have an Enerwave 7-scene controller that I have set up in Vera to control the same switch that the tree lights are on. When I use that to turn the switch on or off, the OpenHAB UI changes as well, nearly instantaneously. If I try to turn the lights on of off directly from the “devices” page in Vera UI7, though, it doesn’t always update. But, to be fair, UI7 doesn’t always update either, or even control the light correctly. That’s the whole reason I’ve decided to try OpenHAB. :smile:

1 Like

I’ve got MapDB set up and tracking the status of all of my items. Now, the reloads that happen when I save a .items file no longer knock the UI switches out of sync.
Last night I did a LOT of reading and re-reading and re-re-reading of the wiki and various threads on this forum and, at some point, something clicked. Persistence makes sense now.

Now it’s time to start coming up with some rules. Otherwise, it isn’t home automation, it’s just remote control.