search

mschlenstedt / LoxBerry-Plugin-Stats4Lox-NG

Apache License 2.0
6 stars 3 forks source link

"Default" attribute difficult to map for MQTTLive #111

Closed Jakob-Gliwa closed 2 years ago

Jakob-Gliwa commented 3 years ago

Example topic: "publish s4l/mqttlive/1/Intelligente_Raumregelung_Badezimmer/Default <v.3>"

When using MQTTLive it is needed to connect the Loxone component with the virtual output command that sends the data via MQTT.

I'm not too deep into the topic, but I see two potential problems with the "Default" values in this context:

  1. Finding the right output for "Default" attributes seems to be non-trivial (for example for the "Intelligente Raumregelung").
  2. As far as I understand "Default" and "AQ" (for example for sensors) can give different values. But when using MQTTLive one would have to connect the "Default" output to AQ on the sensor, right? Wouldn't that result in a Jitter in the resulting data set?

Problem 1 could be fixed by either hinting to the right Attribute in the MQTTLive-Config-GUI or by adapting the topic naming pattern (e.g. to s4l/mqttlive/1/Intelligente_Raumregelung_Badezimmer/HC/Default).

I don't really have a good suggestion for problem 2 (if it really is one) besides removing "Default" attributes from MQTTLive or prompting an information to the user about this caveat.

Thank you for your great work on this plugin!!!

christianTF commented 3 years ago

Hi Jakob,

to explain the "Default" output:

The time-based fetcher from S4L uses the Loxone HTTP REST interface. The Miniserver's http response contains an unlabled value and may contain several labeled output values. In S4L, we call the unlabled value the Default value.

There is no clear definition if or what labled output is represented by the unlabled value. This is hardcoded from Loxone, and to find out, would us to test every block type and do a mapping somewhere. Additionally, the Loxone Config UI may show different labels as the HTTP REST interface returns.

So, for the normal interval-based fetch, it is up to the user to choose the output he likes to collect. Therefore we show the values of all outputs in the plugin, and a smart user should be able to find out the matching outputs in Loxone Config.

For MQTT Live we use the same output labels as for the interval-based data fetch to have a consistent labeling.

It comes to another level of complexity if Loxone Statistics come into play, but that is another story ;-)

christianTF commented 2 years ago

Closed because of inactivity