UPDATE 31.10.: Amazon Alexa - ioBroker Skill läuft aus ?

[Ralla66]

@plchome-0 sagte in Test Adapter Pylontech v0.0.6:

Da ist nix besonderes bei.... ganz primitiv

Ok, für dich ist das ganz primitiv.
Tolle Arbeit die Ihr da macht.
Warum man son TCP Server unbedingt braucht verstehe ich trotzdem nicht,
da die Rohdata ja im ESP vorhanden sind. Ist aber auch egal.
Nachtrag, gerade gesehen, Tasmota TCP Ahja :-)
Das ist was für mich.

[PLCHome 0]

@ralla66
Ich hab das gerade mal getestet.

Anleitung auf: https://tasmota.github.io/docs/Serial-to-TCP-Bridge/

Als bin können nur die folgenden oder selbst kompilierte verwendet werden, da ansonsten der TCP-Server nicht enthalten ist:
http://ota.tasmota.com/tasmota32/release/tasmota32-zbbrdgpro.bin
http://ota.tasmota.com/tasmota/release/tasmota-zbbrdgpro.bin

Es müssen vorher die Gipos eingestellt werden. Je einer auf TCP Rx und TCP Tx.
Bei GPIO1 mit TCP Tx und GPIO3 mit TCP Rx werden die gleichen Leitungen wie am USB-Anschluss benutzt.

Dann auf der Console folgendes eingeben, aber erst nachdem die GIPS zugewiesen sind:

TCPBaudRate 115200
TCPStart 23
Rule1 ON System#Boot do TCPStart 23 endon 
Rule1 1 

Es funktioniert, da ein transparenter TCP-Server auf z.B. Port 23 zur Verfügung gestellt wird. Der Port ist wählbar, einfach die 23 z.B. gegen 9000 austauschen.

Und natürlich zwischen die Gipos und den Westernstecker noch einen MAX2323 löten!!!!

[PLCHome 0]

@ralla66 sagte in Test Adapter Pylontech v0.0.6:

Warum man son TCP Server unbedingt braucht verstehe ich trotzdem nicht,
da die Rohdata ja im ESP vorhanden sind.

Brauchst du nicht, es gibt andere Lösungen, die direkt im ESP die Daten aufbereiten.
https://github.com/irekzielinski/Pylontech-Battery-Monitoring

Allerdings liefert diese Lösung zu wenig Informationen für mich. Und zum anderen habe schon obern erwähnt, es gibt auch Leute, die eine Lösung ohne Basteln suchen.

Der Schaltplan in irekzielinskis Projekt ist übrigens auch für den Aufbau mit Tasmota der gleiche.

Oder so wie die Jungs hier direkt in Tasmota:
https://forum.iobroker.net/topic/63656
Ist aber scheinbar gebastel.

Du kannst ja mal alle drei Lösungen vergleichen und berichten ob der Adapter überflüssig ist.

• Adapter mit Tasmota TCP
• Pylontech-Battery-Monitoring an MQTT
• Tasmota Script aus dem Thread per MQTT

Achso: hatte ich erwähnt, man kann den Adapter auch direkt an den Akku ohne einen TCP-Server über eine serielle Schnittstelle oder USB-RS232-Wandler anschließen, dann stellt sich die Frage nach einem ESP nicht.

[Ralla66]

@plchome-0
sagte in Test Adapter Pylontech v0.0.6:

Du kannst ja mal alle drei Lösungen vergleichen und berichten ob der Adapter überflüssig ist.

Das hat ja nichts mit Überflüssig zu tun. Das wird schon gut sein.
Suche halt andere Wege ohne Waveshare, der ESP ist doch vorhanden.
Die Projekte von Irekzielinski / Tasmota Creatronix Forum sind ja bekannt.
Das läuft bei mir ja auch. Die Datenübertragung ist ja Dokumentiert im Photovoltaik Forum.
Habe alles gelesen, deine Read me auch.

Wann wird denn der Adapter Grün, wenn Daten empfangen wurden ?

[PLCHome 0]

@ralla66 sagte in Test Adapter Pylontech v0.0.6:

Wann wird denn der Adapter Grün, wenn Daten empfangen wurden ?

Ja und Gelb/Rot, wenn er keine empfängt oder die Verbindung nicht aufbauen kann.
Die Frage ist auch, welcher Akku angesprochen wird. US und H2 sind getestet.

Welche Akkus hast du?

[Ralla66]

@plchome-0

Teste Tasmota TCP ESP ja erst auf dem Schreibtisch, erwartet der Adapter bestimmte Daten ?
Würde gerne die Strecke ESP TCP nach Adapter testen. Per Script könnte ich ja versuchen
einen Datensatz zu senden, ok dann geht Rule nicht wobei ja TCP per Consolenbefehl aktiviert
werden kann.
Grübel oder aus hterm über ESP nach Adapter senden :-)

Welcher Akku, US.

Nachtrag, sendet der Adapter zum Akku dieses ? :
7E 32 30 30 31 34 36 34 32 45 30 30 32 30 31 46 44 33 35 0D

[PLCHome 0]

@ralla66

Das ist nicht jedesmal nötig. Die neueren Firmware speichern dieses. Älterer vergessen es, wenn der Akku ausgeschaltet wird, das kann aber mit einem Firmwareupdate behoben werden. Neuere Modelle melden einen Fehler, wenn es über die Konsole kommt.

