[jetzt aber gelöst] Nochmal: Fehler in Skripten seit Update 2.1.2

aski71

~~@aski71:~~

Beides ist vom Typ boolean. Sollte es vielleicht sein - ist es aber nicht, denn an "hm-rega.0.12389" wird ein Wert vom Typ "string" übergeben (der Wert kann z.B "true" sein).

Wenn ich unter Objekte->hm-rega.0.12389->raw nachsehe, finde ich:

    "type": "boolean",

Wenn ich unter Objekte-> geofency.0.Alex.Home.entry-> raw nachsehe, finde ich:

    "type": "boolean",

Warum wird dann an hm-rega.0.12389 ein Wert vom Typ "string" übergeben?

Ist das nicht irgendwie unlogisch?

Und führt das nicht die wunderbar einfache

on('geofency.0.Alex.Home.entry', 'hm-rega.0.12389');

Logik ad absurdum?

paul53

Wenn im Datenpunkt-Attribut common.type: "boolean" steht, bedeutet es, dass der Typ "boolean" sein sollte. In state.val kann aber ein anderer Typ enthalten sein, was bisher ohne die Typprüfung nicht auffiel. Es kann auch ein String "true" oder "false" enthalten sein, was im Reiter "Objekte" oder im Reiter "Zustände" vom echten false oder true nicht unterschieden werden kann. Allerdings funktioniert if(dp.state.val) mit Strings nicht.

aski71

~~@paul53:~~

Wenn im Datenpunkt-Attribut common.type: "boolean" steht, bedeutet es, dass der Typ "boolean" sein sollte. In state.val kann aber ein anderer Typ enthalten sein, was bisher ohne die Typprüfung nicht auffiel. Es kann auch ein String "true" oder "false" enthalten sein, was im Reiter "Objekte" oder im Reiter "Zustände" vom echten false oder true nicht unterschieden werden kann. Allerdings funktioniert if(dp.state.val) mit Strings nicht. `

Hm. Verstanden.

Ich habe nun mal folgende Variablen per log ausgeben lassen:

       log("geofency.0.atHomeCount = " + getState("geofency.0.atHomeCount").val);
       log('rega12391 ist vom Typ: ' + typeof getState("hm-rega.0.12391").val);
       log('geofency.0.atHomeCount ist vom Typ: ' + typeof getState("geofency.0.atHomeCount").val);
       log('geofency.0.Alex.Home.entry ist vom Typ: ' + typeof getState("geofency.0.Alex.Home.entry").val);
       log('geofency.0.Elke.Home.entry ist vom Typ: ' + typeof getState("geofency.0.Elke.Home.entry").val);
       log('hm-rega.0.12389 ist vom Typ: ' + typeof getState("hm-rega.0.12389").val);
       log('hm-rega.0.12390 ist vom Typ: ' + typeof getState("hm-rega.0.12390").val);

Ergebnis im Log ist:

javascript-0	25 16:59:47.668	info	script.js.Geofency_Presence.Presence: hm-rega.0.12390 ist vom Typ: boolean
javascript-0	25 16:59:47.665	info	script.js.Geofency_Presence.Presence: hm-rega.0.12389 ist vom Typ: string
javascript-0	25 16:59:47.664	info	script.js.Geofency_Presence.Presence: geofency.0.Elke.Home.entry ist vom Typ: string
javascript-0	25 16:59:47.663	info	script.js.Geofency_Presence.Presence: geofency.0.Alex.Home.entry ist vom Typ: string
javascript-0	25 16:59:47.662	info	script.js.Geofency_Presence.Presence: geofency.0.atHomeCount ist vom Typ: number
javascript-0	25 16:59:47.657	info	script.js.Geofency_Presence.Presence: rega12391 ist vom Typ: number
javascript-0	25 16:59:47.655	info	script.js.Geofency_Presence.Presence: geofency.0.atHomeCount = 1

Was hier schon auffällig ist:

geofency.0.Alex.Home.entry wird mit obiger kurzer on-Methode auf rega.0.12389 gemappt.

Beide werden hier als string ausgegeben, obwohl in der CCU2 sowohl rega.0.12389, als auch hm-rega.0.12390 als typ boolean angelegt sind.

Im Logging wird "Wrong type of hm-rega.0.12389: "string". Please fix, while deprecated and will not work in next versions." angemeckert.

Eigentlich richtig angemeckert, aber der typeof()-Call liefert für 12389 den falschen Wert. Nämlich string.

geofency.0.Elke.Home.entry wird mit der kurzen on-Methode auf hm-rega.0.12390 gemappt. Das klappt nun also der Typ-Prüfung wegen nicht und wird dann zurecht als deprecated angemeckert. Lösung wäre wohl dann, einen setState('hm-rega.0.12390', <true|false>); zu machen, richtig?
geofency.0.atHomeCount ist number. rega12391 ist auch number.

setState("hm-rega.0.12391", parseInt(getState("geofency.0.atHomeCount").val, 10)); führt auch nicht dazu, dass der richtige Wert nach rega12391 geschrieben wird. Der Wert in der CCU2-Variablen ist und bleibt 65000.00.

Und nu? :o</true|false>

aski71

~~@aski71:~~

geofency.0.Alex.Home.entry wird mit obiger kurzer on-Methode auf rega.0.12389 gemappt.

Beide werden hier als string ausgegeben, obwohl in der CCU2 sowohl rega.0.12389, als auch hm-rega.0.12390 als typ boolean angelegt sind.

Im Logging wird "Wrong type of hm-rega.0.12389: "string". Please fix, while deprecated and will not work in next versions." angemeckert.

Eigentlich richtig angemeckert, aber der typeof()-Call liefert für 12389 den falschen Wert. Nämlich string.

geofency.0.Elke.Home.entry wird mit der kurzen on-Methode auf hm-rega.0.12390 gemappt. Das klappt nun also der Typ-Prüfung wegen nicht und wird dann zurecht als deprecated angemeckert. Lösung wäre wohl dann, einen setState('hm-rega.0.12390', <true|false>); zu machen, richtig?

geofency.0.atHomeCount ist number. rega12391 ist auch number.

setState("hm-rega.0.12391", parseInt(getState("geofency.0.atHomeCount").val, 10)); führt auch nicht dazu, dass der richtige Wert nach rega12391 geschrieben wird. Der Wert in der CCU2-Variablen ist und bleibt 65000.00.

Und nu? :o</true|false> `

