NEWS
Test Adapter FHEM v1.6.x
-
@LausiD
Und bitte bei Github immer das folgende im Hinterkopf abenhttp://www.iobroker.net/docu/?page_id=8511&lang=de#DieInstallation_von_Github_nur_fuer_Experten
-
@Homoran
Danke für den Hinweis1.2.1 von github ist "nur" fix von 1.2.0
Die gemeldeten Fehler/Probleme sollten behoben sein.- fhem.x.alive im Raum ioB_Sytem wird auch ohne fhem.x.info.Configurations.autoConfigFHEM=true gesetzt.
- fhem.x.alive wird nicht mehr alle 60 sec getriggert, sondern alle 300 sec = 5 Minuten. Das reicht, oder?
- Korrektur Text warn "....set manually in FHEM or automatically "fhem.0.info.Configurations.autoConfigFhem" = true | more info README.md"
- fix PossibleSets zB on-for-timer für node-red
Ziel ist es 1.2.1 in stable zu bringen.....
-
Neu in der Version 1.2.1 (19.04.19) von github
- fhem.x.info.Configurations.onlySyncTYPE
Es werden nur Module mit diesem TYPE synchronisiert.
zB HUEDevice,SONOSPLAYER erzeugt nur noch diese Objekte im ioBroker (Alternative für die Verwendung von room ioBroker) - Bei dummy Modulen mit Attribut readingList werden die vorhanden Readings im ioBroker mit Schreib Rechten angelegt.
Somit können diese Readings beidseitig geändert werden. - fhem.x.info.Commands.createSwitch
Durch Eingabe von "NAME room" wird in FHEM ein dummy als Schalter angelegt.
Der Andrang zum Testen hält sich ja leider in Grenzen
Auf gehtsGruß
LausiD - fhem.x.info.Configurations.onlySyncTYPE
-
bislang keine Probleme mit der Version.
Auch der createSwitch funzt . -
Ich nutze den FHEM Adapter zwar, aber nur für Devices die in FHEM besser integriert sind als in ioBroker (und wo ich diese bessere Integration benötige, aktuell jedoch nur noch für meine Lametric). Daher kann ich leider nicht viel testen, finde aber gut, dass die Entwicklung voran geht. Weiter so.
-
@siggi85
Danke für die Rückmeldung
Denke die meisten nutzen den Adapter wie du nur zum Übertrag einzelner Devices übrr den Raum ioBroker.
Vielleicht wäre es sinnvoll über eine Auswahl die restlichen Funktionen zu deaktivieren. Besteht Intetesse?
Ziel von mir war FHEM komplett aus ioBroker bedienen zu können und die eigentlichen Steuerungen können weiterhin auf FHEM laufen. Oder aber auch gemischter Betrieb ist möglich. Der Übertrag funktioniert in beide Richtungen@kmxak
Ebenfalls vielen Danke für die RückmeldungViel Spaß mit ioBroker und FHEM
LausiD -
@LausiD sagte in [Aufruf] FHEM Adapter 1.2.1 (19.04.19) von github:
@siggi85
Danke für die Rückmeldung
Denke die meisten nutzen den Adapter wie du nur zum Übertrag einzelner Devices übrr den Raum ioBroker.
Vielleicht wäre es sinnvoll über eine Auswahl die restlichen Funktionen zu deaktivieren. Besteht Intetesse?Genau so nutze ich den Adapter!
Da diese Funktionen nicht stören, benötige ich nicht zwingend ein Deaktivieren dieser Funktionen. Bin einfach begeistert wie performant und stabil dieser Adapter läuft. -
Geändert wurden:
-
Verarbeitung State change von ioB optimiert
-
fhem.x.info.Commands
sendFHEM und createSwitch werden bei Erfolg mit "done" quittiert.
Unter lastCommand wird jeweils der letzte Befehle an FHEM geschrieben.
resultFHEM enthält Antwort auf Befehl
Hier im Beispiel mit "update check"
-
fhem.0.info.Debug
Unter fhem.x.info.Debug.activate ein oder mehere Device Namen durch Komma getrennt eingeben und im admin-Log erscheinen für zB switch00 folgende Einträge
Gruß
LausiD -
-
Geändert wurde unter fhem.1.info.Configurations:
Jeweils bei Wert false können die angelegten state-Objekte nicht durch den Adapter verändert werden.
Bei true werden die Objekte je nach FHEM Adapter Version automatisch angepasst. -
Noch eine Änderung:
Für den Name Objekt state wird jetzt wie beim Objekt channel wenn vorhanden das Attribut alias verwendet. Kein alias vorhanden ist der Name des Objekts = Name Device in FHEM.
Zusätzlich wird beim Name für ein Objekt state noch das Attribut/Reading angehängt.
Ist fhem.x.info.Configurations.autoName=true werden im laufenden Betrieb durch Änderung alias alle Namen der Objekte geändert.@ok1
Kannst du das nochmal testen? DankeGruß LausiD
-
smartType SWITCH,LIGHT,THERMOSTAT werden automatisch gesetzt.
Mit fhem.0.info.Configurations.autoSmartName=false wird smartName und smartType für Alexa (iot und cloud Adapter) nur beim 1.Sync angelegt und danach nicht mehr durch den Adapter verändert.
Nur für Instanz fhem.0Gruß
LausiD -
Bei Verwendung von send2ioB aus FHEM sollte jetzt auch true/ false möglich sein.
Wer möchte Testen und Rückmeldung geben?
Danke und Gruß
LausiD -
Für ein state aus FHEM mit dem Wert "nomotion" oder "noMotion" wird bei Synchro zusätzlich ein Objekt state_boolean mit Wert "false" angelegt.
Für ein state aus FHEM mit dem Wert "motion" oder "Motion" wird zusätzlich bei Synchro ein Objekt state_boolean mit Wert "true" angelegt.
Ändert sich der Wert von state wird auch state_Boolean geändert.Gruß
LausiD -
Bei Verwendung von send2ioB aus FHEM werden auch Objekte mit type=Nummer geschrieben.
Gruß
LausiD -
Folgende Änderung für Bewegungsmelder:
Zusätzlich zum state wird noch subType=motionDetector geprüft. Wenn vorhanden wird immer ein state_boolean angelegt und auch nicht mehr gelöscht. -
Kompaktmodus wurde von Bluefox hinzugefügt
1.3.0 (2019-07-14)
(bluefox) Compact mode was added@Bluefox
thx
1.3.0 is ready for stable now -
@LausiD ок. Aber kannst du repo patchen bitte?
-
Bei Verwendung von allowedIOBin werden im Namen ioBroker '#' durch '_' ersetzt.
Gruß
LausiD -
- Änderungen in FHEM werden während Synchro gespeichert und erst am Ende Synchro verarbeitet.
- Es gibt im Raum ioB_System einen dummy fhem.0.alive. Der Adapter schickt alle 5 Min "set fhem.0.alive on-for-timmer 360". Bleibt der Befehl aus wechselt der dummy auf state off.
Neu:
Jede Aktualisierung state von fhem.0.alive wird vom Adapter ausgewertet.
Wurde das state 6 Min nicht aktualisiert wechselt fhem.0.info.Info.alive von true auf false.
Gruß
LausiD -
- Änderung bei error jsonlist2 während Synchro.