History settings getting lost

[Cumulus7]

Hi,

i have a lot of history settings activated. However some of them get turned off every few days. Do you by any chance manage these settings in your adapter? Create the states anew and reset these settings?

All my other history settings in the other adapters i use never showed this behaviour.

Any chance that the "create states for wiffi" might affect the history settings?

THX for your help and greetings, Markus

[t4qjXH8N]

Hey Markus, please set logging to "debug" and send me the log after the history got lost.

[t4qjXH8N]

Sorry, it is already set to debug. Are there any "created state XXX" messages in the log after the history got lost?

[Cumulus7]

Hi Christian, i found some of these "created state" messages around the exact moment where the problem arises:

and

The disabling of the history happens again a few seconds later. See log-file:

log_20190511.txt

Greetings, Markus

[t4qjXH8N]

What is your js-controller version?

[Cumulus7]

[t4qjXH8N]

Hm, I am using the History adapter for logging (not the SQL-logger) and the history is NOT getting lost. I am also using the same js-controller version. Sorry, I have no possibilty to check SQL logging at the moment.

[Cumulus7]

Do you have any idea why the states are created again? Or why they get "lost" in the first place?

I guess that is the reason why the logging is getting disabled.

[t4qjXH8N]

It says states are created, but in fact they are only created if they do not exists. Could you please switch to the history adapter for testing purposes only?

[Cumulus7]

Already did that yesterday evening. I will report back when the problem arises again.

[Cumulus7]

Hi,

can you take a look again at the log-file i posted?

The JSON received by the adapter at

2019-05-11 03:17:27.002 - debug: wiffi-wz.0 Received JSON data from Wiffi. Full message: {"modultyp":"rainyman","vars":

right before disabling the sql-logging seems to contain TWO datasets beginning with

modultyp":"rainyman"

I reformatted the JSON here: JSON received at 03-17-27.002.txt

The second JSON part beginning in line 141 does not contain all states. Do you by any chance then delete the states that are not contained in the JSON?

Greetings, Markus

[Cumulus7]

Yesterday evening the history settings got lost again. (both the normal history settings and sql logging)

Time: 2019-05-16 23:40:22.100

There was a JSON received again with some of the rain-values missing. So the adapter apparently deleted the states and later created them again!

Log_Part_2019-05-16 23-40.txt

[t4qjXH8N]

Yes, I am pretty sure that this is the problem. But how to deal with that? At first, I like the idea that only those states are created that are actually needed. But I think I am going to change the behaviour that way that states are created only.

[Cumulus7]

Hi,

yes, creating and deleting states sounds nice, but problems like above can arise. I think manually deleting old unused states is safer.

A change of this behaviour is greatly appreciated :-)

Greetings, Markus

[t4qjXH8N]

There is a branch issue_13 that behaves so. Could you please check if it is working?

[Cumulus7]

Sorry for the question: how do i most easily update to this branch?

[Cumulus7]

Hi, i still need help with the update to the new branch: how do i do that?

Greetings, Markus

[t4qjXH8N]

In this simple case it is sufficient to download the main.js from the new branch and replace the old main.js.

[Cumulus7]

THX. Just did that. I will report back in two weeks...

[Cumulus7]

Hi, the new branch seems to have solved the problem successfully.

THX a lot! Greetings, Markus