InfluxDB problems with Switch(ON/OFF) and Contact(OPEN/CLOSED) states

Ward · 2017-08-11 17:05:59 UTC

So according to the documentation I can find, the states of Switches and Contacts are supposed to be converted from ON/OFF and OPEN/CLOSED to 1/0. Something isn’t working right with this. I initially noticed problems when I tried to use changedSince and ‘true’ was always returned for a Contact Item. I got curious and included a Switch Item in my influxdb.persist file and sure enough it has the same problem. Here is some debugging logs

    2017-08-11 11:55:01.297 [INFO ] [ipt.Testing changedsince/influxdb...] - Garage Door Contact changed since 5 minutes ago: true

    2017-08-11 11:55:01.646 [INFO ] [ipt.Testing changedSince/influxdb...] - Garage Door last state is: org.openhab.core.persistence.internal.QueryablePersistenceServiceDelegate$1@16ed454

    2017-08-11 11:55:01.816 [INFO ] [ipt.Testing changedsince/influxdb...] - Partition 1 Arm Mode changed since 5 minutes ago: false

    2017-08-11 11:55:02.067 [INFO ] [ipt.Testing changedsince/influxdb...] - Chair Lamp changed since 5 minutes ago: false

    2017-08-11 11:55:02.321 [INFO ] [ipt.Testing changedsince/influxdb...] - Motion Disable Switch changed since 5 minutes ago: true

    2017-08-11 11:55:02.353 [INFO ] [ipt.Testing changedSince/influxdb...] - Motion Disable Switch last state is: org.openhab.core.persistence.internal.QueryablePersistenceServiceDelegate$1@1a92609

Using OH2 2.1 Stable and InfluxDB v1.0 on Openhabian

rlkoshak · 2017-08-11 20:35:17 UTC

So this used to work for sure. And it appears to be saved in my Influx as a 1/0 for a Switch at least for me.

In the above graph, I’m charting the state of my house fan Switch at the bottom. As you can see it is saving the state as a number, at least as far as Graphana is concerned. I’m running a not too recent 2.2.0 SNAPSHOT but this has worked back when I was on 2.1 as well. I’m using whatever the latest Docker version of InfluxDB had as of a couple weeks ago.

I’ve not used changedSince, lastUJpdate, et al on my Items in InfluxDB so can’t say if there might be a bug or something causing the historic data methods to fail.

What do you get when you call lastUpdate? If you get a null that means the Item isn’t found in the DB at all. That would be informative.

Put InfluxDB add-on into debug logging and see if you can track the saving of the Contact and Switch Items. Query InflukxDB directly to see what is being saved there for the switches and contacts.

Ward · 2017-08-12 04:55:56 UTC

Thanks! What’s the namespace for Influxdb logging to include? I tried log4j.logger.org.openhab.persistence.influxdb

With regards to lastupdate indeed it throws an error indicating it is null when I try to log it.

2017-08-12 00:08:24.737 [ERROR] [.script.engine.ScriptExecutionThread] - Rule 'LR Main Zwave Command': cannot invoke method public java.lang.String org.joda.time.base.AbstractInstant.toString() on null

rlkoshak · 2017-08-12 13:40:05 UTC

I don’t know the namesake but I can say that your items are not being saved at all. Double check your persist file and verify the items are configured to be saved. In your rule use lastUpdate(“InfluxDB”) to be certain that you are querying the right service.

Ward · 2017-08-12 21:58:08 UTC

I wasn’t sure how to specify influxdb for lastUpdate (although it is for the others). I will see about it. I am sure the influxdb.persist file is fine… these switch and contacts are setup exactly the same as working number items.

Edit. Okay, it is in the db. lastUpdate(“influxdb”) returns proper datetime value. So it seems like an issue with the historic methods I am trying to use. Still need to look up query syntax for influxdb (or set up temporary graph) to see if values are stored as 0/1

