FHEM [gelöst] Adapter Readings direkt beschreiben

LausiD

@LHBL2003
Update Adapter 1.4.2 von github und sollte gehen

LHBL2003

Hi,

schon mal Danke.

aber ich glaube da passt etwas nicht oder?

Bildschirmfoto 2020-03-15 um 00.28.55.png

Hatte vorher die Stabile Version 1.3.0 aber auch die 1.4.1 funktioniert ohne Probleme.
Das Problem besteht also in der neuen 1.4.2.

Gruß Denis

LausiD

@LHBL2003
Jo hängt mit der Änderung zusammen.
Sind states ohne Wert dabei?
Mach noch eine Änderung

LHBL2003

@LausiD

Ich sehe gerade das er Einträge erzeugt hat.
Leider ist die Version 1.4.2 nicht mehr online, kann also nicht prüfen ob sich etwas bessert wenn ich noch eine Änderung mache.

Bildschirmfoto 2020-03-15 um 00.42.03.png

Aber ja von der Schnittstelle kommen auch Objekte ohne Werte.
Bildschirmfoto 2020-03-15 um 00.47.13.png

LausiD

@LHBL2003
Kannst nochmal mit 1.4.2 von github testen
Bei Objekten ohne Wert wird jetzt "no value" übertragen

LHBL2003

1.4.2 steht scheinbar nicht zur Verfügung

Bildschirmfoto 2020-03-15 um 09.12.36.png

Gruß Denis

LausiD

@LHBL2003
Die Version 1.4.2 ist nur unter github verfügbar.
Nur in dieser Version kann ich kurzfristig Änderungen durchführen.
Bei mir werden bei Adapterstart jetzt alle Objekte an FHEM übertragen.
Ist der Wert "leer" wird in FHEM "no value" gesetzt.
Also den Adapter nochmal von github aktualisieren und testen...

LHBL2003

Nein ist leider noch nicht besser:

Man kann auch aktuell aus dem log nicht erkennen um welche Variable es sich handelt.
Nachfolgend das Log und Screens der Wolf.0 Variablen:

Bildschirmfoto 2020-03-15 um 10.55.05.png

Gruß Denis

LausiD

@LHBL2003
Ok ein "leerer" Wert ist nicht schuld.
Bitte nochmal Update von github.
Unter Step 6 werden jetzt alle ausgewählten Objekte als Warnmeldung angezeigt.

Alternativ:
Test mit Einschränken unter allowedIOBin zB wolf.0.bm3

Gruß
LausiD

LHBL2003

Also bei wolf.0.bm3 kommt der Fehler auch.

Ich habe also mal den ersten leeren von wolf.0.bm3 genommen, da dieser ein Umlaut im Namen hat. Dort hatte ich dann den Fehler wieder. Aber wolf.0.bm3.82 hat keine Umlaute, ist aber auch leer. Dort bekomme ich den Fehler auch.
wolf.0.bm3.81 besitz einen Wert. Dort bekomme ich keinen Fehler.

{
 "common": {
   "name": "Warmwassersolltemperatur",
   "role": "Value_Temp",
   "type": "boolean",
   "unit": "°C",
   "enabled": false
 },
 "native": {
   "rw": "rw"
 },
 "acl": {
   "object": 1638,
   "owner": "system.user.admin",
   "ownerGroup": "system.group.administrator",
   "state": 1638
 },
 "_id": "wolf.0.bm3.82",
 "type": "state"
}

{
 "type": "state",
 "common": {
   "name": "Raumtemperatur",
   "role": "Value_Temp",
   "type": "state",
   "unit": "°C",
   "enabled": false
 },
 "native": {
   "rw": "r"
 },
 "_id": "wolf.0.bm3.81",
 "acl": {
   "object": 1638,
   "state": 1638
 }
}

Gruß Denis

LHBL2003

Ich habe mal den Adapter und alle Variablen abgelöscht.
Interessanterweise kommt der Fehler dennoch beim start.

Bildschirmfoto 2020-03-15 um 23.06.59.png

Dabei ist check fhem.0.info.Configurations.allowedIOBin aktuell nicht gesetzt.

evtl. Schlummert irgendwo einen tiefergründigeres Problem.

LausiD

Danke für die Infos.
Gleiches Problem aber an anderer Stelle.
Schau ich mir die Tage nochmal in Ruhe an..
Gruß
LausiD

LausiD

@LHBL2003
Update über github und neuer Versuch
States ohne value werden jetzt ignoriert

LHBL2003

@LausiD

