Morgen Nacht oder Sonntag kommt die GitHub version auf npm wenn keiner mehr was findet

@xwing Du musst das objekt vehicle_state aber hier ist das falsche Forum um das zu diskutieren

@old_engineer Leg das doch mal als GitHub issue im material Adapter an

@mickym Das Bild sollte nur den Eingang des Flow zeigen, weil nach dem owntracks-node erst wieder ein Json gemacht werden muss. Nur, falls jemand mal was nachbauen will mit Payload encryption. Ohne die ging der Flow, den ich gefunden und angepasst hatte problemlos, nur mit halt zuerst nicht mehr. Aber wie gesagt, alles läuft nun. Gruß, Jürgen

@crunchip Na dann kennste ja das Spiel ;-) PS: hjhjjkdrghp806749ß8uPI/&(

Heute kam Email von dicovergy Hat das Auswirkungen auf den Adapter? API-Änderung: Neue, vereinfachte Notation für RLM-Stromzähler des Fabrikanten EMH. Auch anwendbar für alle anderen RLM-Zähler API-Änderung: RLM-Zähler Sehr geehrte(r) Frau/Herr , Heute möchten wir eine Änderung ankündigen, die sich auf die Notationen auswirkt, mit denen die Messwerte einiger RLM-Stromzähler in unserem System gespeichert sind und wie diese über die API abgerufen werden können. Für alle von dem Fabrikanten EMH hergestellten RLM-Zähler wurden die Felder bisher in OBIS-Notation gespeichert und die Werte auf 1 000 000 Einheiten pro kWh festgelegt. Für alle anderen Zähler verwenden wir im System anstatt OBIS einen menschenlesbaren Namen – energy – und 10 000 000 000 Einheiten pro kWh. Fortan werden allerdings bei allen neu installierten EMH RLM-Zählern keine OBIS-Notationen mehr verwendet, sondern die Daten mit derselben menschenlesbaren Notation – energy – und mit derselben Skalierung wie bei anderen Zählern gespeichert. Zur Veranschaulichung: Nehmen wir zum Beispiel an, es wurden 12 kWh von einem RLM-Zähler des Fabrikanten EMH gemessen. Diese Daten sehen derzeit so aus: Feldname: 1.8.0 Wert: 12 000 000 Nach der Änderung werden die Daten wie folgt aussehen: Feldname: energy (normalisiert auf denselben Namen wie bei allen anderen Zählern) Wert: 120 000 000 000 (normalisiert auf den gleichen Faktor wie bei allen anderen Zählern) Bei Anwendungen, die auf unserer API basieren und Messwerte von EMH RLM-Stromzählern abfragen, müssen diese Felder entsprechend angepasst werden. Obwohl diese Änderung nur die oben erwähnten RLM-Zähler von EMH betrifft, möchten wir auch anderen interessierten Kunden die Möglichkeit bieten, dieses normalisierte Format für alle ihre RLM-Zähler zu übernehmen. Die Änderung könnte zukünftige Entwicklungen und Integrationen auf Kundenseite erleichtern, indem es nicht mehr notwendig wäre, mit zwei Branchencodes zu arbeiten (einem für RLM-Zähler und einem für SLP-Zähler), sondern alle Daten könnten einheitlich abgerufen werden. Dies ist besonders vorteilhaft für Kunden, die mit der API arbeiten und sowohl über SLP- als auch RLM-Zähler verfügen. Wollen Sie diese Änderung für Ihre bereits oder künftig installierten RLM-Zähler übernehmen, können Sie sich gerne an Ihren Ansprechpartner bei Discovergy wenden oder einfach eine E-Mail an unseren Vertrieb (vertrieb@discovergy.com) schicken. Bei Fragen zu den in diesem Artikel beschriebenen Änderungen schicken Sie gerne eine E-Mail an api@discovergy.com. Wir werden uns bemühen, Ihre Frage schnellstmöglich zu beantworten. Herzliche Grüße Ihr Discovergy-Team

@hamburgmeineperle https://forum.iobroker.net/topic/45942/vis-inventwo-v3-x-x?_=1627507256386

Wird an dem Adapter noch gearbeitet? Hätte auch großes Interesse daran! Leider hab ich selbst keine Ahnung wie man so einen Adapter schreibt.

@cino Hm, Du könntest evtl. die Szene über eine (in der App) angelegte Routine aufrufen. Diese Routine kannst Du dann per Adapter auslösen.

cc2538 von Arteck [image: 1626954833268-screenshot-2021-07-22-135326.png]

@sneak-l8 sagte in Test Adapter kecontact v1.1.x GitHub/Latest: Wobei da Keba vorbildlich und flott geantwortet hab auhf meine Nachfrage, wie ich die Boxen auseienderhalten kann. Das ist ja Klasse und lässt hoffen, falls mal irgendtwas größeres sein sollte, das sie sich kümmern :)

