@adamantium lies es nochmal! in /opt/iobroker ohne -g probieren

@mccavity sagte in IoBroker.Jeelink + Davis geht teilweise - Hilfe beim Rest?: Einen habe ich doch noch, den ich nicht vorenthalten wollte - ich habe gerade gesehen, daß im Battery Status auf einmal "okOK" steht - da hat der Parser etwas mißverstanden. Den dafür verantwortlichen Empfang habe ich im Log finden können: Man sieht, daß das mal wieder eine "vermackelte" Zeile war: 2022-12-23 14:10:41.380 - debug: jeelink.0 (18237) data received: OK VALUES DAVIS 0 20=3,22=-66,21=okOK VALUES DAVIS 0 20=4,22=-6 DAVIS 0 20=1,22=-67,21=ok,4=0.00,5=228,8=39, Bis zu okOK ist die Zeile in Ordnung und wurde auch weiter bearbeitet Es scheint, als würde der Adapter momentan nur dann anfangen zu arbeiten, wenn das Zeilenpräfix "OK VALUES DAVIS" nicht am Anfang der Zeile steht - zumindest läßt die Log-Zeile 2022-12-23 14:10:41.386 - debug: jeelink.0 (18237) splice : 20=3,22=-66,21=okOK,VALUES,DAVIS,0,20=4,22=-6,DAVIS,0,20=1,22=-67,21=ok,4=0.00,5=228,8=39, darauf schließen. Trotzdem scheint er, wenn er die Zeile verarbeitet, richtigerweise von vorne anzufangen. Er hat auch bemerkt, daß irgendetwas nicht stimmt, was die nächste Logzeile bestätigt: 2022-12-23 14:10:41.387 - debug: jeelink.0 (18237) something is wrong in stream 20=3,22=-66,21=okOK strange part ->VALUES Nicht ganz richtig vermutet, wegen OK VALUES DAVIS springt er überhaupt in die Bearbeitung und "spliced" den Rest auf. Das ist auch soweit gut bis keine Wertepaare mehr enthalten sind -> VALUES DAVIS.. Das erkennt er und meckert "VALUES" an. Im Prinzip müßte der Parser pro empfangener Zeile folgendes prüfen: Das Präfix lautet fix "OK VALUES DAVIS" Ich prüfe auf OK und DAVIS an übernächster Stelle ab. Die ID besteht aus einer einzelnen Ziffer zwischen zwei Leerzeichen Ein Meßwert besteht aus einem Schlüssel, dem Gleichheitszeichen, dem Wert und einem Komma Schlüssel bestehen aus einer ein-oder zweistelligen Nummer, optional einem Punkt plus einer weiteren Ziffer Werte können verschiedene Datentypen enthalten: unsigned int (z.B. WindDirection) signed int (z.B. RSSI), signed float (z.B. Temperature, Dezimaltrennzeichen ist der Punkt), String (z.B. Battery) wird genauso verarbeitet alle möglichen Schlüssel sind bekannt Bis auf Channel und PacketDump dürfte alles drin sein. Annahmen / Beobachtungen: Die Meßwerte beginnen mit einer fixen Folge (Schlüsselnummer in Klammern): <Channel (20)><RSSI (22)><Battery (21)><WindSpeed (4)><WindDirection (5)> nach den fixen Meßwerten folgen i.d.R. 0 bis 2 weitere Meßwerte Die Meßwerte <Temperature (1)>, <Humidity (3)>, <RainTipCount (8)> und <RainSecs (9)> werden einzelnen übertragen Die Meßwerte <WindGust (6)> und <WindGustRef (7)> werden in der gleichen Zeile direkt nacheinander übertragen Werte mit einem float Datentyp haben zwei Nachkommastellen Eine optimale Zeile sieht wie folgt aus: <Präfix><ID><Channel (20)><RSSI (22)><Battery (21)><WindSpeed (4)><WindDirection (5)>[<Meßwert (x)>...] ob die Reihenfolge so ist oder auch nicht, ist in der Auswertung egal. Wenn OK VALUES DAVIS 0 am Anfang steht, wird alles danach zwischen den Kommas über das = als Wertepaar identifiziert und anhand der Schlüsselnummer richtig weggeschrieben. Fehlerfälle und Ausnahmen: Das Präfix kann unvollständig sein, möglicherweise auch falsche Zeichen enthalten Das Präfix kann auch weiter hinten in der Zeile erscheinen, das ist zwingend ein Zeichen dafür, daß die vorherige Zeile unvollständig war - möglicherweise fehlt nur der Zeilenumbrauch, möglicherweise aber auch ein oder mehrere vollständige Meßwerte oder ein Teil eines Meßwertes Meßwerte ohne abschließendes Komma sind möglicherweise unvollständig und sollten ggf. verworfen werden und nur im Log erwähnt werden, zumindest als debug - eine höhere Stufe könnte man ggf. überdenken. Alles was nicht passt wird verworfen, die "strange" Meldungen sind nur debug. Wenn der Anfang nicht passt, führt halt zu einer Meldung das Konfig nicht richtig ist. Könnte man auch unter debug laufen lassen, bisher sah ich es als hilfreich für die Inbetriebnahme bzw. als Hinweis bei ID-Wechsel nach Batteriewechsel (da der Adapter ja auch die LaCrosse/Technolink verarbeitet). Ich weiß nicht, ob es möglich ist, daß Zeilen auch ohne das Präfix beginnen können; so gut kenne ich den JeeLink-Sketch nicht, aber da sowohl das Funkprotokoll als auch das serielle Protokoll als unzuverlässig eingestuft werden müssen, würde ich damit rechnen, daß es überall zu fehlenden Bytes kommen kann und daher ein paar Sanity-Checks einbauen. Zusammen mit den Datentypen sollten sich zumindest ein paar Grundchecks durchführen lassen, genauso damit, daß es im Prinzip nur das Präfix aus Großbuchsteben und den (vermutlich) einzigen String Wert in Kleinbuchstaben gibt. Merkt sich der Adapter eigentlich die zuletzt gemessenen Werte? Falls ja, könnte man überlegen, ob man da ggf. noch Änderungen über die Zeit prüfen möchte - aber ich denke, das sollte dann schon extern in der Auswertung geschehen, je weniger der Adapter voraussetzt, umso besser. Wenn der Adapter gut erkennt, und wenn es die Feststellung "schlechter Empfang" ist, dann ist schon viel gewonnen :-) Ich bin hier für KISS (keep it simple und stupid), einfach auf das nächste saubere Telegramm warten und dieses auswerten und wegschreiben. Großartig rumorakeln was von einem String noch auswertbar ist oder nicht, bringt bei so schnell ankommenden Telegrammen nichts. Eher wäre der sketch auf dem Stick gefragt um die Telegramm richt zu separieren und nicht ein "...=okOK VALUES..." zu bekommen. Sonst kommt da als letztes immer ein Komma. Und wenn wir an den Daten an sich zweifeln (vergleich mit letzten Wert) :dizzy_face:

@crunchip Danke ich werde erst am Dienstag dazu kommen mir das Ganze noch einmal anzuschauen.

@mickym Vielen Dank für die Hilfe. Ich habe jetzt einfach den Adapter OpenDTU https://github.com/o0shojo0o/ioBroker.opendtu verwendet. Der geht zwar über die Webseite der OpenDTU, aber macht, was ich will...

@chase295 , für was ist der 300 Ohm Widerstand? Die Taster kommen zwischen Gnd und GPIO, man kann dann noch ein 4,7k Widerstand zwischen 5V und GPIO als Pullup schalten braucht man in der Regel aber nicht,

@jensven ja das kannst du so machen.

@toralt Nein, das geht bei dem Button nicht. Es gibt 3 Zustände (enum, 0-2): 0 = einfacher Click 1 = Doppelclick 2 = longpress der Datebpunkt im IoBroker ändert sich nicht, wenn man ein weiteres mal clickt. Er bleibt auf 0. Erschwerdend kommt hinzu, dass vom Zigbee Gateway, wo der Taster dran hängt, alle Minute der aktuelle Zustand (in meinem Fall 0) gesendet wird. Also ich setze manuell in Objekte den Zustand auf z.B. 5, ist er eine Minute später automatisch wieder auf 0 und es wird ungewollt die Schaltaktion ausgelöst, da ja eine Zustandsänderung erkannt wird. Der Zustand bleibt solange auf 0, bis ein Doppelclick oder longpress erkannt wird. Deswegen geht ja auch click=einschalten, doppelclick = ausschalten Gibt es bei Ali o.ä. Zigbee Taster, die einfach nur 0/1 toggeln?