Nachtrag: Nachdem ich 1) und 2) auf die Langform des on() mit einem if-then-else und setState(…, <true|false>) umgeschrieben habe, ist 1) und 2) gelöst. Bei 1) liefert das logging jetzt auch den richtigen typeof()-Wert. Sollte es aber eigentlich immer machen, oder?

ist mir nach wie vor schleierhaft.</true|false>

paul53

Zu 1) und 2) Probier mal

on('geofency.0.Alex.Home.entry', function(dp) {
setState('hm-rega.0.12389', toBoolean(dp.state.val));
});

aski71

~~@paul53:~~

Zu 1) und 2) Probier mal

on('geofency.0.Alex.Home.entry', function(dp) {
setState('hm-rega.0.12389', toBoolean(dp.state.val));
});
```` `

Das klappt. Danke.

… jetzt nur noch 3) auf die Schliche kommen.

aski71

Zu 3)

Es wird ja immer 65000 in die Variable geschrieben.

Ich habe mir jetzt nochmal den Raw-Modus von hm-rega.0.12391 angesehen.

Dort gibt es einen "min": 65000

Ist das eine Spur? Zumal min und max eigentlich 0 und 65000 sind.

Wo kommt dieses min 65000 her?

{
  "common": {
    "name": "Anwesenheit.Nutzer",
    "type": "number",
    "role": "state",
    "desc": "# user @ home",
    "min": 65000,
    "read": true,
    "write": true
  },
  "native": {
    "Name": "Anwesenheit.Nutzer",
    "TypeName": "VARDP",
    "DPInfo": "# user @ home",
    "ValueUnit": "",
    "ValueList": "",
    "ValueMin": 0,
    "ValueMax": 65000,
    "ValueType": 4,
    "ValueSubType": 0
  },
  "acl": {
    "object": 1638,
    "owner": "system.user.admin",
    "ownerGroup": "system.group.administrator",
    "state": 1638
  },
  "_id": "hm-rega.0.12391",
  "type": "state"
}

paul53

~~@aski71:~~

Dort gibt es einen "min": 65000

Ist das eine Spur? `
Ja, der JS-Adapter wurde nicht nur um die Typprüfung, sondern auch um die Prüfung common.min <= state <= common.max erweitert (falls vorhanden). Korrigiere den Wert von common.min und es wird wieder funktionieren.

aski71

~~@paul53:~~

~~@aski71:~~

Dort gibt es einen "min": 65000

Ist das eine Spur? Ja, der JS-Adapter wurde nicht nur um die Typprüfung, sondern auch um die Prüfung ****common.min <= state <= common.max**** erweitert (falls vorhanden). Korrigiere den Wert von common.min und es wird wieder funktionieren.

Genau das war's! Weiß der Henker, wo dieses common.min herkam.

