Hallo Ralf, vielen Dank für deine Antworten.
Nun läuft alles.
1 „Gefällt mir“
guten morgen,
bin zufällig auf euer forum gestoßen und hoffe, dass ihr mir helfen könnt.
ich schaffe es den SF von der cloud zu nehmen, allerdings bekomme ich dann keine werte an meinen mqtt-broker.
iot/73bkTV/DEVICE_ID/properties/read {„properties“: [„getAll“]} habe ich auch schon gesendet, leider kein erfolg.
über bluetooth funktioniert das allerdings ohne probleme, allerdings ist die verbindung recht instabil.
habt ihr vielleicht eine ahnung?
vielen dank vorab, vg thomas
Dein Topic ist nicht vollständig, da davor noch ein „nicht sichtbares“ Zeichen ist.
Außerdem klappt MQTT auf einen eigenen Server nicht gut/stabuil, wenn die App noch läuft und mit dem SF connected ist.
Ein Sendeversuch aus dem MQTT-Explorer sollte dir eventuell helfen.
ich muss ja ehrlich gestehen, ich nutze nicht Symcon. Aber mit den Hinweisen von Ralf konnte ich das System komplett offline nehmen und es ist nun im Home Assistant integriert sogar mit der Möglichkeit das outputLimit im Home Assistant zu setzen. Nach dem bei mir die Variante solarflow-bt-manager.py -i -b Broker sehr instabil lief bin ich zu der Docker-Variante mit solarflow-control.py gewechselt und siehe da nach kurzer Zeit kommt im MQTT-Explorer auch die Topic so wie von Ralf beschrieben. Einziger Unterschied ist der Aufbau der Topic bei mir jetzt solarflow-hub/73bkTV/DEVICE_ID/telemetry
Da jetzt alle Daten vom Hub, meiner OpenDTU sowie ShellyPRO3EM im selben MQTT-Brocker landen konnte ich sogar in der OpenDTUonbattery die Daten der Akkus und des Shelly einbinden. Mir war aber am wichtigsten von HA aus das outputLimit steuern zu können, da ich im nächsten Schritt an einer Automatisierung in Richtung Nulleinspeisung arbeiten möchte. Dafür ist mir wichtig nicht nur das Limit des WR anpassen zu können sondern auch den output der Akkus.
1 „Gefällt mir“
ich habe das auch im mqtt-explorer so gesendet:
SF ist nicht mehr mit der app verbunden
leider kommen aber keine nachrichten auf den mqtt-server
Hat dein Broker einen User/PW?
habe ich bereits deaktiviert. und, wie gesagt, über BT werden werte gesendet
firewall ist auch nicht schuld
Also bei mir sah das Ergebnis so aus wie bei dir als ich bt-manager -d -w WLAN -b Broker gesendet hatte und selbst nach einem Tag kam nix.
ich hatte mich dann mit folgendem beschäftigt
und hab es auf dem gleichen rpi zero als docker laufen, auf welchem auch der mqtt läuft. sobald man wie in dem link beschrieben die config.ini auf seine werte anpasst und den docker container startet werden die Topics richtig angelegt und die Werte kommen.
Da wie in deinem Screen zusehen du auch HA nutzt. Hat es den Vorteil, dass die outputlimit Geschichte in HA veröffentlicht wird. Du bekommst dann unter der HA Topic einen Switch für Bypass vom Hub und auch einen Eintrag number dies ist im HA das Feld um outputlimit Werte zu setzen.
alternativ gibt es noch solarflow-topic-manager.py das script macht wenn es als Dienst läuft wohl das gleiche und erstellt alle Topics richtig, aber das hab ich nicht zum laufen bekommen.
danke zu allererst mal für eure hilfe. allerings habe ich eben das problem, dass keine werte vom hub an den broker geliefert werden:
Ach was bei mir noch ein Problem war ich musste erstmal solarflow-bt-manager.py -d -w fiktives WLAN -b Broker und danach nochmal mit meinem richtigen WLAN Daten
ändert leider auch nichts daran…
zudem kann ich nach dem disconnecten auch nicht mehr auf die cloud verbinden, außer mit neuerlichem hinzufügen einer NW-verbindung in der app
Hast du den Hub mal neugestartet?
Moin, du musst das topic mit dem „richtigen“ json Format senden
Topic:
iot/73bkTV/DEVICE_ID/properties/read
{
"properties": [
"getAll"
]
}
oder
{"properties": ["getAll"]}
hier im Forumbeitrag wurden die Gänsefüße nicht korrekt gesetzt.
Ach ja und deine app darf am besten auch nicht mehr im hintergrund geöffnet sein.
Gruß
Matten Matten
jedoch hab ich noch einige Datenpunkte womit ich noch nichts anfangen kann.
vielleicht könnt ihr mir weiter helfen.
Gruß Matten Matten
Nicht alle Topics werden regelmäßig aktualisiert.
Teilweise hat Reinhard (redchili) in seiner Statuspage passende Erklärungen
GitHub - reinhard-brandstaedter/solarflow-statuspage: A simple statuspage with live-data from Zendure's Solarflow Hub for those who do not want to use the App
Es gibt auch eine Gruppe im Discord
hubstate ist entsprechend dem state des Akkupacks
0 standby
1 laden
2 entladen
die Gänsefüße nicht korrekt gesetzt
Das passiert nur, wenn Codeblock nicht genutzt wird, dann gibt es hoch- und tiefgestellt ".
morgen,
hat leider alles nichts geholfen. es scheint, als könnte sich der hub im offline modus nicht auf den mqtt-broker verbinden - warum auch immer.
hub ist im wlan und auch pingbar.
Ich hatte größere Probleme mit abweichenden Ports und habe am Ende 1883 genutzt, damit funktioniert es bei mir.
bin bereits am standard-port 1883
Hallo @ralf - hast du dir auch schon die Zendure API angesehen? klick …das wäre ja eigentlich der „richtigere“ Weg an die Daten zu kommen. Auch wenn ich kein Freund der Cloud bin. Ich bin noch mit meiner Wahl des Speichers am schwanken und war aktuell eher bei der AC einspeise und entlade Lösung von dem anderen Thread hier im Forum. Jetzt habe ich aber den HUB2000 gesehen, der alle meine 6 Panels aufnehmen kann. Und da die alle am gleichen Ort liegen wäre und es in der Tat genau mein Gerät. Die Trickserei mit Gerät „Offline“ nehmen und dann wieder „Online“ für Updates und sowas, mag ich eigentlich nicht mehr. Das erscheint mir zu fragile um auf die nächste Jahre so betreiben zu wollen. Wenn aber, irgendwann in Zukunft ein Script oder Modul einer solchen API in der Luft liegen, wäre das eine coole Sache.
MfG.