Achtung! Die Gen1 Shellies senden den MQTT Prefix mit "shellies/" davor, den Gen2 nicht! Ich weis nicht, ob das der Shelly Adapter das immer so erwartet. Eventuell mal probieren, bei Gen2 Geräten das bei den Einstellungen selber davor setzen.

Geht jetzt plötzlich, Danke.

@glasfaser https://forum.iobroker.net/topic/55115/gelöst-benötige-hilfe-modbus-tcp-hoymiles-hm-1500-dtu-pro das hab ich bereits durch und hab nichts erreicht. hier werden die Daten per Modbus RTU ausgelesen. Ich möchte aber per Modbus TCP kommunizieren. Ich habe das Problem die korrekten Adressen und deren Einstellung im iobroker Adapter zu finden.

Okay, habe meinen Denkfehler selbst gefunden. Ich musste die IP des WR ermitteln und den ansprechen. Jetzt läuft es.

@lazyqueen du sprichts von Geräten sagst aber nicht welche es sind.. und nein du brauchst kein binding du kannst auch per [image: 1680065794429-911574a1-2172-4b18-8e74-683b7c636610-grafik.png] auch schalten..oder oder oder..es gibt so viele möglichketeine

@homoran said in Modbus Fehler "current mbap contains trashed request id": ein client kann nur an einem Master hängen. Wenn dann müsste es heißen, ein Client (Master) kann nur an einem EM24 Server (Slave) hängen. Client = Master Server = Slave das geht nicht! Das geht eigentlich schon. Der EM24 kann laut Doku 5 Client Verbindungen handeln. Inzwischen bin ich allerdings schon etwas schlauer. Beim EM24 <-> Cerbo gibt es ein Firmware-Verbindungsproblem. Es schaut so aus, wenn mehrere Geräte auf den EM24 zugreifen, dass dieser gelegentlich aussteigt. Ursache unbekannt... Lockup Fehler [image: 1679663117347-1.jpg] Lies doch den Cerbo aus, da bekommst du die EM24 Werte Könnte ich... Nur steuere ich den Setpoint des Cerbo über eine SPS. Wenn ich die Daten vom EM24 über den Cerbo auslese, bekomme ich die Daten nur mit noch mehr Verzögerung. Die Daten des EM24 möchte ich aber auch direkt im Cerbo haben. Manchmal schalte ich die Steuerung über die SPS aus. Dann muss der Cerbo die ESS Funktion selber mit den Daten des EM24 machen.

@arteck said in zigbee external converter Wert verrechnen: das :+1:

@glasfaser Habe die Lösung jetzt gefunden. Problem hier ist jetzt, dass eine neue "Anmeldung" am SolarEdge über Modbus nur innerhalb der ersten 2 Minuten nach einschalten des Wechselrichters möglich ist. Also: Wechselrichter ausschalten kurz warten Wechselrichter einschalten Verbindung zu modbus auf Wechselrichter funktioniert

@bulli1308 wie @mickym schon schreibt: Jeden, aber auch wirklich jeden Befehl den Tasmota kennt: https://tasmota.github.io/docs/Commands/ kannst du unterhalb von cmnd anlegen und Nutzen Du kannst also in der Tasmota-Konsole ggf. Testen falls es nicht etwas so einfaches ist wie POWER3

@silbaer Hi, hast du schon was Sinnvolles auslesen können. Besitze ebenfalls einen Fronius Sunrise WR.