SMA Wechselrichter ueber SBFspot und Mqtt auszulesen / kein autocreate

Begonnen von Willi Wurst, 14 Dezember 2020, 12:35:58

Vorheriges Thema - Nächstes Thema

Willi Wurst

Hallo,
Ich versuche 3 SMA Wechselrichter ueber SBFspot und Mqtt auszulesen.
SBFspot funktioniert und published.
Ich bekomme allerdings kein autocreate hin. Tasmoto Steckdose funktioniert sofort.
Das device hat folgende Einstellungen und ist auf einem Raspi4 installiert.

Zitat###   MQTT Settings start  ###

MQTT_Publisher=/usr/bin/mosquitto_pub

# MQTT Broker in Fhem
MQTT_Host=192.168.1.97
MQTT_Port=1883

MQTT_Topic=sbfspot_{serial}

# Format of message items to be sent
# JSON: MQTT_ItemFormat="{key}": {value}
# TEXT: MQTT_ItemFormat={key}:{value}
# XML:  MQTT_ItemFormat=<item name="{key}" value="{value}" />
MQTT_ItemFormat="{key}": {value}

MQTT_ItemDelimiter=comma

# JSON: MQTT_PublisherArgs=-h {host} -t {topic} -m "{{message}}"
# TEXT: MQTT_PublisherArgs=-h {host} -t {topic} -m "{message}"
# XML : MQTT_PublisherArgs=-h {host} -t {topic} -m "<mqtt_message>{message}</mqtt_message>"
MQTT_PublisherArgs=-h {host} -t {topic} -m "{{message}}"

# Data to be published (comma delimited)
MQTT_Data=Timestamp,SunRise,SunSet,InvSerial,InvName,InvTime,InvStatus,InvTemperature,InvGridRelay,EToday,ETotal,PACTot,UDC1,UDC2,IDC1,IDC2,PDC1,PDC2

###   MQTT Settings end  ###


Der in Fhem installierte Mqtt2 Server(Broker) liest folgende publish von 3 verschiedenen Solar Wechselrichtern

###   EladaBroker  start  ###

