Navigation

    Logo
    • Register
    • Login
    • Search
    • Recent
    • Tags
    • Unread
    • Categories
    • Unreplied
    • Popular
    • GitHub
    • Docu
    • Hilfe
    1. Home
    2. esche

    NEWS

    • Neuer Blog: Fotos und Eindrücke aus Solingen

    • ioBroker@Smart Living Forum Solingen, 14.06. - Agenda added

    • ioBroker goes Matter ... Matter Adapter in Stable

    E
    • Profile
    • Following 0
    • Followers 0
    • Topics 2
    • Posts 27
    • Best 1
    • Groups 1

    esche

    @esche

    1
    Reputation
    26
    Profile views
    27
    Posts
    0
    Followers
    0
    Following
    Joined Last Online

    esche Follow
    Starter

    Best posts made by esche

    • RE: [Aufruf] Nina Gefahrenmeldung Adapter

      Hallo zusammen

      ich finde die Idee mit dem Adapter sehr gut. Daher habe ich mir diesen in den letzten Tagen etwas genauer angeschaut.
      Ich habe für mich ein kleines Script gebaut, welches die alle paar Minuten prüft, ob es neue Nachrichten vom Adapter gibt. Wenn ja, können diese an die gewünschten Systeme (bei mir bisher Pushover / Telegram) versendet werden.

      Vielleicht nützt es den einen anderen anderen hier etwas, daher habe ich diesen mal auf einem Git Repo hochgeladen.

      https://github.com/mesche/iobroker-scripts/tree/master/nina_messages_eventhandler

      Gerne freue ich mich auch über Feedback oder weitere Ideen für de Umsetzung.
      Bitte zerlegt den Adapter nicht sofort, dies ist bisher nur eine erste Version.

      Gruß
      Esche

      posted in Tester
      E
      esche

    Latest posts made by esche

    • RE: HM-RPC - Werte via Scripte ohne Konflikte setzen/steuern

      Hallo zusammen,

      nachdem ich bei dem Problem keine wirkliche Lösung finde, habe ich mir als Workaround ein Script gebaut, welches eine synchrone Verarbeitung der Befehle durchführt.
      Es lief bei mir in den letzten Tagen ohne Probleme bei der Kommunikation mit der CCU.

      Vielleicht ist es ja für jemanden auch interessant. Weitere Infos dazu gibts hier.

      Blog: setState: Synchrone Verarbeitung der ioBroker Homematic RPC Adapter Befehle via BIN-RPC/XML-RPC um Probleme bei der Kommunikation zu vermeiden

      Gerne auch Feedback ob es bei euch auch funktioniert.

      Gruß
      Esche

      posted in Skripten / Logik
      E
      esche
    • RE: HM-RPC - Werte via Scripte ohne Konflikte setzen/steuern

      @zahnheinrich said in HM-RPC - Werte via Scripte ohne Konflikte setzen/steuern:

      @esche sagte in HM-RPC - Werte via Scripte ohne Konflikte setzen/steuern:

      hm-rpc.0 (26742) xmlrpc -> setValue ["MEQXXXXXXXX:1","LEVEL",1] FLOAT error: hm-rpc.0 (26742) Cannot call setValue: XML-RPC fault: Failure

      Selbige Fehlermeldung erhalte ich auch zeitweise vom HM-IP Adapter.
      Ich betreibe nach jahrelangen Erfahrungen mit allen HM Systemen seit einigen Wochen ein HM-IP wired System.
      Wenn es läuft, läuft es gut! Stellen sich jedoch obige Fehlermeldungen ein und ich versuch dann z.B. (in der HM GUI) Kommandos zur Rolladen steuerung abzustzen passiert: NICHTS.
      Wiederhole ich selbige Kommandos mehrmals, rebootet die CCU.
      Das Problem der Fehlermeldungen liegt offensichtlich nicht im Bereich des ioBrokers/Adapters, sondern im Bereich der CCU.

      Nach einem CCU reboot ist der Fehler nach kurzer Zeit weiter vorhanden, mir hilft nur ein Werksreset des HM-Wired Interfaces HmIPW-DRAP.

      Also meine Wired-Komponenten laufen bei mir erstaunlicherweise problemlos. Auch ein Reset des DRAPs musste ich noch nie vornehmen. Probleme habe ich wirklich nur, wenn ich die Funk-Komponenten via Schnittstelle steuere. Auch die Steuerung direkt via CCU funktioniert eigentlich ohne Probleme.

      Ich behaupte auch nicht, dass das Grundproblem am IOBroker-Adapter liegt, sondern an der Schnittstelle. Da aber das Verhalten so ist wie es ist, müsste entweder der Adapter selbst mittels Workaround dagegenwirken (was er nicht tut), oder eben via Script etc... und genau diese "Lösung" hoffe ich noch zu finden.

      posted in Skripten / Logik
      E
      esche
    • RE: HM-RPC - Werte via Scripte ohne Konflikte setzen/steuern

      @paul53 Danke für den Vorschlag. Glaube ich verstehe ihn aber noch nicht ganz.
      Du änderst den Wert von "idSoll", dann wird das ON-Event getriggert. Dies führt die Funktion "actor()" aus. diese Funktion setzt den Wert sofort, dann nochmal nach 1 Sek. und nochmal nach 5 Sek.
      Korrekt soweit?

      Hier meine Unklarheiten:

      1. Die beiden Timeout-Functions werden aber immer ausgeführt, egal ob erfolgreich oder nicht (somit hätte man im Erfolgsfall) den Wert mehrfach (unnötig) gesetzt.

      2. Angenommen der Wert für ist und soll ist immer noch unterschiedlich.
        Dann müssten im Konfliktfall 3 Errors im Log auftauchen oder?
        Wie werden dann die Timeouts erneut getriggert?

      Meine Bedenken:

      • Wenn ich das mit 30 Geräten mache, hätte ich ziemlich viele Timer laufen, welche jedes Mal JS-Functions Instanzen erzeugen. Gibt es da bisher keine Probleme mit Leaks im Memory?
      • Was ist wenn du Werte nicht via IOBroker sondern direkt über die CCU änderst? Dann stimmt der Wert von "idSoll" auch nicht mehr mit "idAktor" überein
      posted in Skripten / Logik
      E
      esche
    • RE: HM-RPC - Werte via Scripte ohne Konflikte setzen/steuern

      @homoran Geht leider nicht, da einige Logik dabei ist, die ich nicht via Direktverknüpfung abbilden kann.

      posted in Skripten / Logik
      E
      esche
    • RE: HM-RPC - Werte via Scripte ohne Konflikte setzen/steuern

      @homoran Danke für deine Rückmeldung. Ja, hatte mir überlegt das Ganze auch in einem HM-Forum zu posten. Jedoch weiß ich jetzt schon, dass dort auch kommen wird, dass dies ein IOBroker Problem bzw. des entsprechenden Adapters ist. Fakt ist aber, dass das Problem existent ist und ich denke, weder HM seine API, noch der IOBroker Adapter in seinem Vorgehen in der nächsten Zeit umgeschrieben wird. Somit bleibt eigentlich nur das Handling, bzw. eben die entsprechenden Scripte anzupassen.

      Via virtuellen Taster, ist ja schon mal ein guter Lösungsansatz. Wobei das auch bedeuten würde, dass ich einige Logik via HM-Script implementieren müsste. Bisher hatte ich versucht alles Zentral in IOBroker umzusetzen, da auch noch andere Komponenten z. B. ZigBee bei manchen Aktionen mitgesteuert werden sollen. Mal ganz davon abgesehen, ist HM-Script auch nicht meine bevorzugte Wahl beim Scripten 😉

      posted in Skripten / Logik
      E
      esche
    • HM-RPC - Werte via Scripte ohne Konflikte setzen/steuern

      Hallo zusammen,

      dass es zu Konflikten/Überschneidungen bei der Steuerung von mehreren Homematic(-IP) Komponenten kommen kann und somit die Werte nicht korrekt gesetzt/übertragen werden, sollte ja kein Problem sein, welches nur bei mir vorkommt.

      Bei manchen Konstellationen wurde ich durch einen Fehler im Log darauf aufmerksam.

      hm-rpc.0 (26742) xmlrpc -> setValue ["MEQXXXXXXXX:1","LEVEL",1] FLOAT
      error: hm-rpc.0 (26742) Cannot call setValue: XML-RPC fault: Failure
      

      Jedoch musste ich feststellen, dass dies nicht immer der Fall ist. Manchmal wird einfach der Wert nicht korrekt übertragen und somit führen die Geräte die entsprechende Aktion nicht aus.

      Ich beobachte dieses Problem bei mir schon längere Zeit und habe dies auch noch weiterhin nicht lösen können.
      Auch habe ich mir hier im Forum in der letzten Zeit viele Beiträge dazu angeschaut, aber leider noch keine wirkliche Lösung/Workarounds gefunden, die umfänglich funktioniert. Daher habe ich mich entschlossen jetzt hierzu doch nochmal einen Beitrag zu eröffnen, mit der Hoffnung neuer Erkenntnisse und mögliche Lösungsansätze zu bekommen.

       
      Meine Infrastruktur:

      • RPi 4: piVCCU: 3.63.9.71
      • Adapter: ioBroker.javascript v5.7.0
      • Adapter: hm-rpc.0 v1.15.12 (HM)
      • Adapter: hm-rpc.1 v1.15.121.15.12 (HM-IP)
      • HM/IP Komponenten: HM-LC-Bl1-FM / HM-CC-RT-DN / HMIP-eTRV / M-LC-Dim1T-FM / HM-LC-Sw1-FM

       
       

      Konkretes Beispiel, bei dem das Problem öfters auftaucht.

      • Schließen mehrerer Jalousie-Aktoren (HM-LC-Bl1-FM)
      • Öffnen mehrerer Jalousie-Aktoren (HM-LC-Bl1-FM) und setzen der Temperatur von Heizkörperthermostate (HM-CC-RT-DN / HMIP-eTRV)
      • Ausschalten aller Lichter (HM-LC-Dim1T-FM / HM-LC-Sw1-FM) und setzen der Temperatur von Heizkörperthermostate (HM-CC-RT-DN / HMIP-eTRV)

      Hierzu habe ich auch via JavaScript-Script ein paar Tests gemacht um das Verhalten zu verstehen.
      Überraschend war für mich, dass mehrere Befehle auf das gleiche Gerät teilweise problemlos funktionieren.
      Zusätzlich war interessant, dass teilweise Werte nicht gesetzt werden, dies aber ohne Fehlermeldung im Log.

      setState

      const LICHT1 = 'hm-rpc.0.MEQXXX1.1.LEVEL';
      const LICHT2 = 'hm-rpc.0.MEQXXX2.1.LEVEL';
      const LICHT3 = 'hm-rpc.0.MEQXXX3.1.STATE';
      const HEIZUNG1 = 'hm-rpc.1.000XXXXXXXA4.1.';
      
      // test1
      setState(LICHT1, 30, false);
      setState(LICHT1, 0, false);
      // Ergebnis: Inkonsistenzes Verhalten: Licht1 geht an und wieder aus / Licht1 beleibt an / Licht1 bleibt aus
      
      // test2
      setState(LICHT1, 30, false);
      setState(LICHT2, 30, false);
      setState(LICHT3, true, false);
      // Ergebnis: Licht1 und Licht2 und Licht3 gehen an
      
      //test3
      setState(HEIZUNG1 + 'WINDOW_STATE', 1, false); // 0:Closed  1:Open
      setState(HEIZUNG1 + 'CONTROL_MODE', 1, false); // 0:Auto  1:Manu  2:Party  3:Boost
      setState(HEIZUNG1 + 'SET_POINT_TEMPERATURE', 18, false);
      // Ergebnis: Temperatur wird nicht korrekt gesetzt
      // --> Trotz unzuverlässiger Werte-Setzung keinerlei Fehler im Log
      
      //test4
      setState(HEIZUNG1 + 'CONTROL_MODE', 1, false); // 0:Auto  1:Manu  2:Party  3:Boost
      setState(HEIZUNG1 + 'SET_POINT_TEMPERATURE', 18, false);
      // Ergebnis: Temperatur wird nicht korrekt gesetzt (egal in welcher Reihenfolge)
      // Steht aber einer der 3 Werte bereits auf den zu setzenden Wert, werden somit "alle" korrekt gesetzt
      // --> Trotz unzuverlässiger Werte-Setzung keinerlei Fehler im Log
      
      // test5
      setState(LICHT1, 30, false);
      setState(LICHT2, 30, false);
      setState(LICHT3, true, false);
      setState(HEIZUNG1 + 'SET_POINT_TEMPERATURE', 14, false);
      // Ergebnis: Licht1 und Licht2 und Licht3 gehen an, aber Temperatur wird nicht korrekt gesetzt
      // --> Trotz unzuverlässiger Werte-Setzung keinerlei Fehler im Log
      

      setStateDelayed

      const LICHT1 = 'hm-rpc.0.MEQXXX1.1.LEVEL';
      const LICHT2 = 'hm-rpc.0.MEQXXX2.1.LEVEL';
      const LICHT3 = 'hm-rpc.0.MEQXXX3.1.STATE';
      const HEIZUNG1 = 'hm-rpc.1.000XXXXXXXA4.1.';
      
      // test1
      setStateDelayed(LICHT1, 30, false, 5000);
      setStateDelayed(LICHT1, 0, false, 10000);
      // Ergebnis: Licht1 bleibt aus, da nur letzter Befehl durchgeführt wird
      
      // test1
      setStateDelayed(LICHT1, 30, false, 5000);
      setStateDelayed(LICHT1, 0, false, 10000, false);
      // Ergebnis: Licht1 geht an und wieder aus
      
      
      // test3
      setStateDelayed(LICHT1, 30, false, 5000);
      setStateDelayed(LICHT2, 30, false, 5000);
      setStateDelayed(LICHT3, true, false, 5000);
      // Ergebnis: Licht1 und Licht2 und Licht3 gehen an
      
      // test4
      setStateDelayed(LICHT1, 30, false, 5000);
      setStateDelayed(LICHT2, 30, false, 5000);
      setStateDelayed(LICHT3, true, false, 5000);
      setStateDelayed(LICHT1, 0, false, 10000);
      setStateDelayed(LICHT2, 0, false, 10000);
      setStateDelayed(LICHT3, false, false, 5000);
      // Ergebnis: Licht1 und Licht2 und Licht3 bleiben aus, da nur letzter Befehl je ID durchgeführt wird
      
      // test5
      setStateDelayed(LICHT1, 30, false, 5000);
      setStateDelayed(LICHT2, 30, false, 5000);
      setStateDelayed(LICHT3, true, false, 5000);
      setStateDelayed(LICHT1, 0, 10000, false);
      setStateDelayed(LICHT2, 0, 10000, false);
      setStateDelayed(LICHT3, false, 10000, false);
      // Ergebnis: Licht1 und Licht2 und Licht3 gehen an und wieder aus
      
      // test6
      setStateDelayed(HEIZUNG1 + 'WINDOW_STATE', 0, false, 5000); // 0:Closed  1:Open
      setStateDelayed(HEIZUNG1 + 'CONTROL_MODE', 1, false, 5000); // 0:Auto  1:Manu  2:Party  3:Boost
      setStateDelayed(HEIZUNG1 + 'SET_POINT_TEMPERATURE', 18, false, 5000);
      // Ergebnis: Es werden immer nur 2 Werte zuverlässig/korrekt gesetzt und ein Wert nicht
      // Steht aber einer der 3 Werte bereits auf den zu setzenden Wert, werden somit "alle" korrekt gesetzt
      // --> Trotz unzuverlässiger Werte-Setzung keinerlei Fehler im Log
      
      
      // test7
      setStateDelayed(HEIZUNG1 + 'WINDOW_STATE', 0, false, 5000); // 0:Closed  1:Open
      setStateDelayed(HEIZUNG1 + 'CONTROL_MODE', 1, false, 5000, false); // 0:Auto  1:Manu  2:Party  3:Boost
      setStateDelayed(HEIZUNG1 + 'SET_POINT_TEMPERATURE', 14, false, 5000, false);
      // Ergebnis: Heizung1 Fensterstatus, Temperatur und Modus wird korrekt gesetzt
      
      
      // test8
      setStateDelayed(HEIZUNG1 + 'WINDOW_STATE', 1, false, 5000); // 0:Closed  1:Open
      setStateDelayed(HEIZUNG1 + 'SET_POINT_TEMPERATURE', 14, false, 5000, false);
      setStateDelayed(HEIZUNG1 + 'CONTROL_MODE', 1, false, 5000, false); // 0:Auto  1:Manu  2:Party  3:Boost
      // Ergebnis: Heizung1 Fensterstatus und Modus wird korrekt gesetzt, aber Temperatur wird nicht immer korrekt gesetzt 
      // (teilweise auf ganz anderen Wert)
      // --> Trotz unzuverlässiger Werte-Setzung keinerlei Fehler im Log
      
      
      // test9
      script1: 
      //setStateDelayed(LICHT1, 30, false, 5000);
      //script2: 
      setStateDelayed(LICHT1, 0, false, 10000);
      // Ergebnis: Licht1 bleibt aus, da nur letzter Befehl durchgeführt wird
      
      
      // test10
      //script1: 
      setStateDelayed(LICHT1, 30, false, 5000);
      //script2: 
      setStateDelayed(LICHT1, 0, false, 10000, false);
      // Ergebnis: Licht1 geht an und wieder aus
      
      

       
       

      Mögliche Lösungsansätze (welche ich hier im Forum gefunden habe)

      1. Expliziter JS-Code für Verzögerungen der einzelnen Befehle um X Sekunden
             schedule() 
             setTimeout()
             async function sleep(milliseconds) { return new Promise(resolve => setTimeout(resolve, milliseconds));};
      
      1. Aufsteigende Verzögerung bei Iteration via setStateDelayed()
            for (var i = 0; i < stateIds.length; i++) {
              setStateDelayed(id, true, false, i * 300, false);
            }
      
      1. Befehl wiederholen, wenn der Aktor nach ein paar Sekunden nicht den Sollzustand hat
        https://forum.iobroker.net/topic/53725/gelöst-gelegentlich-fehler-bei-homematic/7?_=1655732666750

      2. Anpassung der HM-Gerät-Einstellungen direkt in der CCU

        • Max. Sendeversuche
        • Statusmeldungen Zufallsanteil
        • Statusmeldungen Mindestverzögerung

       
       

      Alle diese Lösungsansätze, funktionierten bei mir jedoch nicht wirklich zuverlässig und bringen teilweise weitere Nachteile mit sich u. a.

      • Bei Ansatz 1 und 2 ist nicht sichergestellt, dass der Wert übermittel wurde ohne das darauf reagiert werden kann.
      • Bei Ansatz 3 wird ggf. viel Datenverkehr verursacht, was die Situation evtl. noch verschlimmert
      • Bei Ansatz 4 konnte ich keine Verbesserung zu diesem Problem feststellen
      • Bei allen Ansätzen kann der Zeitraum zu klein sein und es weiterhin unkontrolliert zu Problemen kommen.
        Wird der Wert zu groß gewählt, läuft das Script unnötig lange und führ die Befehle (unnötig) verzögert aus.
      • All diese Ansätze verhindern keine Konflikte/Überschneidungen, wenn mehrere Scripte gleichzeitig auf HM-Geräte zugreifen und Werte setzen wollen.
         
         

      Idee für einen möglichen Lösungsansatz
      Script welches eine zentrale Queue und deren Verarbeitung für das Setzen von Werten zur Verfügung stellt. Durch diesen zentralen Punkt wäre neben einem zentralen Fehlerhandlings, eine globale Steuerung über mehrere Scripte möglich, um Konflikte/Überschneidungen zu minimieren/vermeiden.

       
       

      Fragen an euch

      • Gibt es ggf. sowas wie eine zentrale Queue schon und es mir nur noch nicht bekannt?
      • Wie sehen eurer Erfahrungen zu diesem Thema aus?
      • Wie geht ihr mit dem Problem um?
      • Habt ihr Lösungsansätze, welche sich bei euch über einen längeren Zeitraum bewährt haben?
      • Gibt es noch weitere Lösungsansätze, welche ich noch nicht auf dem Schirm habe?

       
       
      Danke und Gruß
      Esche

      posted in Skripten / Logik
      E
      esche
    • RE: Steuerung von HM-Komponenten via XML-API nicht mehr möglich

      @homoran Was stört an dem XXen? Glaubt mir, dass ist der gleiche Aktor... Und es sind ja alle meine Aktoren und nicht nur ein bestimmter

      posted in ioBroker Allgemein
      E
      esche
    • RE: Steuerung von HM-Komponenten via XML-API nicht mehr möglich

      Was mir gerade noch zusätzlich aufgefallen ist, nachdem ich den Adapter auf das Loglevel "debug" gestellt habe.
      Sehe ich jetzt einige "no matching device" Meldungen...

      hm-rpc.0 2021-11-12 17:05:26.697	debug	hm-rpc.0 (15400) xmlrpc <- event: hm-rpc.0.CENTRAL.PONG:pve-iobroker:hm-rpc.0 discarded, no matching device
      ....
      ....
      hm-rpc.0 2021-11-12 17:08:26.695	debug	PING ok
      hm-rpc.0 2021-11-12 17:08:26.694	debug	xmlrpc <- event: hm-rpc.0.CENTRAL.PONG:pve-iobroker:hm-rpc.0 discarded, no matching device
      hm-rpc.0 2021-11-12 17:08:26.694	debug	xmlrpc <- event ["pve-iobroker:hm-rpc.0","CENTRAL","PONG","pve-iobroker:hm-rpc.0"]
      hm-rpc.0 2021-11-12 17:08:26.694	debug	xml multicall <event>: pve-iobroker:hm-rpc.0,CENTRAL,PONG,pve-iobroker:hm-rpc.0
      hm-rpc.0 2021-11-12 17:08:26.687	debug	Send PING...
      hm-rpc.0 2021-11-12 17:08:26.686	debug	[KEEPALIVE] Check if connection is alive
      
      posted in ioBroker Allgemein
      E
      esche
    • RE: Steuerung von HM-Komponenten via XML-API nicht mehr möglich

      @Homoran: Welche Informationen genau würden denn benötigt werden?
      Das JSON des Jalousie-Aktors (HM-LC-Bl1-FM)? Versuche gerne alles zu liefern was benötigt wird

      {
        "type": "state",
        "common": {
          "name": "EG - Jalousie Kanal.LEVEL",
          "def": 0,
          "type": "number",
          "read": true,
          "write": true,
          "min": 0,
          "max": 100,
          "unit": "%",
          "workingID": "WORKING"
        },
        "native": {
          "CONTROL": "BLIND.LEVEL",
          "DEFAULT": 0,
          "FLAGS": 1,
          "ID": "LEVEL",
          "MAX": 1,
          "MIN": 0,
          "OPERATIONS": 7,
          "TAB_ORDER": 0,
          "TYPE": "FLOAT",
          "UNIT": "100%"
        },
        "from": "system.adapter.hm-rega.0",
        "user": "system.user.admin",
        "ts": 1633803681051,
        "_id": "hm-rpc.0.MEQXXXXXX.1.LEVEL",
        "acl": {
          "object": 1636,
          "state": 1636,
          "owner": "system.user.admin",
          "ownerGroup": "system.group.administrator"
        }
      }
      
      posted in ioBroker Allgemein
      E
      esche
    • RE: Steuerung von HM-Komponenten via XML-API nicht mehr möglich

      Ich habe heute wieder genau das gleiche Problem/Verhalten.

      Habe heute ein Update des Betriebssystem gemacht (apt update/upgrade). Vorher habe ich explizit die ioBroker Adapter hm-rpc & hm-rega gestoppt und nach dem Update, bzw. Neustart des Betriebssystems, wieder gestartet (sobald piVCCU3 verfügbar war)

      Die CCU zeigt mir den Status der Komponenten (z. B. Fensterkontakt) korrekt an und die Komponenten lassen sich auch problemlos steuern.
      Über die CCU habe ich mir das Fehlerprotokoll heruntergeladen, aber daraus konnte ich nicht wirklich was ableiten.

      Im ioBroker jedoch stimmt der Status der Datenpunkte nicht und sind auch nicht steuerbar.

      Jemand eine Idee wie ich das Problem lokalisieren/debuggen kann?

      Danke und Gruß
      Esche

      posted in ioBroker Allgemein
      E
      esche
    Community
    Impressum | Datenschutz-Bestimmungen | Nutzungsbedingungen
    The ioBroker Community 2014-2023
    logo