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

[aski71]

@aski71:

1. 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.

2. 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?

3. 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?

3. 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.