Es ist aber auf jeden fall einstellbar über .config.set_speed:
https://github.com/PLCHome/ioBroker.pylontech#transmission-speed

Der AsciiText ist übrigens:
~20014642E00201FD35<cr>

[Ralla66]

@plchome-0

ok dann sende ich mal zum Adapter

7E 32 30 30 31 34 36 30 30 43 30 36 45 31 31 30 31 30 
46 30 44 34 35 30 44 34 34 30 44 34 35 30 44 34 34 30 44 34 35 30 44 34 
34 30 44 33 45 30 44 34 35 30 44 34 41 30 44 34 41 30 44 34 42 30 44 34 
41 30 44 34 41 30 44 34 41 30 44 34 41 30 35 30 42 43 33 30 42 43 33 30 
42 43 33 30 42 43 44 30 42 43 44 30 30 30 30 43 37 32 35 42 46 36 38 30 
32 43 33 35 30 30 30 30 32 45 35 35 33 0D

[PLCHome 0]

@ralla66 Der Adapter verarbeitet nur Daten, die er selber angefraget hat. Einfach etwas hinschicken funktioniert nicht.
Er arbeite auch nicht mit den "~" Befehlen.

[l1berty]

Hi, Der Adapter läuft sauber bei mir.

Initial mit nem ESP32 der die Daten auf einem Port über Wifi zur Verfügung gestellt hat.

Nun mit Waveshare RS232/485/422 TO POE ETH (B).

Hersteller Link

POE powered mit Hutschienenmontage sieht das ganze schon ganz nett aus !
(Das Webinterface von dem Ding ist eine Katastrophe, mit der Software vom Hersteller lässt es sich aber gut parametrieren, bei Switches die kein 10 Mbit mehr unterstützen kann es Probleme geben).

Viele Grüße

[PLCHome 0]

@l1berty Danke, das mit den 10Mbit bei dem Waveshare/POE werden ich zum nächten Release in die read.me aufnehmen.

@Radi kann dein Waveshare auch 100Mbit/1Gbit oder redet der auch nur mit Switches, die 10Mibt unterstützen?

[Radi]

@plchome-0 Laut Beschreibung können beide Umsetzer (der von mir vorgeschlagene wie auch der von l1berty verwendete) 100Mbit. Auszug aus der Beschreibung des Herstellers:
10/100M Auto-MDI/MDIX ethernet interface, regardless of cross-over or straight-through cable

Der Switch, an dem der Umsetzer bei mir angeschlossen ist (Unifi USW Flex mini), meldet eine Fast-Ethernet-Verbindung (100Mbit).

[PLCHome 0]

So der Adapter ist im stabilen Zweig.
Und Zack, Zack 60 Installationen :-)

[Ralla66]

@plchome-0

Nabend, bin weiter am testen mit der ESP TCP Bridge.
Was wird bei Netzwerkhost eingetragen ? Die IP der ESP TCP Bridge ohne http
bei mir dann 192.168.2.177 ?

Trockenlauf :
Vom Windows PC TCP Client über ESP TCP Bridge nach Hterm geht.
Von Hterm über ESP TCP Bridge nach Windows PC TCP Client geht.
Wireshark zeigt Telnet als Protokoll an.
Also sind die Kabelwege in Ordnung.

192.168.2.89 ist IO Broker mit dem Adapter

[PLCHome 0]

@ralla66 Der akku antwortet nicht ist das Kabel zum Akku ok? Was sendet der Akku?

[Ralla66]

@plchome-0

Der Akku ist gar nicht angeschlossen.
Der Adapter müsste ja eine Anfrage zur Batterie senden.
Mit Wireshark ist keine Kommunikation vom Adapter zum ESP zu sehen.

[PLCHome 0]

@ralla66 Lade den Adapter auf deinem hTerm Rechner von Github herunter, npm geht nicht und starte statt hTerm auf dem Rechner in der Root der Quellen.

https://github.com/PLCHome/ioBroker.pylontech/archive/refs/heads/master.zip

node build/moc/serialMoc.js <port> 115200 US

Aber es ist komisch unter hTerm hättest du das erste Komando "pwr" sehen müssen.
Und im wireshark auch.

[Ralla66]

@plchome-0

Also läuft der Adapter nicht auf meinem Raspi 4 mit IO ?

[PLCHome 0]

@ralla66 Irgendwie ist mir das hier zu blöd:
Zuerst schreibst du, dass du mit Hterm gegen einen gefummelten TCP/V24 Adapter getestet hast.

Also:
Verbinde deine Raspberry IO Installation in der du den ioBroker-Pylontech-Adapter installiert hast zu deinen TCP/V24 Adapter. Den TCP/V24 Adapter mit deinem Testrechner und starte dadrauf die Akkuemulation, also den serialMoc

Dan läuft der Adapter.

Sollte es nicht funktionieren, dann prüfe bitte deinen Aufbau/Hardware oder Konfiguration.

Es geht nämlich das Gerücht rum, dass der ioBroker-Pylontech-Adapter funktioniert!

Deinen Adapter kannst du mit Putty in raw und hTerm prüfen.

[Ralla66]

@plchome-0

gefummelt, ah ja.
Danke für die Kommunikation.