@mrbungle64 Sorry für den Fehlalarm, ich habe den Fehler gefunden. Der Button, der den Pop-Up View aufruft, sollte gleichzeitig den Status (connected) für den Staubsauger anzeigen und hat den aber durch meinen Fehler auf "false" gesetzt... Danke für Deine Hilfe!

@jackblackson Ich würde im 1 Beitrag auf die neue Version hinweisen.

Soeben habe ich Version 2.2.3 veröffentlicht. Sie fixt nur ein Problem mit dem Sentry Reporting - ich habe @apollon77's Server etwas stark belastet - sorry! :-) Um genau zu sein war es quasi ein einzelner Adapter User, der mehrere Tausend Meldungen generierte. Falls also jemand von euch auf seinem ioBroker grössere Probleme mit dem Loxone Adapter hat, dann bitte hier melden oder direkt per PM!

Ich hab nun einen Ordner manuell erstellt und konnte ein paar Geräte testweise eintragen. Jedoch wird das Gerät unter "Geräte" nicht in dem Ordner angezeigt. Unter "Objekte" bekomme ich die Geräte angezeigt. Screenshots kann ich allerdings erst morgen hier rein stellen.

@garfonso Mir is auch grad aufgefallen, Sobald ich eine Taste am der fernbedienung drücke, wird das auch in den Logs direkt angezeigt. Also die Verbidnung steht 1a und es wird auch alles soweit erkannt. Nur halt ich selbst kann vom Broker nix über die Buttons steuern ``` cec2.0 2021-06-23 17:37:10.844 debug (19241) Updating TV.info.active to true cec2.0 2021-06-23 17:37:10.826 debug (19241) DEBUG: [ 47701] >> TV (0) -> Playback 1 (4): feature abort ( 0) cec2.0 2021-06-23 17:37:10.825 debug (19241) DEBUG: [ 47701] marking opcode 'menu request' as unsupported feature for device 'TV' cec2.0 2021-06-23 17:37:10.824 debug (19241) Parsing data... cec2.0 2021-06-23 17:37:10.824 debug (19241) ============================ Processing Event: undefined: {"type":"TRAFFIC","number":"47701","flow":"IN","source":0,"target":4,"opcode":0,"args":[141,0]} cec2.0 2021-06-23 17:37:10.822 debug (19241) TRAFFIC: [ 47701] >> 04:00:8d:00 cec2.0 2021-06-23 17:37:10.620 debug (19241) TRAFFIC: [ 47498] << 40:8d:02 cec2.0 2021-06-23 17:37:10.569 debug (19241) DEBUG: [ 47448] initiator 'TV' is not supported by the CEC adapter cec2.0 2021-06-23 17:37:10.459 debug (19241) TRAFFIC: [ 47338] << 40:8d cec2.0 2021-06-23 17:37:10.424 debug (19241) Sending true for id cec2.0.TV.menuStatus to TV cec2.0 2021-06-23 17:37:10.423 debug (19241) state cec2.0.TV.menuStatus changed: true (ack = false)