Ward · 2017-08-13 05:29:00 UTC

OK. So I looked up query syntax. I first did ‘Show Measurments’ to verify everything that should be persisted had a measurement created. However when I try to do "Select * FROM measurement_name " I get nothing… even for ones that I know are working. Will keep looking at it

Edit: I tried to graph my values and neither the switch or contact showed anything. A number item worked fine, though.

rlkoshak · 2017-08-13 14:38:54 UTC

All I can add is that when I’m sure something is right, that is usually where my problem lies.

So far, everything you mention points to the Items not being saved at all.

I’m not sure what could be going on.

Ward · 2017-08-14 14:52:14 UTC

So I figured out what was going on… I had set influxdb.persist to record everyminute (I did have a retention policy set…) for these items. Apparently this causes the changedSince for anything over a minute to return true and the lastUpdate to return a the value of the last time the item was recorded. Is this how these functions are supposed to operate? Hard to tell since there is no organized documentation for hardly anything. Just changed these items to everyChange for persistence and it is working OK now.

Thanks for the help!

rlkoshak · 2017-08-14 19:19:35 UTC

Yes for lastUpdate at least. Unfortunately, the persistence engine is unable to tell the difference between a record that was caused by an update to the Item or a periodic save. So it treats every record as an update.

The changedSince seems to be in error though. That should return true only if the Item state was different from the current state since the pasted in time. This should be the case regardless of whether you are saving every change, every update, every minute or a combination of the three.

We would welcome any contributions you may want to make.

everyChange is usually the best choice unless you have a compelling reason to use a different strategy. For example, the everyMinute is usually only used when using rrd4j or when you want to calculate the number of minutes a switch has been ON in the last hour, for instance.

Ward · 2017-08-15 04:55:46 UTC

OK, should I create a ticket anywhere for changedSince? It is really the only one I wanted in the first place and that behavior is what I expected, so good to know I guessed right. It is also why I wasn’t concerned about overdoing it, by having it set to EveryMinute. The persistence strategies were copied over from rrd4j from OH1… thus having everyMinute as well as everyChange.

We would welcome any contributions you may want to make.

Sorry, didn’t mean to sound ungrateful for the free magic dust. Is there an actual API reference anywhere or just different tutorials? I would be happy to contribute, but it would be a bit like the blind leading the blind. I code and am pretty familiar with java, so I should probably just jump in… but it is about I all i can do to find some free time to setup my own house.

Also, how should I get the actual state I had been trying to debug (unsuccessfully) using

Garage_Door.previousState(true, "influxdb").toString

If I wanted to actually use the state I would have to cast it to something appropriate?

rlkoshak · 2017-08-15 14:54:03 UTC

Probably. I think the persistence modules are maintained on the Eclipse SmartHome project, but I could be won’t and they are in the openhab2-addons repo.

It would be good to test with one of the other persistence engines, maybe SQLite so you don’t have to install anything. This will tell them whether it is a problem in shared code or InfluxDB in particular.

All the docs that are complete including API calls, roles language references, readmes for each binding are here.

http://docs.openhab.org

JavaDocs can be found here:

http://www.eclipse.org/smarthome/documentation/javadoc/index.html

There are lots of links to additional resources in the docs as well.

Much of the reference documentation from the old OH 1.x wiki still applies as well.

This is actually documented here:

PreviousState returns a HistoricItem, not just a State. So to get the state you call .state like you would with any other Item type.

Once you have a State you can cast or use it like any other state object. See the following for a Type Conversions article a few of us are working in before adding it to the docs.

It’s ok. I just find that 90% of the time people who complain had about the lack of docs simply have not looked at the docs. A tremendous amount of effort had gone into the OH 2 docs and while a lot remains to be done, it is more complete than most who complain about the docs give them credit for.

Don’t count yourself out as a contributor either. The fact you know Java and can look at and understand the coffee pots you a level above many of the contributors.