Set quality to according value by lost of connection

[GermanBluefox]

If Instance lost connection or alive goes to false set according quality to all states except system.adapter.*

[Apollon77]

puuuhhh this can be much of state changes

[Stabilostick]

What is „according quality to all states“? Default value? Null? Not ack? Something else?

[Apollon77]

We have cool things (that many adapter are not using): https://github.com/ioBroker/ioBroker/blob/master/doc/SCHEMA.md#states , see "q" there

[Apollon77]

But then it would be "generating new state entries with the new quality", correct ?! Because the last received value with a certain quality was still correct back in the time it was generated. SO we would need to add new state values with new timestamp and same (?) valuem, but different quality

[Stabilostick]

I have seen q before. But i forgot about it... If the whole adapter disconnects setting q to 0x42 for all states keeping the actual value seems legit. The history adapter writes now the following sequence:

  {
    "val": 57.64,
    "ack": 1,
    "ts": 1532523709632,
    "q": 0,
    "user": "system.user.admin"
  },
  {
    "val": 57.57,
    "ack": 1,
    "ts": 1532523769628,
    "q": 0,
    "user": "system.user.admin"
  },
  {
    "val": 57.57,
    "ack": 1,
    "ts": 1532523814920,
    "q": 0,
    "user": "system.user.admin",
    "from": "system.adapter.history.0"
  },
  {
    "val": null,
    "ts": 1532523814921,
    "lc": 1532523814921,
    "q": 64,
    "from": "system.adapter.history.0"
  }

When should the new q value appear? Before the null value? What is the right position for reporting?

[Apollon77]

The null is history specific. The idea here is for adapters own data!! So more hm-rpc, alexa2 and all that connect to devices and such.

So history is nearly out in this case. (Will only log the additional values)

[Apollon77]

@GermanBluefox postpone a second try to 2.1?

[Apollon77]

posponed to 2.1

[Apollon77]

We should decide how to continue with this. We had the feature in but it was very problematic. In fact it is about "how to update all relevant states with new quality flag". For smalladapters this is no problem, but for other ones it may slow down the system significantly.

Especially when we also update q on adapter start or clean end (and here even more problematic when this "start" is the iobroker start itself and so ALL adapters doing that.

In my eyes we can only try get that optimized as hell, means we need a special script for that that runs on DB level (lua script for redis and a adoption of that for in mem db) because only that way it could work. Kind of "one command to DB and DB is internally doing all these thousands of updates".

Opinions? With an idea we can also plan in for 3.1

[foxriver76]

In my eyes we can only try get that optimized as hell, means we need a special script for that that runs on DB level (lua script for redis and a adoption of that for in mem db) because only that way it could work.

What about SSCAN on state followed byMSET for redis? Of course sim still needs some extra adaption and maybe Performance is still bad..

[Apollon77]

In fact would be a "SSCAN" to iterate over the states, the MGET to read all states and MSET to set them and then many PUBLISHs to notify all others

And remember that on "stop" of ioBroker this happens for ALL instances "at once"