Danke allen für die Mithilfe.

aski71

~~@aski71:~~

~~@paul53:~~

~~@aski71:~~

Dort gibt es einen "min": 65000

Ist das eine Spur? Ja, der JS-Adapter wurde nicht nur um die Typprüfung, sondern auch um die Prüfung ****common.min <= state <= common.max**** erweitert (falls vorhanden). Korrigiere den Wert von common.min und es wird wieder funktionieren.

Genau das war's! Weiß der Henker, wo dieses common.min herkam.

Danke allen für die Mithilfe. `

Kaum einen Tag später: Das gelöschte common.min ist wieder da und steht auf 65000. :oops:

Hat wer eine Idee, wer oder was dieses common.min automatisch setzen könnte?

aski71

~~@aski71:~~

~~@paul53:~~

~~@aski71:~~

Dort gibt es einen "min": 65000

Ist das eine Spur? Ja, der JS-Adapter wurde nicht nur um die Typprüfung, sondern auch um die Prüfung ****common.min <= state <= common.max**** erweitert (falls vorhanden). Korrigiere den Wert von common.min und es wird wieder funktionieren.

Genau das war's! Weiß der Henker, wo dieses common.min herkam.

Danke allen für die Mithilfe. `

… kaum ein Tag später: Das common.min von 65000 ist wieder da. Obwohl ich es gestern raus gelöscht hatte. :shock:

Hat jemand eine Erklärung dafür?

paul53

~~@aski71:~~

Das common.min von 65000 ist wieder da. Obwohl ich es gestern raus gelöscht hatte. :shock:

Hat jemand eine Erklärung dafür? `
In der Datei "ioBroker.hm-rega/hm-rega.js" enthalten die Zeilen 1060 und 1061 einen Fehler:

// Zeile 1059 ff.
                if (data[id].ValueMin)  obj.common.min = data[id].ValueMin;
                if (data[id].ValueMax)  obj.common.min = data[id].ValueMax;
                if (data[id].ValueUnit) obj.common.min = data[id].ValueUnit;

Richtig:

                if (typeof data[id].ValueMin === 'number')  obj.common.min = data[id].ValueMin;
                if (typeof data[id].ValueMax === 'number')  obj.common.max = data[id].ValueMax;
                if (data[id].ValueUnit)                     obj.common.unit = data[id].ValueUnit;

aski71

Das erklärt einiges. Danke.

paul53

Bluefox hat es in Version 1.1.1 von iobroker.hm-rega korrigiert.

Bluefox

~~@paul53:~~

Bluefox hat es in Version 1.1.1 von iobroker.hm-rega korrigiert. `
Du musst langsam lernen wie man mit github arbeitet.

Es ist sehr mühsam die Änderungen aus JIRA einzupflegen. Aber die will ich auch auf keinen Fall liegen lassen.

paul53

~~@Bluefox:~~

Du musst langsam lernen wie man mit github arbeitet. `
Ja, solche "Kleinigkeiten" könnte ich auch selbst einpflegen. Es gibt aber 3 Argumente dagegen:

1. Bei der Gelegenheit hast Du noch mal über das Programm geschaut und weitere kleine Änderungen vorgenommen, die bei mir unter den Tisch gefallen wären.

2. Deine Lösung, auch den gültigen Wert 0 zu übertragen, sieht anders aus als meine. Dafür gibt es sicherlich einen Grund ?

3. Den hm-rega-Adapter verwende ich nicht. Bevor ich etwas veröffentliche, möchte ich es aber testen.

Homoran

Hallo Paul,

stell dein Licht mal nicht so unter den Scheffel!

Alle deine Hinweise in allen Ehren, aber Bluefox kann bei einem Pull-request das auch alles berücksichtigen.

Und außerdem ich sehe einen Pull-Request auch eher als Diskussionsgrundlage und nicht als Veröffentlichung.

Gruß

Rainer

paul53

~~@Homoran:~~

Bluefox kann bei einem Pull-request das auch alles berücksichtigen. `
Ein Pull-Request ist kein Problem (habe ich schon ein paar Mal genutzt). Wenn es damit für Bluefox einfacher wird, lasse ich künftig JIRA außen vor.

NEWS

[jetzt aber gelöst] Nochmal: Fehler in Skripten seit Update 2.1.2

Support us

872
Online

31.5k
Users

79.2k
Topics

1.3m
Posts

NEWS

[jetzt aber gelöst] Nochmal: Fehler in Skripten seit Update 2.1.2

Support us

872Online

31.5kUsers

79.2kTopics

1.3mPosts

872
Online

31.5k
Users

79.2k
Topics

1.3m
Posts