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 Beta User,
ich hab nichts zu dem SBFspot config script hinzugefuegt.

MQTT_Topic=sbfspot_{serial}   (liest die SMA Bezeichnungen der verschiedenen Wechselrichter ein)

in:  PUBLISH: 0(139)(3)(0)(18)sbfspot_1100245644{"Timestamp": "14/12/2020 12:25:12","SunRise".....
in:  PUBLISH: 0(145)(3)(0)(18)sbfspot_2100196497{"Timestamp": "14/12/2020 12:25:12","SunRise"......
in:  PUBLISH: 0(144)(3)(0)(18)sbfspot_2100188305{"Timestamp": "14/12/2020 12:25:12","SunRise".....

fuer mich liest sich eure Diskussion eher wie geht nicht moskito_pub
Zitat....Sonderbehandlung: mosqutto generiert zufaellige ClientIDs (mosq-64xMUrGgX1nI6ZWCod, mosq-7hhJdneTV5RqSmu5iu, etc),....


Beta-User

Zitat von: Beta-User am 14 Dezember 2020, 13:20:16
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}}"
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: ZigBee2mqtt, MiLight@ESP-GW, BT@OpenMQTTGw | ZWave | SIGNALduino | MapleCUN | RHASSPY
svn: u.a Weekday-&RandomTimer, Twilight,  div. attrTemplate-files, MySensors

Willi Wurst

Hallo Beta-User
ich scheine schlaefriger zu sein wie meine Wechselrichter und hab Dein -i "sbfspot_{serial}" nicht gesehen.
ZitatMQTT_PublisherArgs=-h {host} -t {topic} -i "sbfspot_{serial}" -m "{{message}}"
Fhem macht nun sein autocreate.
Meine Wechselrichter wollen teilweise nicht mehr wach werden.
Wenn die Sonne morgen wieder scheint schaue ich mir die readings mal an und berichte wie es aussieht.

Super so langsam machts SPASS.

Willi Wurst

Danke an alle fuer die schnelle und  kompetente Hilfe!

Autocreate funktioniert mit allen Wechselrichtern!
Readings werden erstellt!

ZitatreadingList
_serial_:1100245644:.* { json2nameValue($EVENT) }
_serial_:2100196497:.* { json2nameValue($EVENT) }
_serial_:2100188305:.* { json2nameValue($EVENT) }

Jetzt kommt noch die Arbeit um eine eine nette Auswertung nach Anwendungsfaellen zu erstellen!




Willi Wurst

Gehört zwar nicht zu Mqtt aber gibt es dazu eine Lösung?

X-Achse im SVG-Plot skalieren z.B.:  8 Uhr bis 16 Uhr

https://forum.fhem.de/index.php/topic,59658.msg1111274.html#msg1111274

Beta-User

Da Rudi hier mitliest, kann er dir sicher was dazu sagen.

Vorab mal danke für's wieder aufmachen ;) .
Ich hätte da noch ein paar Punkte gehabt; vielleicht hast du Lust, die MQTT-Themen ggf. noch zu vertiefen?
Zitat von: Beta-User am 16 Dezember 2020, 10:19:14
Interessant sind hier v.a. die Angaben MQTT_Publisher und MQTT_PublisherArgs.
Der "Trick" besteht nun darin, MQTT_PublisherArgs passend zu ergänzen. Der TE hat mit meinem dort zu findenden Vorschlag einen Teilerfolg erzielt und war damit glücklich, ich halte ihn für verbesserungsfähig; leider hat der TE den Thread geschlossen, so dass wir bis auf weiteres auf die Antwort warten müssen, ob das hier besser oder schlechter ist und noch weiter optimiert werden kann...:
MQTT_PublisherArgs=-h {host} -t {topic} -i sbfspot_{serial} -m "{{message}}"

Vermutlich sollte man sich auch den Topic ("MQTT_Topic=SMA_Converters/sbfspot_{serial}"?) und die Auswertungsanweisung "{ json2nameValue($EVENT) }" nochmal ansehen, ich vermute, dass es im Interesse "guter Reading-Namen" hilfreich wäre, hier die "vereinfachte complex"-Variante von json2nameValue() zu verwenden. Dann könnte evtl. sowas rauskommen:
attr DEVICE readingList SMA_Converters/1100245644:.* { json2nameValue($EVENT,'',$JSONMAP) }
attr DEVICE jsonMap bad_reading1:good_reading1 not_needed1:0 [tbc]


Wer speziell für Solaranlagen Anregungen sucht, wie jsonMap "gut" zu setzen ist, findet evtl. bald dazu was hier: Frevel: Die Idee einheitlicher Devicenamen und Readings. Jedenfalls, was Reading-Namen angeht, bin ich starker Befürworter einer einheitlichen (und internationalisierten!) Namensgebung. Das macht es z.B. auch einfacher, wenn es z.B. um die Anbindung von Sprachsteuerungssystemen geht.
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: ZigBee2mqtt, MiLight@ESP-GW, BT@OpenMQTTGw | ZWave | SIGNALduino | MapleCUN | RHASSPY
svn: u.a Weekday-&RandomTimer, Twilight,  div. attrTemplate-files, MySensors

rudolfkoenig

#21
ZitatX-Achse im SVG-Plot skalieren z.B.:  8 Uhr bis 16 Uhr
Vmtl. noch dazu Jahreszeit-abhaengig
Gibts meines Wissens nicht.
Was gibts ist fixedRange, fixedOffset und endPlotNow.
Und Grafana :)