Also der FHEM Adapter bleibt am laufen.
Allerdings werden die Propertys mit den NULLs nicht in FHEM als dummys angelegt.
Für ein Error ist es etwas hart. Ich würde es maximal als Warnung einstufen.

Denn es wird sicherlich immer mal Propertys geben die nicht initialisiert sind.
Schön wäre es wenn diese dann in FHEM einfach mit einem Empty angelegt werden.
Denn für den leihen sieht er ja im ioBroker auch nur ein leeren Wert fürs Property.

Bildschirmfoto 2020-03-16 um 21.32.48.png

Oder wie siehts du das?

Gruß Denis

LausiD

@LHBL2003
Ok, gebe dir Recht......Warnung reicht vollkommen:-)
Ein Übertrag in FHEM macht für mich keinen Sinn. Sollte sich irgendwann an den States mal was ändern erfolgt ja ein Übertrag.
Ok so?

Gruß
LausiD

LHBL2003

@LausiD
Ich glaube das sollte ok sein (mit der Warnung ohne den leeren Import). Wenn da nichts drinn steht, dann werden die von der Heizung scheinbar nicht gemeldet und die Einstellbaren Parameter der Heizung sollten von Haus aus einen Wert besitzen.

So nun sollte sich bei mir noch der gedankliche keis schließen.
Gehen wir mal davon aus, dass einer dieser Propertys gelesen und geschrieben werden kann. Wie z.B. eine Sollwertkorrektur oder ein Betriebsmodus.

Dann kann ich mit den dummys die Werte ja nur lesen richtig?
Wie hast du dir das schreiben aus FHEM auf den selben Paramet gedacht.

Mir würde jetzt nur einfallen, dass ich in FHEM im Dummy oder co. ein UserReading erzeuge den ich dann im ioBroker auslese und mit node Red in die eigentliche Variable der Heizung bei Änderung umschifte.

Gruß Denis

LausiD

@LHBL2003
Richtig, dummys im Raum ioB_IN sind nur lesbar.
FHEM Raum ioB_System gibt es ein dummy fhem.0.send2ioB.
Hier gibst du Objektname und den wert ein zB "wolf.0.bm.82 off"

LHBL2003

@LausiD

Also ich wollte gerade mal den rückkanal ausprobieren.

Bildschirmfoto 2020-03-17 um 18.50.13.png

Leider erhalte ich dieses Warnung:

fhem.0 2020-03-17 18:50:06.107 warn (1307) unhandled event FHEM: ---- | dummy fhem.0.send2ioB wolf.0.bm1.65 1 > no sync - object "wolf.0.bm1.65" common.write not true

Bildschirmfoto 2020-03-17 um 18.51.03.png

Hast du eine Idee was ich falsch mache?

Gruß Denis

LausiD

@LHBL2003
Sagt die Meldung schon aus:
Dein verwendetes Objekt hat keine Berechtigung zum Schreiben.
common.write = true wird überprüft.
Bsp:

{
  "from": "system.adapter.admin.0",
  "user": "system.user.admin",
  "ts": 1575997759830,
  "common": {
    "name": "test:test",
    "role": "",
    "type": "string",
    "desc": "Manuell erzeugt",
    "def": "",
    "read": true,
    "write": true
  },
  "native": {},
  "acl": {
    "object": 1636,
    "owner": "system.user.admin",
    "ownerGroup": "system.group.administrator",
    "state": 1636
  },
  "_id": "0_userdata.0.test:test",
  "type": "state"
}

Gruß
LausiD

Mod-Edit: Code/Log in Code Tags gepackt. Bitte benutzt die Code Tags Funktion -> </>
Hier gehts zur Hilfe.

LHBL2003

@LausiD

Habe "write": true in der RAW Konfiguration für Common hinzugefügt, damit ich die beschreibbaren Variablen des ioBroker Wolf Adapters von FHEM aus beschreiben kann.
Ich dachte immer das "rw": "rw" dies schon aussagt.
Aber in diesen Fall sollte ich sicherlich mal den Entwikler @smiling_Jack vom ioBroker.Wolf Adapter darum bitten dies in die default Einstellungen zu übernehmen.
Vielleicht liest er diesen Eintrag und die zwei Einträge zuvor ja

Gruß Denis

NEWS

FHEM [gelöst] Adapter Readings direkt beschreiben

Support us

774
Online

32.0k
Users

80.5k
Topics

1.3m
Posts

NEWS

FHEM [gelöst] Adapter Readings direkt beschreiben

Support us

774Online

32.0kUsers

80.5kTopics

1.3mPosts

774
Online

32.0k
Users

80.5k
Topics

1.3m
Posts