Serial Binding only persisting "0" to influx

Hi!

I have an item “Waterswitch” which uses the serial binding.

It is persisting ON/OFF in my MySQL DB. I am parallel testing InfluxDB. Openhab stores the correct timestamps in Influx also but only “0”.
Other Switch Items where persisted with 0/1 in Influx.

What is the difference with that serial item?

best regards

Item config?
Persist config?
System?
Java version?

RPi 3B+
OH2.5-3-1
influx 1.7.8
I assume that I am getting the error below on start up because the .persist file has not loaded up yet?There is no queryable persistence service registered with the id ‘influxdb’

Yes that can happen during start up

Can you post your influxdb.persist file, please

Do you mean that the changes to that particular switch are not persisted or that switches are not persistened as ON/OFF but 0/1 influx?

Switches are persisted as 0/1 in influxdb. I guess that was a choice made a the time of the persistence service development. Influxdb is a database more geared towards number storage in the first place so that would have made sense at the time.

Hi,

Only one switch isnt correct in influx(only zeros persisted). All other switches are correct (1/0).
In MySQL the wrong Switch is correct (ON/OFF).

The only difference is that this incorrect Switch uses the serial binding.

OH 2.4
Java 8
I can Post the config Files when im back home.

Can you show the logs of the state changes for this particular switch

This should not affect persistence

@vzorglub

2019-10-09 07:15:25.449 [vent.ItemStateChangedEvent] - Waterswitch changed from OFF to ON
2019-10-09 07:15:25.450 [vent.ItemStateChangedEvent] - Waterswitch changed from ON to OFF

Switch Waterswitch "Waterswitch" (gPersistenceEveryUpdate) { serial="COM4@9600,ON(1),OFF(0)" }

influx persist

Strategies {
    default = everyUpdate
}
Items {    
    gPersistenceEveryUpdate* : strategy = everyUpdate, restoreOnStartup
}

jdbc persist

Strategies {
    default = everyUpdate
}
Items {    
    gPersistenceEveryUpdate* : strategy = everyUpdate, restoreOnStartup
}

System Windows 10 1903

You should have only one restoreOnStartup persistence setup or you will get conflicts at startup.

Turn OFF the SQL persistence. Do the symptoms continue?

1 Like

Your Switch Item has state ON for just one millisecond.
I’m not convinced the persistence service is going to be very good at dealing with that - I’m sure it will get notice of a change, but by the time it has come to store it the state will have changed to OFF (stores 0).
You have the additional complication of storing it twice, in two different DB.

What are you expecting the Switch behaviour to be? What does an incoming data packet look like?

I’m actually fairly impressed openHAB can carry out event bus changes that quickly. What’s the host, it was said both RPi and Windows??

Please use code fences

Items {
* : strategy = everyChange, restoreOnStartup
chamberlainmyq_MyQDoorOpener_6d05aabe_1805433125_doorstatus : strategy = everyChange, restoreOnStartup
lutron_dimmer_2eaf27ce_lightlevel : strategy = everyChange, restoreOnStartup
}

The first line is enough:

Items {
* : strategy = everyChange, restoreOnStartup
}

That means ALL items. No need for duplication

I would advise to set the persistence as above
Remove the persistence service for Influx
Stop Openhab
Delete the database
Remove influx
Reboot
apt update upgrade
Reinstall influx
start openHAB
install influx persistence
restart openHAB

But we started off with this -

Are you now saying it does not store your Item?

@rossko57

I think @Stbowling is mixing things up. He has a different problem which has nothing to do with my topic/problem.

My influx stores only “0” and works for every other switch (stores 0/1).

Okay. So is this switch only ever ON for one millisecond? What about the others?

EDIT - I’m thinking this might be falling into some granularity gap. ON for one millisecond will generate two updates to be persisted (update to ON, update to oFF) - they might both fit into the same time slot on the DB, so the last one overwrites the first one.
I note that influxdb has some kind of ‘precision’ parameter that could affect this.
And/or openHAB’s persistence service may have its own limitations.

You haven’t told us how you know influxdb is storing only 0 and not perhaps also 1 with the same timestamp?

I am sorry
I have removed my post
Yes I was confused

@rossko57 The other switches are homematic switches and remain seconds in ON state not just one ms.

You haven’t told us how you know influxdb is storing only 0 and not perhaps also 1 with the same timestamp?

I just displayed all values in chronograf. There are only “0”. Is this the wrong way to view all values?

I’ve no idea, I don’t know what chronograf is. I believe your results, if it is showing ‘all’ and not time based.

Next step i guess is to use debug to observe write requests to infuxdb.

But I think in the end here, you are going to discover you have run in to some (quite reasonable) limitation of some part of the system. And then will need to develop a workaround.

Why is this switch action so brief, what is its purpose? If SQL can record it, why do you need influx also?

I need mysql persistence because influx is not able to group my month or year.

The switch is an impulse switch on my watermeter. Is it possible to extend the duration with a rule so that influx can persist the “1” ?

Of course. For testing, you might make a dummy Item and have a rule triggered by your original changing to ON only that sets the dummy on. Then have a timer set it back off after your chosen time.

I think if that proves the point, you may be able to configure your original Item serial only for ON, and trigger a rule for timed expiry back to off.