Verständnisfrage ValueUnit bei HmIP-Geräten

[Rosagallica]

Ich bin über eine unverständliche Belegung des ValueUnit-Datenpunkts bei HmIP-Geräten gestolpert.
Die meisten HmIP-Geräte haben diesen entweder garnicht (nix) oder mit Text von Abkürzungen (Hz,°C,...) gefüllt. Soweit im erwarteten Rahmen.
Die TFKs HmIP-SWDO-I, HMIP-SWDO hingegen geben den Wert "" (2 Anführungszeichen) zurück.

Einfach falsch von eq-3 belegt oder hat das einen tieferen Sinn? Gibt's noch mehr Gerätetypen mit dieser "Eigenschaft"?

Wer mal seinen Gerätezoo testen will...

Code: Alles auswählen

string dpIdList = dom.GetObject(ID_DATAPOINTS).EnumUsedNames();
string dpId;
foreach (dpId, dpIdList) {
  object dp = dom.GetObject(ID_DATAPOINTS).Get(dpId);
  if (!(dp.Name().StartsWith("HmIP-RF."))) { continue; }
  var vu = dp.ValueUnit();
  if (vu && (vu.Length()>0)) {
    object ch = dom.GetObject(ID_CHANNELS).Get(dp.Channel());
    object device = dom.GetObject(ID_DEVICES).Get(ch.Device());
    string dpName = dp.Name();
    string dpSuffix = dpName.Substr(dpName.Find(":"));
    WriteLine(">" # vu # "<" # " - " # device.HssType() # dpSuffix # " -> " # device.Name());
  }
}
WriteLine("OK");

Warum ist das mir überhaupt aufgefallen? Nun, ich lasse einige HmIP-Geräte ins CuxD-Logging hineinfließen. Mit dem kleinen Hack klappt dann auch die Namensauflösung der Datenpunkte in den CuxD-Highcharts. Jetzt auch die TFKs berücksichtigt im Logging. Nun fällt in den Highcharts aber dpinfos.cgi auf die Nase beim Generieren der JSON-Antwort für die Charts, wenn dieser Anführungszeichen-Text unmaskiert als JSON-String für den ValueUnit-Wert geschrieben wird.

[Xel66]

Ich bin über eine unverständliche Belegung des ValueUnit-Datenpunkts bei HmIP-Geräten gestolpert.

Was ist daran unverständlich? Wenn Messwerte eine Einheit (Unit) wie °C, Hz, V, W, kWh u.ä. haben, dann ist das erklärlich. Aber warum sollten dimensionslose Status ausgaben (die eben nur WAHR oder FALSCH, true oder false, 0 oder 1 sein können) um eine Einheit erweitert sein. Sie sind eben dimensionslose Status. Und der Inhalt dieser Datenpunkte ist nicht "" sondern (nix, leer). Die Anführungsszeichen dienen nur der Abgrenzung von Inhalten gegen Bezeichnungen und umschließen alle Namen, Adressen, Bezeichnungen usw. Irgendwie muss ja dem Rechner mitgeteilt werden, dass ab jetzt wieder "Programmcode" kommt und der Inhalt der Variablen o.ä. zuende ist. Da sich vergebene Einheiten für Messwerte eher selten ändern, muss man diese auch nicht mitloggen. Es dürfte reichen, die Values zu loggen.

Gruß Xel66

[Rosagallica]

Was ist daran unverständlich? Wenn Messwerte eine Einheit (Unit) wie °C, Hz, V, W, kWh u.ä. haben, dann ist das erklärlich. Aber warum sollten dimensionslose Status ausgaben (die eben nur WAHR oder FALSCH, true oder false, 0 oder 1 sein können) um eine Einheit erweitert sein. Sie sind eben dimensionslose Status. Und der Inhalt dieser Datenpunkte ist nicht "" sondern (nix, leer).

Doch: es gibt <nix,nil,null,nada>, sinnvolle Einheitstexte àla "°C" und eben """" (also Anführungszeichen als Inhalte, nicht als Inhaltsabgrenzer einer Stringkonstante im Sourcecode), was keinen Sinn ergibt in meinen Augen. Ergebnis aus dem Skriptschnipsel:

>°C< - HmIP-eTRV-B1:1.SET_POINT_TEMPERATURE -> Bad.Thermostat.Heizkörper
>""< - HmIP-SWDO-I:1.STATE -> Büro.Fensterkontakt (KEIN ><!)

Die Anführungsszeichen dienen nur der Abgrenzung von Inhalten gegen Bezeichnungen und umschließen alle Namen, Adressen, Bezeichnungen usw. Irgendwie muss ja dem Rechner mitgeteilt werden, dass ab jetzt wieder "Programmcode" kommt und der Inhalt der Variablen o.ä. zuende ist. Da sich vergebene Einheiten für Messwerte eher selten ändern, muss man diese auch nicht mitloggen. Es dürfte reichen, die Values zu loggen.

Ich logge diese Attribute gar nicht, die holt sich der Highcharts-Code automatisch (/www/addons/cuxchart/ajax/dpinfos.cgi). Darum geht's auch nicht.

Falls relevant, die Firmwareverionen sind:
HmIP-SWDO-I 1.16.10
HMIP-SWDO 1.16.8

[alchy]

Das ist ein "Bug" über den du gestolpert bist. Wo den EQ3 eingebaut hat müsste man schauen.
Oder noch besser, melde den Bug an EQ3 dann fixen die den und bis dahin überschreib die Einheit einfach.

PS: ich habe mit einem kurzem Script keine weiteren Bugvorkommen außer bei HmIP-SWDO-I & HmIP-SWDO gefunden.
Ich habe aber bei Weitem nicht alle Geräte.
PSPS: pass mit deinem Script auf

Alchy

[Rosagallica]

Das ist ein "Bug" über den du gestolpert bist. Wo den EQ3 eingebaut hat müsste man schauen.
Oder noch besser, melde den Bug an EQ3 dann fixen die den und bis dahin überschreib die Einheit einfach.

So war auch erstmal mein Plan, die "kaputten" Werte rauskicken, damit die Highcharts weiter funktionieren. Aber schon ein lustiges "Kuriosum" von den Friesen. Müsste ich glatt mal an anderen Stellen in Anwendungen probieren

PSPS: pass mit deinem Script auf

Was meinst Du? Dass ich recht sorglos durch die Daten pflüge ohne große Rücksicht auf Fehlerquellen und Performance, ist mir bei dem runtergeschriebenen PoC schon klar

[Baxxy]

Der Vollständigkeit halber...
Das Lidl-Teil HmIP-SWDM-B2 zeigt die gleiche "Einheit".

Code: Alles auswählen

>""< - HmIP-SWDM-B2:1.STATE -> Fensterkontakt WZ: SWDM-B2 2C5

Grüße
Baxxy

[alchy]

So war auch erstmal mein Plan, die "kaputten" Werte rauskicken, damit die Highcharts weiter funktionieren.

Da die Methode ValueUnit() auch schreibend tätig sein kann und es sich um Strings handelt ist ein löschen mittels .ValueUnit("") zielführend.
Aber das wirst du ja wissen.
Würde mich freuen, wenn du die Meldung zu dem Bug schreiben würdest und die Antwort die du erhältst hier mal postest.
Eigentlich könnte ich den Thread auch mal nach bekannte Bugs verschieben zur Historienbewahrung .

Dass ich recht sorglos durch die Daten pflüge ohne große Rücksicht auf Fehlerquellen und Performance, ist mir bei dem runtergeschriebenen PoC schon klar

dann ist ja alles gut. Ist ja auch kein Beinbruch.

Alchy