Nachtrag: Bitte Themen nicht schliessen, sonst haben andere Teilnehmer keine Moeglichkteit mehr, was dazu beizutragen oder verwandte Fragen zu stellen.

Willi Wurst

Ich habe jetzt auf dblog/SQLite umgestellt.

Jetzt hab ich zwei neue Fragen.

1 Frage)
Kann ich von einer anderen SQLite Db direkte "inserts" in die FHEM Db machen.
Bisher habe ich über einen Umweg

Erzeugen --> *.csv --> File anpassen auf reading Format -->  FHEM Db ausschalten --> *.csv in FHEM history Db Tabelle einlesen --> Index löschen/neuerstellen --> FHEM Db einschalten

Daten in die FHEM Db bekommen. Sehr, sehr zeitaufwendig die Prozedur sie ist.

2 Frage)
Um "Historische readings", selbst erzeugte oder durch in FHEM vorhandene Abfragen, zu manipulieren (Rechnen mit den readings / Einheiten o.ä. hinzufügen) bin ich auch den obigen Weg gegangen.
Gibt es eine Funktion in FHEM um "Historische readings" zu manipuliern?

Beta-User

Vermutlich kann https://fhem.de/commandref_modular_DE.html#DbRep dir einen Teil der Arbeit abnehmen, Details dazu wären aber m.E. eher separat im passenden Forumsbereich zu erfragen.

Was "Rechnen" angeht, kann man für SVG-Auswertungen dann auch nachträglich mit logProxy vorverarbeitende Anweisungen generieren. Aber auch das wäre m.E. woanders zu vertiefen.
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: ZigBee2mqtt, MiLight@ESP-GW, BT@OpenMQTTGw | ZWave | SIGNALduino | MapleCUN | RHASSPY
svn: u.a Weekday-&RandomTimer, Twilight,  div. attrTemplate-files, MySensors

Willi Wurst

Gut das mir momentan keiner in mein Zeitmanagment reinredet.
Nach überfliegen des Wikis

DbRep - Reporting und Management von DbLog-Datenbankinhalten

denke ich das Dein Tip nicht mit Gold aufzuwiegen ist.

Also kein Gold für Dich, trotzdem Danke!

Beta-User

Danke für die Rückmeldung.

Hast du das hier wahrgenommen?
Zitat von: Beta-User am 16 Dezember 2020, 16:33:46
Ich hätte da noch ein paar Punkte gehabt; vielleicht hast du Lust, die MQTT-Themen ggf. noch zu vertiefen?
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: ZigBee2mqtt, MiLight@ESP-GW, BT@OpenMQTTGw | ZWave | SIGNALduino | MapleCUN | RHASSPY
svn: u.a Weekday-&RandomTimer, Twilight,  div. attrTemplate-files, MySensors

Willi Wurst

Die readings die vom Wechselrichter kommen brauche ich alle. Die Namen der readings möchte ich nicht ändern da sie in der vorgelagerten Anwendung genau so heißen.
Standards sind OK.
ABER Standardisierung erfordert viel Arbeit. Innerhalb von Gerätefamilien eines Herstellers und Herstellerübergreifend kaum machbar. Innerhalb von FHEM vielleicht. Aber bei dem Getümmel im Bereich  "SMARTHOME" wohl eher nicht.

MQTT werden ich mir noch genau anschauen wenn ich die ersten Sensoren einsetzte.

Beta-User

Ok, kein Ding, war als Angebot gedacht :) .

Eventuell würde ich aber trotzdem noch anregen, den "-i"-Parameter nochmal anzusehen (da kam nur der string "_serial_", oder habe ich das missverstanden?), was an dem "schnellen2 Vorschlag mit den "" liegen könnte, und einen längeren Topic zu wählen. Alles auf der untersten Ebene "abzufackeln", ist vermutlich irgendwann ziemlich unübersichtlich, wenn noch mehr MQTT-Geräte dazu kommen. Und man scheint es ja beieinflussen zu können...

Beides sollte jeweils kein "breaking change" sein ;) .
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: ZigBee2mqtt, MiLight@ESP-GW, BT@OpenMQTTGw | ZWave | SIGNALduino | MapleCUN | RHASSPY
svn: u.a Weekday-&RandomTimer, Twilight,  div. attrTemplate-files, MySensors