2020.12.14 12:25:12 5: in:  PUBLISH: 0(139)(3)(0)(18)sbfspot_1100245644{"Timestamp": "14/12/2020 12:25:12","SunRise": "14/12/2020 07:51:00","SunSet": "14/12/2020 17:14:00","InvSerial": 1100245644,"InvName": ","InvTime": "14/12/2020 12:25:57","InvStatus": "Ok","InvTemperature": 0.000,"InvGridRelay": "?","EToday": 1.807,"ETotal": 38677.351,"PACTot": 725.000,"UDC1": 140.000,"UDC2": 0.000,"IDC1": 5.660,"IDC2": 0.000,"PDC1": 800.000,"PDC2": 0.000}
2020.12.14 12:25:12 4:   EladaBroker_192.168.1.97_49576 mosqpub|30061-raspberry PUBLISH sbfspot_1100245644:{"Timestamp": "14/12/2020 12:25:12","SunRise": "14/12/2020 07:51:00","SunSet": "14/12/2020 17:14:00","InvSerial": 1100245644,"InvName": ","InvTime": "14/12/2020 12:25:57","InvStatus": "Ok","InvTemperature": 0.000,"InvGridRelay": "?","EToday": 1.807,"ETotal": 38677.351,"PACTot": 725.000,"UDC1": 140.000,"UDC2": 0.000,"IDC1": 5.660,"IDC2": 0.000,"PDC1": 800.000,"PDC2": 0.000}
2020.12.14 12:25:12 5: EladaBroker: dispatch autocreate=simple\000mosqpub_30061_raspberry\000sbfspot_1100245644\000{"Timestamp": "14/12/2020 12:25:12","SunRise": "14/12/2020 07:51:00","SunSet": "14/12/2020 17:14:00","InvSerial": 1100245644,"InvName": ","InvTime": "14/12/2020 12:25:57","InvStatus": "Ok","InvTemperature": 0.000,"InvGridRelay": "?","EToday": 1.807,"ETotal": 38677.351,"PACTot": 725.000,"UDC1": 140.000,"UDC2": 0.000,"IDC1": 5.660,"IDC2": 0.000,"PDC1": 800.000,"PDC2": 0.000}
2020.12.14 12:25:12 5: in:  DISCONNECT: (224)(0)
2020.12.14 12:25:12 4:   EladaBroker_192.168.1.97_49576 mosqpub|30061-raspberry DISCONNECT
2020.12.14 12:25:12 4: Connection accepted from EladaBroker_192.168.1.97_49578
2020.12.14 12:25:12 5: in:  CONNECT: (16)#(0)(4)MQTT(4)(2)(0)<(0)(23)mosqpub|30063-raspberry
2020.12.14 12:25:12 4:   EladaBroker_192.168.1.97_49578 cid:mosqpub|30063-raspberry CONNECT V:4 keepAlive:60
2020.12.14 12:25:12 5: out: CONNACK:  (2)(0)(0)
2020.12.14 12:25:12 5: in:  PUBLISH: 0(145)(3)(0)(18)sbfspot_2100196497{"Timestamp": "14/12/2020 12:25:12","SunRise": "14/12/2020 07:51:00","SunSet": "14/12/2020 17:14:00","InvSerial": 2100196497,"InvName": ","InvTime": "14/12/2020 12:25:55","InvStatus": "Ok","InvTemperature": 37.760,"InvGridRelay": "?","EToday": 3.184,"ETotal": 46796.670,"PACTot": 1103.000,"UDC1": 195.580,"UDC2": 235.460,"IDC1": 4.511,"IDC2": 0.950,"PDC1": 881.000,"PDC2": 223.000}
2020.12.14 12:25:12 4:   EladaBroker_192.168.1.97_49578 mosqpub|30063-raspberry PUBLISH sbfspot_2100196497:{"Timestamp": "14/12/2020 12:25:12","SunRise": "14/12/2020 07:51:00","SunSet": "14/12/2020 17:14:00","InvSerial": 2100196497,"InvName": ","InvTime": "14/12/2020 12:25:55","InvStatus": "Ok","InvTemperature": 37.760,"InvGridRelay": "?","EToday": 3.184,"ETotal": 46796.670,"PACTot": 1103.000,"UDC1": 195.580,"UDC2": 235.460,"IDC1": 4.511,"IDC2": 0.950,"PDC1": 881.000,"PDC2": 223.000}
2020.12.14 12:25:12 5: EladaBroker: dispatch autocreate=simple\000mosqpub_30063_raspberry\000sbfspot_2100196497\000{"Timestamp": "14/12/2020 12:25:12","SunRise": "14/12/2020 07:51:00","SunSet": "14/12/2020 17:14:00","InvSerial": 2100196497,"InvName": ","InvTime": "14/12/2020 12:25:55","InvStatus": "Ok","InvTemperature": 37.760,"InvGridRelay": "?","EToday": 3.184,"ETotal": 46796.670,"PACTot": 1103.000,"UDC1": 195.580,"UDC2": 235.460,"IDC1": 4.511,"IDC2": 0.950,"PDC1": 881.000,"PDC2": 223.000}
2020.12.14 12:25:12 5: in:  DISCONNECT: (224)(0)
2020.12.14 12:25:12 4:   EladaBroker_192.168.1.97_49578 mosqpub|30063-raspberry DISCONNECT
2020.12.14 12:25:12 4: Connection accepted from EladaBroker_192.168.1.97_49580
2020.12.14 12:25:12 5: in:  CONNECT: (16)#(0)(4)MQTT(4)(2)(0)<(0)(23)mosqpub|30069-raspberry
2020.12.14 12:25:12 4:   EladaBroker_192.168.1.97_49580 cid:mosqpub|30069-raspberry CONNECT V:4 keepAlive:60
2020.12.14 12:25:12 5: out: CONNACK:  (2)(0)(0)
2020.12.14 12:25:12 5: in:  PUBLISH: 0(144)(3)(0)(18)sbfspot_2100188305{"Timestamp": "14/12/2020 12:25:12","SunRise": "14/12/2020 07:51:00","SunSet": "14/12/2020 17:14:00","InvSerial": 2100188305,"InvName": ","InvTime": "14/12/2020 12:25:50","InvStatus": "Ok","InvTemperature": 36.990,"InvGridRelay": "?","EToday": 1.106,"ETotal": 44000.432,"PACTot": 843.000,"UDC1": 236.300,"UDC2": 234.910,"IDC1": 1.033,"IDC2": 2.599,"PDC1": 243.000,"PDC2": 610.000}
2020.12.14 12:25:12 4:   EladaBroker_192.168.1.97_49580 mosqpub|30069-raspberry PUBLISH sbfspot_2100188305:{"Timestamp": "14/12/2020 12:25:12","SunRise": "14/12/2020 07:51:00","SunSet": "14/12/2020 17:14:00","InvSerial": 2100188305,"InvName": ","InvTime": "14/12/2020 12:25:50","InvStatus": "Ok","InvTemperature": 36.990,"InvGridRelay": "?","EToday": 1.106,"ETotal": 44000.432,"PACTot": 843.000,"UDC1": 236.300,"UDC2": 234.910,"IDC1": 1.033,"IDC2": 2.599,"PDC1": 243.000,"PDC2": 610.000}
2020.12.14 12:25:12 5: EladaBroker: dispatch autocreate=simple\000mosqpub_30069_raspberry\000sbfspot_2100188305\000{"Timestamp": "14/12/2020 12:25:12","SunRise": "14/12/2020 07:51:00","SunSet": "14/12/2020 17:14:00","InvSerial": 2100188305,"InvName": ","InvTime": "14/12/2020 12:25:50","InvStatus": "Ok","InvTemperature": 36.990,"InvGridRelay": "?","EToday": 1.106,"ETotal": 44000.432,"PACTot": 843.000,"UDC1": 236.300,"UDC2": 234.910,"IDC1": 1.033,"IDC2": 2.599,"PDC1": 243.000,"PDC2": 610.000}
2020.12.14 12:25:12 5: in:  DISCONNECT: (224)(0)
2020.12.14 12:25:12 4:   EladaBroker_192.168.1.97_49580 mosqpub|30069-raspberry DISCONNECT

###   EladaBroker  end  ###


Was muss ich machen um ein autocreate zu erzielen?
Wie werden die readings erzeugt? Bei Tasmota kann ich das ueber ein Template das in Fhem existiert erreichen.

Beta-User

MQTT2_SERVER will afaik zwingend eine ClientID von allen Clients. Das solltest du zunächst mal ergänzen, dann sehen wir weiter...
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

rudolfkoenig

MQTT2_DEVICE fuehrt kein autocreate aus fuer die von mosquitto_pub per Voreinstellung generierten ClientID.
Mit "-i XXX" kann man das aendern.

Willi Wurst

Die readings werden aus der Software SBFspot erzeugt. Die Angaben zu Mqtt sind aus einer vorgegebenen config Datei. Kann ich die client ID eventuell selbst vergeben oder sollte ich den Provider von SBFspot bitten diese zu ergaenzen?

Beta-User

Na ja, hier könntest du das einfach in den publish-Command einbauen, oder?

MQTT_PublisherArgs=-h {host} -t {topic} -i "sbfspot_{serial}" -m "{{message}}"

@Rudi: in den "Praxisbeispielen@Wiki" habe ich jetzt noch was bei "autocreate will nicht" eingefügt. Evtl. noch was bei "autocreate" in der cref? (Ich kann mich aber auch nicht an den Grund für die Sonderbehandlung von mosquito_pub erinnern).
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

Willi Wurst

Das meint SBFspot kann fuer die drei Wechselrichter eine client ID mitgeben?

rudolfkoenig

Grund fuer Sonderbehandlung: mosqutto generiert zufaellige ClientIDs (mosq-64xMUrGgX1nI6ZWCod, mosq-7hhJdneTV5RqSmu5iu, etc), ich (und vmtl. andere) testen gerne mit mosquitto_pub, und ich will nicht "Muell" angelegt haben. 

Willi Wurst


Beta-User

Zitat von: rudolfkoenig am 14 Dezember 2020, 13:25:03
Grund fuer Sonderbehandlung: mosqutto generiert zufaellige ClientIDs (mosq-64xMUrGgX1nI6ZWCod, mosq-7hhJdneTV5RqSmu5iu, etc), ich (und vmtl. andere) testen gerne mit mosquitto_pub, und ich will nicht "Muell" angelegt haben.
...hatte ich früher auch gemacht, aber mit m2server und rePublish kann man auch zumindest einzelne "Spezialfälle" auch gut testen. (Aber auch da ist die CID "seltsam"). ignoreRegexp ist für "Power-User" keine gute Lösung?

Ansonsten _glaube_ ich, dass es gut wäre, entweder prominenter darauf hinzuweisen, wie man das Problem umgehen kann, oder den SERVER entsprechend konfigurieren zu können, dass er es "frisst". mosquitto_pub ist eben auch ein omnipräsentes Tool, mit dem man "eben mal schnell was zusammenscripten" kann (auf praktisch jeder Linux-Kiste)...
(sieht man ja hier...)

Zitat von: Willi Wurst am 14 Dezember 2020, 13:22:40
Das meint SBFspot kann fuer die drei Wechselrichter eine client ID mitgeben?
Wenn ich das richtig verstanden habe, löst das script diverse Parameter aus, und das war der Versuch, das so weiterzustricken, dass eine passable ClientID erzeugt wird (für jeden WR eine, vermute ich jedenfalls).
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

rudolfkoenig

mosquitto_pub eignet sich wegen dem automatisch generierten ClientID nicht fuers autocreate.
Jedenfalls fehlt mir die Fantasie dafuer.

Beta-User

Hmm, ja, auch wieder wahr...
Wenn, dann müßte man die in diesen Fällen entfernen, aber das jeweils zu prüfen ist vermutlich auch eine Sch...idee,...

Vielleicht als Merkposten: Bin mir nicht sicher, ob wir bei dem paho-Framework ("mqttjs_.*" (?))nicht genauso verfahren sollten. Hatte heute wieder einen User, der darüber gestolpert ist: https://forum.fhem.de/index.php/topic,116622.msg1110465.html#msg1110465. Da ist es nicht ganz so dramatisch, weil die random-CID "nur" bei jedem Start von so einem Java-Dienst erzeugt wird.
Weiß aber auch nicht, was besser ist: kein autocreate oder ständig neue Devices bei Usern, die nicht verstehen, wo es herkommt.
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

rudolfkoenig

Ich sehe die Probleme bei der Nutzung von ClientID in FHEM, aber ich meine immer noch, dass es den Anfaengern hilft.

Womoeglich brauchen wir Migrationshilfen wie das Loeschen vom ClientId von allen readingsList oder beim automatisches Anlegen der ersten MQTT2_DEVICE vom MQTT2_CLIENT aus das Setzen eines bridgeRegexps.

Beta-User

Das mit Berücksichtigung der ClientID ist auf alle Fälle die "sauberere" Lösung, und es ist immer ein Problem, auf Eindeutigkeit zu verzichten. Sehe ich im Prinzip genauso, auch wenn das "Paradebeispiel" Tasmota afaik zwischenzeitlich die ... Vorgabe "Tasmota" im Topic _nicht_ mehr verwendet.
Weiter _glaube_ ich, dass inzwischen so viele Leute auf ein relativ offensichtliches "selber (default-) Topic" in einem list auf Anhieb die richtige Antwort wüßten, von daher sind die Argumente im Gewicht zwischenzeitlich m.E. weiter in Richtung "für readingList ignorieren" verschoben.

Aber letztlich geht es eher darum, den User beizubringen, wie die Infos zu lesen sind, und auch diese Botschaft ist m.E. soweit angekommen, dass es nicht lohnt, an der Stelle irgendwas zu ändern :) . Na ja, genauer gesagt finde ich es nicht schlecht, wenn die ClientID in der readingsList bei autocreate-Einträgen steht, so sieht man ggf. recht gut, was attrTemplate-Konfiguration war und was ggf. nachträglich noch dazukam ;) .

"Migrationshilfe" würde ich ggf. als Anschubser in Richtung passende list-Befehle im Wiki auffassen, müßte mal drüber nachdenken; allerdings ist es nicht so einfach, weil der Doppelpunkt in vielen readingList-Zeilen (mehrfach) vorkommt und der Topic sehr flexibel aufgebaut werden kann; muss ja nicht mal ein "/" rein, an dem man sich per FILTER-Regex orientieren könnte...

Bei MQTT2_CLIENT könnte es in der Tat hilfreich sein, die User in Richtung bridgeRegexp-Anlage zu schubsen. Wie wäre es mit einem automatisch angelegten comment-Attribut, das gleich "klickbar" den Hinweis samt setter auf das attrTemplate enthält? Sollte relativ simpel umzusetzen sein, oder?
(Kann aber sein, dass sich das mit den neueren Anwendungsfällen "ich zapfe für mein spezielles Gadget einen externen Broker (auf dem Gadget) an" in die Quere kommt).
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

Willi Wurst

Soo bin wieder da. Da hab ich wohl ne Diskussion unter Profis ausgeloest. Und trotzdem mit meinem laienhaften Verstaendnis mitgenommen das
autocreate mit  mosquitto_pub nicht funktioniert. Besteht die Moeglichkeit einen anderen client zum publishen zu nehmen. Der muesste halt die Parameter aus SBFspot verstehen und auf Raspian laufen.
Oder gibt es eine ander Idee?
Wahnsinn wie schnell hier alle reagieren und antworten!! Dafuer ein dickes Danke.

Beta-User

Es geht schon, siehe Rudis Hinweis auf -c und meinen Vorschlag....
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files