Ecoflow PowerStream lokaal aansturen

[Valkske]

Hoi. Even korte intro, dit is een afsplitsing van het klustopic "Eenvoudige thuisaccu samenstellen". Daarin gebruiken we een regelbare micro-inverter, de ecoflow powerstream. Nu heb ik thuis 2 wifi netwerken, eentje daarvan is voor smartdevices en die is afgesloten van alle rest(inclusief internet). Voor alle duidelijkheid, ik wil hier geen discussie voeren over het waarom dit device geen internet toegang krijgt.

Die microinveter blijkt nu dus (bijna) onbruikbaar zonder internet. Ik had dit nog niet meegemaakt, de meeste devices met wifi functionaliteit die ik heb, hebben één of andere locale API (al dan niet officieel). Voordeel is dat het niet eens uitmaakt of het on-officieel is, gezien de devices ook geen firmware updates krijgen, blijven ze ook gewoon werken. (if it ain't broke...)

Toeval wou dat ik net een topic op homeassistant gelezen had van iemand die met een self-signed certificate en een eigen DNS server(pihole of adguard) met een DNS rewrite rule een ander toestel zo ver gekregen had om op zijn eigen MQTT server te connecteren en hiermee te communiceren.

Een avondje later was mijn Ecoflow powerstream geconnecteerd op mijn eigen MQTT server en begon die zijn status te posten in allerhande topics.

Ik heb een github repo gestart om daarin all mijn bevindingen te publiceren:
https://github.com/tomvd/local-powerstream

En nu komt mijn vraag. Ik ben nog op zoek naar mensen die dit interessant vinden om mee verder te zoeken, bij voorkeur kennis hebben van protobuf/rpc over mqtt en een Ecoflow powerstream in bezit hebben.
Data uitlezen is geen probleem, maar we zitten vast met versturen van het command om de output power de zetten. (zie ook dit topic: https://github.com/tomvd/local-powerstream/issues/4)
Dank!

[Valkske]

Dit topic mag wat mij betreft op slot. Ik kan de powerstream inmiddels lokaal aansturen. Developers van oa de ecoflow home assistant plugin zijn op de hoogte, hopelijk wordt deze lokale API ook snel in die plugin ondersteund.

[Septillion]

Misschien kan je er hier nog wat details over delen als naslag?

[turbotony]

Ik ben ook heel benieuwd hoe dit uiteindelijk gelukt is en waar ik daar meer info van kan vinden.

...zou heel graag al mijn ecoflow devices aansturen zonder afhankelijkheid van de Ecoflow cloud

[Valkske]

Zeker, hier zijn wat details als naslag:

De powerstream connecteert naar een mqtt server/broker op het adres mqtt-e.ecoflow.com. Dit adres kan je omleiden met een DNS rewrite (in bvb Adguard of pihole) naar je eigen mosquitto server.
In die mosquitto server zet je een self-signed certificate op (heb er een stapvoorstap readme hier gezet: https://github.com/tomvd/...rver/mosquitto/data/certs)
In je mosquitto conf zet je dan dit:
listener 8883
certfile /mosquitto/data/certs/certificate.pem
keyfile /mosquitto/data/certs/key.pem

En dan begint dat device protobuf commands te publishen in het /sys/.../thing/protobuf/upstream topic. De proto definities zijn gekend doordat de android app was gedecompiled, en dezelfde definities voor de communicatie van de server naar de app worden herbruikt voor de communicatie van de server naar het device, enkel de topics en sommige velden (zoals src en dst) zijn anders.
Wat hij in het upstream topic published zijn statusupdate over het device, en daarin vind je alles wat je nodig hebt, voltages, stroom,...

De belangrijkste parameter die je moet kunnen zetten in de powerstream is de basisterugleverstroom. En dat is bijna indentiek als het reeds gekende command van de app, enkel zetten we het hier in het topic /sys/.../thing/property/cmd
(als het device connect op de mosquitto server, kan je zien welke topics het subscribed en zo ben ik er achter gekomen)
(en om achter het command te komen moest ik als device zijnde connecteren op de server, daarvoor moest ik even client/user/paswoord ontfutselen van het device, maar dat is bij mqtt vrij makkelijk met een zogehete honeypot mqtt server)

Alles heb ik genoteerd op de readme van de github pagina, alsook alles van code en config heb ik gedeeld.

Veel batterijen van ecoflow sturen nog json door, in dat geval is het zelfs nog iets makkelijker om te lezen. Ecoflow is wel gekend om door firmware updates dingen meer te beveiligen (bvb sommige batterijen zijn al van json naar protobuf gewisseld), dus persoonlijk update ik de firmware van mijn powerstream nu niet meer.

[turbotony]

Zou dit ook met de Mosquito broker van Home Assistant moeten werken?

Ik heb op HA ook adguard draaien en daar een dns rewrite toegevoegd voor mqtt-e.ecoflow.com maar ik zie in mqtt explorer niets nieuws verschijnen.

[turbotony]

Ik gebruik nu EMQX in HA as mqtt broker en dat werkt goed. Ik zie nu de berichten van de ecoflow devices binnenkomen.

De volgende vraag is nu hoe ik de protobuf message aan kan maken in HA. Heb jij daar ervaring mee? Ik zie dat je java gebruikt om de protobuf message te maken, maar ik ben er nog niet uit hoe ik dat in HA zou kunnen doen. Tips zijn welkom!

Alvast bedankt! Het zou geweldig zijn als ik mijn powerstreams lokaal aan zou kunnen sturen....dan kunnen al mijn ecoflow devices van internet afgekoppeld worden :-)

[Valkske]

Ik heb de laatste versie van mijn java app gepushed naar de github repo. Aansturen en uitlezen van mijn powerstream doe ik nu volledig lokaal.
Wat betreft protobuf messages, die gaan niet rechtreeks naar HA kunnen vrees ik. Er moet iets van python, java of nodejs applicatie tussen zitten die de vertaling gaat doen.
Als je dit zonder zelf te moeten programmeren wil doen, kan je eventueel naar node-red kijken, die heeft een package node-red-contrib-protobuf die een encode/decode node toevoegd. In theorie moet het daar mee lukken, maar ik heb hier geen ervaring mee.

[turbotony]

Ik denk dat ik het liefst jouw psbridge wil gebruiken. Waar daar jij deze op? Zou dit op een Raspberry pi4b kunnen bijvoorbeeld?

[turbotony]

Het is me inmiddels gelukt om op een pi4 gradlew van jouw psbridge uit te voeren....maar weet nu nog niet hoe nu verder. Ik heb nog geen idee hoe ik die gradle app nu kan starten met de juiste parameters.

Ik vroeg me trouwens af of in het protobuf bericht ook specifieke powerstream info zit zoals serienummer of ip adres of iets dergelijks. Zo niet zou het dan niet mogelijk zijn om vooraf voor verschillende home base load waarden een bericht te maken? Dus bijvoorbeeld een bericht voor een base-load van 50W en een voor 100W etc.
Dan hoeft het protobuf bericht niet elke keer opnieuw gemaakt te worden maar kan afhankelijk van de op dat moment gewenste base-load een eerder gemaakt bericht gebruikt worden.....en die kan dan met een MqttPublish naar de powerstream gestuurd worden.

Zou dat werken denk je?

[Valkske]

Ik zou geen protobuf berichten op voorhand aanmaken, want er zit een tijdcode in en ik vermoed dat die gebruikt wordt om ofwel berichten weg te gooien die te oud zijn, of om de opeenvolging te controleren van berichten: de tijdcode van een nieuw bericht moet altijd hoger zijn dan de tijdcode van het vorige.
(los daarvan zie ik het nut niet, je kan bij elke aanvraag voor een andere base load een nieuw bericht aanmaken)

[turbotony]

Ik kom vooralsnog niet echt verder met de java en psbridge aanpak. Ik ben een .NET programmeur en heb te weinig ervaring met java ed. Ik heb wel alle benodigdheden op een Raspberry PI4 geinstalleerd maar het is me niet duidelijk hoe ik nu de psbridge app aan moet roepen met de juiste parameters laat staan hoe ik dit op mijn HA (ook PI4) werkend zou moeten krijgen. Misschien kun je daar nog iets over zeggen?

Hoe draai jij HA? En de psbridge app? Ik draai HA op een Raspberry PI4 en zou dus ideaal gezien van daaruit de psbridge app willen draaien die dan het bericht maakt en naar de powerstream stuurt. Ik zie bij psbridge in de "main\resources" het bestand "application-example.yml" staan...ik neem aan dat dat eigenlijk "application.yml" met daarin de juiste configuratie moet zijn om het te kunnen laten werken?

Is het nodig om permament de dns-rewrite in AdGuard te hebben staan of was dat alleen tijdelijk om eea af te kunnen vangen?

Het idee met de vooraf aangemaakte berichten had te maken met het feit dat ik wel vanuit .NET de protobuf berichten aan kan maken, maar dan wordt het live koppelen met HA wel erg lastig. Met NetDaemon zou ik C# moeten kunnen draaien in HA dus daar ga ik eens naar kijken....maar als je iets meer info hebt over hoe ik de psbridge aan de praat zou kunnen krijgen zou dat geweldig zijn! :-)

[Valkske]

Hey. Ik heb even mijn github repo geupdate en m'n container publiek gezet. Dat werkt namelijk het makkelijkst om te deployen.
Ik draai HA op een raspberry pi met docker en eigenlijk zowat alle applicaties in containers. De psbrige app idem maar in een andere (Ubuntu) vm, maar op een raspberry pi gaat dat hetzelfde zijn.

Je moet dus dit stukje in een docker compose zetten:

code:

  psbridge:
    image: ghcr.io/tomvd/psbridge:latest
    container_name: "psbridge"
    restart: always
    volumes:
      - /home/user/psbridge/application.yml:/home/app/application.yml
    environment:
      MICRONAUT_CONFIG_FILES: '/home/app/application.yml'

Je configureert dan nog de application.yml goed en dan docker compose up en dat zou moeten draaien.
Je kan hetzelfde ook gewoon met docker run command doen natuurlijk.
Die dns-rewrite zou ik gewoon laten staan ja.

[turbotony]

Bedankt hiervoor!

Ik denk alleen dat ik nu eerst HA "Supervised" moet installeren om de container te kunnen draaien. Ik heb Portainer geprobeerd maar die is deprecated en daarin krijg ik het ook niet werkend.

Als ik iets meer tijd heb ga ik de HA Supervised optie proberen.....

[turbotony]

Ik ben nu aan het testen met docker op Ubuntu op een Raspberry Pi4 maar jouw image lijkt alleen for amd64 te zijn en niet voor arm64:

psbridge The requested image's platform (linux/amd64) does not match the detected host platform (linux/arm64/v8) and no specific platform was requested

Is daar iets aan te doen of is nu mijn enige optie om docker (en dus ook HA) op een amd64 platform te installeren?

[Valkske]

Hey turbotony, je hebt gelijk, dat zal enkel op amd64 runnen.
Anderszijds, ik denk dat, gezien het programma op zich niet zo groot/complex is, een python port vrij snel te maken is. Ik denk zelfs als ik al de java code in claude AI zou plakken en vraag om er een python versie van te maken, dat dit bijna plug&play is. Ik wil dit wel eens proberen als ik tijd heb.

[turbotony]

Dat zou mooi zijn! :-)

...kan niet wachten om mijn powerstreams lokaal aan te sturen...

[BuurmanG]

Ik ben ook zeer geïnteresseerd!

[Wirehead]

Interessant topic. Ik heb recent de Stream AC gekocht, en zat ook met het idee te spelen om mqtt te onderscheppen. Top.

Ik merk ook op dat de Stream AC's ook op het lokale netwerk broadcasten voor sturing, misschien is de encoding hetzelfde.. leuk project .

[450SL]

Vannacht na 4:00 uur is volgens mij de Ecoflow communicatie met de powerstreams uit de lucht gegaan.. Mijn Powerstreams hangen vast en ik kan ze ook via bluetooth niet aansturen dus ik krijg ze niet meer aan de praat...waarmee mijn systeem helemaal plat ligt...Geweldige setup op deze manier, dus ik ben ook zeer geinteresseerd in een lokale aansturing vanuit HA... Helaas ben ik geen programmeur

[ Voor 6% gewijzigd door 450SL op 19-06-2025 08:58 ]

[RudolfR]

Mooi project!

Ik krijg het niet werkend, ik zie geen gegevens in HA.

Edit: Gelukt! Home Assistant MQTT add-on draait nu met het "ecoflow" certificaat. De broker uit de docker-compose heb ik dus buiten werking gesteld en de DNS rewrite naar m'n Home Assistant doorgezet.

Gelukkig maakte ik nog geen gebruik van secure MQTT, dus dit kan wel.

Het probleem was:

De devices wel, maar er komen geen statusberichten door.

Ik heb een VM met Portainer de stack gedeployed en ik zie de Powerstream verbinding maken:

1750406713: mosquitto version 2.0.21 starting
1750406713: Config loaded from /mosquitto/config/mosquitto.conf.
1750406713: Opening ipv4 listen socket on port 1883.
1750406713: Opening ipv6 listen socket on port 1883.
1750406713: Opening ipv4 listen socket on port 8883.
1750406713: Opening ipv6 listen socket on port 8883.
1750406713: mosquitto version 2.0.21 running
1750406713: New connection from 192.168.1.241:43303 on port 8883.
1750406713: New client connected from 192.168.1.241:43303 as mqtt-explorer-244e1606 (p2, c1, k60).
1750406715: New connection from 192.168.1.174:60774 on port 8883.
1750406716: New client connected from 192.168.1.174:60774 as HWxxxxxxxxxxxxxxxx (p5, c1, k120, u'device-xxxxxxxxxxxxxxxxxxxxxxxxxxxxx').

Ook maakt de PSBridge verbinding met Home Assistant, daar is een Powerstream1 bijgekomen (en een batterij)


Misschien dat deze fout er iets mee te maken heeft?

__ __ _ _

| \/ (_) ___ _ __ ___ _ __ __ _ _ _| |_

| |\/| | |/ __| '__/ _ \| '_ \ / _` | | | | __|

| | | | | (__| | | (_) | | | | (_| | |_| | |_

|_| |_|_|\___|_| \___/|_| |_|\__,_|\__,_|\__|

08:12:18.289 [main] INFO com.tomvd.services.EcoflowService - Starting MQTT bridge
08:12:18.828 [scheduled-executor-thread-1] ERROR i.m.s.DefaultTaskExceptionHandler - Error invoking scheduled task for bean [com.tomvd.services.EcoflowService@288f6cf] Cannot invoke "org.eclipse.paho.client.mqttv3.IMqttClient.isConnected()" because "this.haClient" is null
java.lang.NullPointerException: Cannot invoke "org.eclipse.paho.client.mqttv3.IMqttClient.isConnected()" because "this.haClient" is null
at com.tomvd.services.HomeAssistantService.isOnline(HomeAssistantService.java:310)
at com.tomvd.services.EcoflowService.executeHB(EcoflowService.java:135)
at com.tomvd.services.$EcoflowService$Definition$Exec.dispatch(Unknown Source)
at io.micronaut.context.AbstractExecutableMethodsDefinition$DispatchedExecutableMethod.invoke(AbstractExecutableMethodsDefinition.java:456)
at io.micronaut.inject.DelegatingExecutableMethod.invoke(DelegatingExecutableMethod.java:86)
at io.micronaut.context.bind.DefaultExecutableBeanContextBinder$ContextBoundExecutable.invoke(DefaultExecutableBeanContextBinder.java:152)
at io.micronaut.scheduling.processor.ScheduledMethodProcessor.lambda$scheduleTask$2(ScheduledMethodProcessor.java:160)
at java.base/java.util.concurrent.Executors$RunnableAdapter.call(Unknown Source)
at java.base/java.util.concurrent.FutureTask.runAndReset(Unknown Source)
at java.base/java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(Unknown Source)
at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown Source)
at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source)
at java.base/java.lang.Thread.run(Unknown Source)
08:12:19.631 [main] INFO io.micronaut.runtime.Micronaut - Startup completed in 2833ms. Server Running: http://871321cb2b71:8080

Bovenstaande fout heb ik soms, maar ook zonder fout werkt het niet.

Ik begrijp niet helemaal hoe het moet werken met maar '1 broker':
https://github.com/tomvd/...994a344194e73a6fdb77159d5

Ik heb er nl. 2, 1 voor de Ecoflow met een eigen certificaat, die bereikbaar is via 'mqtt-e.ecoflow.com'
met behulp van een DNS rewrite en de reguliere, de add-on in Home Assistant OS.

[ Voor 16% gewijzigd door RudolfR op 20-06-2025 18:17 ]

[joep03nl]

Ik heb het inmiddels ook werkend, echter ik zie in MQTT Explorer maar de eerste powerstream...

Mijn application.yml is:

code:

devices:
  powerstreams:
    - HW51ZEH49XXXXXXX
    - HW51ZEH4SXXXXXXX
    - HW51ZOH48XXXXXXX  
  batteries:
    - R621xxxxxxxxxxxx
mqtt:
  client:
    server-uri: tcp://192.168.30.139:1883
    user-name: mosquitto
    password: secret
    enable-discovery: true
smart:
  enabled: true
  meter-topic: smart/p1
  enabled-topic: smart/enabled
  charger-topic: smart/charger
  soc-topic: smart/soc
  max-power: 333

Weet iemand of ik ergens anders ook nog wat moet aanpassen om alle 3 de Powerstreams te zien?

Na een reboot van de PS's zijn ze wel zichtbaar allemaal

[ Voor 6% gewijzigd door joep03nl op 20-06-2025 21:24 ]

[Valkske]

Wat betreft de python versie van bovenstaand project, daar ben ik niet uitgeraakt. Ik zit vast op het genereren van de protobuf classes. Dus ik vrees dat ik daar niet mee ga kunnen helpen.
Ik hoop nog altijd dat er een vrijwilliger mijn code gaat gebruiken om hier een volwaardige HA plugin van te maken, maar voorlopig heb ik deze nog niet gezien (misschien dat na die recente uitval er wel schot in de zaak komt)

[RudolfR]

@Valkske
Ik ben geen Python-expert, maar het is me wel gelukt om de ecoflow.proto om te zetten voor Python.

code:

protoc --python_out=. ecoflow.proto

Dat levert een ecoflow_pb2.py op. Die je kunt importeren.

Dit komt er nu uit en dat klopt nog niet helemaal, maar het lijkt er wel op.

{
"deviceSn": "HWXXXXXXXXXXXX",
"llcTemp": 34.0,
"invErrorCode": 0,
"invWarningCode": 0,
"pv1InputVolt": 2.52,
"pv1InputWatts": 0,
"batSoc": 0,
"batTemp": 0.0,
"invOutputWatts": 0,
"invFreq": 4.99,
"supplyPriority": 0,
"invOnOff": 1,
"ratedPower": 800.0,
"batteryChargeRemain": 5999,
"batteryDischargeRemain": 5999,
"invTemp": 0.0,
"bat_error_code": 64,
"pv1_status": 4,
"pv2_status": 4,
"bat_status": 1,
"llc_status": 3,
"inv_status": 1,
"pv1_input_volt": 25.2,
"pv1_op_volt": 236.6,
"pv1_temp": 340,
"pv2_input_volt": 25.2,
"pv2_op_volt": 238.0,
"pv2_temp": 340,
"bat_input_volt": 0.7,
"bat_op_volt": 61.0,
"llc_op_volt": 436.2,
"llc_temp": 340,
"inv_op_volt": 232.8,
"inv_output_cur": 6.7,
"inv_freq": 499,
"install_country": 16724,
"upper_limit": 100,
"inv_on_off": 1,
"inv_brightness": 104,
"heartbeat_frequency": 2,
"rated_power": 8000,
"battery_charge_remain": 5999,
"battery_discharge_remain": 5999
}

code:

import paho.mqtt.client as mqtt
import time
import sys
import os
import json
from google.protobuf.message import DecodeError

# --- Import your generated protobuf file ---
import ecoflow_pb2

# --- Define CMD_ID to Message Type Mapping ---
# You'll need to populate this based on EcoFlow's protocol documentation or by
# observing cmd_id values for different messages.
# For example, from the Java code, we know CmdId 1 is InverterHeartbeat.
# This is crucial for correctly parsing pdata into the right message type.
CMD_ID_MESSAGE_MAP = {
    1: ecoflow_pb2.InverterHeartbeat,
    # Add other mappings as you discover them:
    # 10: ecoflow_pb2.EventRecordReport,
    # 20: ecoflow_pb2.RTCTimeGetAck,
    # etc.
}

class EcoflowMQTTClient:
    def __init__(self, broker_host, broker_port, client_id, username=None, password=None):
        self.broker_host = broker_host
        self.broker_port = broker_port
        self.client_id = client_id
        self.username = username
        self.password = password

        # Create a Paho MQTT client instance
        # Using protocol=mqtt.MQTTv5 is good practice
        self.client = mqtt.Client(client_id=self.client_id, protocol=mqtt.MQTTv5)

        # Register callback methods
        self.client.on_connect = self._on_connect
        self.client.on_message = self._on_message
        self.client.on_publish = self._on_publish
        self.client.on_subscribe = self._on_subscribe

        if self.username and self.password:
            self.client.username_pw_set(self.username, self.password)

        # --- MQTT Topics ---
        # Crucial: This must match the actual topic your EcoFlow inverter uses
        self.ecoflow_heartbeat_topic = "/sys/75/+/thing/protobuf/upstream" # Placeholder
        self.command_topic_prefix = "ecoflow/cmd/" # Example for sending commands

        self.is_connected = False

    def _on_connect(self, client, userdata, flags, rc, properties=None):
        """Callback for when the client connects to the MQTT broker."""
        if rc == 0:
            print("Connected to MQTT Broker!")
            self.is_connected = True
            # Subscribe to the heartbeat topic
            client.subscribe(self.ecoflow_heartbeat_topic)
            print(f"Subscribed to topic: {self.ecoflow_heartbeat_topic}")
        else:
            print(f"Failed to connect, return code {rc}\n")
            self.is_connected = False

    def _on_message(self, client, userdata, msg):
        print(f"Received message on topic: {msg.topic}")
        payload = msg.payload

        print(f"Payload Length: {len(payload)} bytes")
        print(f"Payload Hex: {payload.hex()}")

        try:
            # Step 1: Parse the incoming payload as the outer HeaderMessage
            header_message_obj = ecoflow_pb2.HeaderMessage()
            header_message_obj.ParseFromString(payload)

            #print("\n--- Decoded HeaderMessage (Outer) ---")
            #print(header_message_obj)

            # Step 2: Iterate through the headers to find the specific message(s)
            processed_any_message = False
            for header in header_message_obj.header: # 'header' is the field name in HeaderMessage
                print(f"  Processing header with CmdId: {header.cmd_id} and CmdFunc: {header.cmd_func}")
                print(f"  Header pdata length: {len(header.pdata)} bytes")
                # print(f"  Header pdata hex: {header.pdata.hex()}") # Uncomment for detailed pdata inspection

                # Determine the correct message type based on cmd_id
                message_type = CMD_ID_MESSAGE_MAP.get(header.cmd_id)

                if message_type:
                    try:
                        nested_message = message_type()
                        nested_message.ParseFromString(header.pdata)

                        print(f"\n--- Decoded Nested {message_type.__name__} Message ---")
                        print(nested_message)

                        # Call a specific processing function based on message type
                        if isinstance(nested_message, ecoflow_pb2.InverterHeartbeat):
                            self._process_heartbeat(nested_message, header.device_sn)
                        # Add elif blocks for other message types if you start processing them:
                        # elif isinstance(nested_message, ecoflow_pb2.EventRecordReport):
                        #     self._process_event_report(nested_message)
                        # elif isinstance(nested_message, ecoflow_pb2.RTCTimeGetAck):
                        #     self._process_rtc_time_ack(nested_message)

                        processed_any_message = True

                    except DecodeError as e:
                        print(f"  Nested Protobuf DecodeError for CmdId {header.cmd_id} ({message_type.__name__}): {e} - pdata likely malformed.")
                        print(f"  Problematic pdata (hex): {header.pdata.hex()}")
                    except Exception as e:
                        print(f"  An unexpected error occurred during nested message processing for CmdId {header.cmd_id}: {e}")
                        print(f"  pdata (hex): {header.pdata.hex()}")
                else:
                    #print(f"  Warning: Unknown CmdId {header.cmd_id}. Skipping pdata decoding for this header.")
                    if header.pdata: # Only print if there's actual pdata
                        print(f"  Unknown CmdId pdata (hex): {header.pdata.hex()}")

            if not processed_any_message:
                print("No recognized Protobuf messages found in the HeaderMessage.")

        except DecodeError as e:
            print(f"Protobuf DecodeError for HeaderMessage: {e} - Outer payload is likely malformed or not a valid HeaderMessage.")
            print(f"Problematic payload (hex): {payload.hex()}")
        except Exception as e:
            print(f"An unexpected error occurred during outer message processing: {e}")
            print(f"Payload (hex): {payload.hex()}")
        print("-" * 30)

    # Note: I've added a device_sn parameter here, as it's available in the Header.
    def _process_heartbeat(self, message: ecoflow_pb2.InverterHeartbeat, device_sn: str = "unknown"):
        """
        Processes the decoded InverterHeartbeat message and converts it to JSON.
        :param message: The decoded InverterHeartbeat protobuf message.
        :param device_sn: The serial number of the device from the Header.
        """
        inverter_data = {}
        inverter_data["deviceSn"] = device_sn # Add device serial number to JSON

        # Specific conversions and field mappings
        inverter_data["llcTemp"] = message.llc_temp / 10.0
        inverter_data["invErrorCode"] = message.inv_error_code
        inverter_data["invWarningCode"] = message.inv_warning_code
        inverter_data["pv1InputVolt"] = message.pv1_input_volt / 100.0
        inverter_data["pv1InputWatts"] = message.pv1_input_watts
        inverter_data["batSoc"] = message.bat_soc
        inverter_data["batTemp"] = message.bat_temp / 10.0
        inverter_data["invOutputWatts"] = message.inv_output_watts
        inverter_data["invFreq"] = message.inv_freq / 100.0
        inverter_data["supplyPriority"] = message.supply_priority
        inverter_data["invOnOff"] = message.inv_on_off
        inverter_data["ratedPower"] = message.rated_power / 10.0
        inverter_data["batteryChargeRemain"] = message.battery_charge_remain
        inverter_data["batteryDischargeRemain"] = message.battery_discharge_remain
        inverter_data["invTemp"] = message.inv_temp / 10.0 # Common scaling

        # This loop is a more robust way to capture ALL fields.
        # Be careful with its use if you need specific conversions for each field.
        # You might want to remove the individual assignments above if you rely solely on this loop
        # and ensure all conversions are handled within this loop's logic.
        for field_descriptor, value in message.ListFields():
            # Apply known conversions based on field name patterns or specific field_descriptor.name
            if field_descriptor.name.endswith("_volt") or field_descriptor.name.endswith("_cur"):
                inverter_data[field_descriptor.name] = value / 10.0
            elif field_descriptor.name.endswith("_temp"):
                inverter_data[field_descriptor.name] = value
            elif field_descriptor.name.endswith("_freq"):
                inverter_data[field_descriptor.name] = value
            elif field_descriptor.name == "bat_soc": # Specific handling for SoC percentage if needed
                inverter_data[field_descriptor.name] = value
            elif field_descriptor.name == "inv_output_watts": # Example for specific watts handling
                inverter_data[field_descriptor.name] = value
            else:
                # Default for other fields without specific conversions
                inverter_data[field_descriptor.name] = value


        json_output = json.dumps(inverter_data, indent=2)

        print("\n--- Converted to JSON ---")
        print(json_output)

    def _on_publish(self, client, userdata, mid):
        """Callback for when a message is successfully published."""
        print(f"Message published (mid={mid})")

    def _on_subscribe(self, client, userdata, mid, granted_qos, properties=None):
        """Callback for when a subscription is acknowledged by the broker."""
        print(f"Subscribed (mid={mid}), QoS: {granted_qos}")

    def connect(self):
        """Initiates connection to the MQTT broker."""
        print(f"Attempting to connect to MQTT broker at {self.broker_host}:{self.broker_port}...")
        try:
            self.client.connect(self.broker_host, self.broker_port, 60)
            # Start the non-blocking loop in a separate thread
            self.client.loop_start()
        except Exception as e:
            print(f"Error connecting to MQTT broker: {e}")
            self.is_connected = False

    def disconnect(self):
        """Disconnects from the MQTT broker."""
        print("Disconnecting from MQTT Broker...")
        self.client.loop_stop() # Stop the background loop
        self.client.disconnect()
        self.is_connected = False
        print("Disconnected.")

    def publish_command(self, device_serial, command_message_pb):
        """
        Publishes a protobuf command message to the inverter.
        :param device_serial: The serial number of your EcoFlow device.
        :param command_message_pb: An instantiated and populated protobuf command message object.
        """
        # You'll need to define your command message type in ecoflow.proto
        # and ensure your inverter listens on this topic.
        topic = f"{self.command_topic_prefix}{device_serial}"
        try:
            payload = command_message_pb.SerializeToString()
            self.client.publish(topic, payload)
            print(f"Published command to {topic}: {command_message_pb}")
        except Exception as e:
            print(f"Error publishing command: {e}")

# --- Main execution block ---
if __name__ == "__main__":
    # --- Configuration ---
    MQTT_BROKER_HOST = "192.168.1.49" # Replace with your MQTT broker's IP or hostname
    MQTT_BROKER_PORT = 1883
    MQTT_CLIENT_ID = "python_ecoflow_monitor"
    MQTT_USERNAME = "psbridge" # Your MQTT username, if required
    MQTT_PASSWORD = "psbridge" # Your MQTT password, if required

    # Instantiate your MQTT client
    ecoflow_monitor = EcoflowMQTTClient(
        MQTT_BROKER_HOST,
        MQTT_BROKER_PORT,
        MQTT_CLIENT_ID,
        username=MQTT_USERNAME,
        password=MQTT_PASSWORD
    )

    ecoflow_monitor.connect()

    time.sleep(5)

    print("EcoFlow MQTT Monitor started. Waiting for messages...")

    try:
        # Keep the main thread alive. The MQTT client runs in a background loop.
        # Here you could also add logic to send commands periodically or based on user input.
        while ecoflow_monitor.is_connected:
            time.sleep(1) # Sleep briefly to avoid busy-waiting

            # Example of sending a command (requires a command protobuf definition)
            # if time.time() % 60 < 1: # Send a command every minute (for demonstration)
            #     try:
            #         # Assume you have a CommandMessage in ecoflow_pb2.py
            #         # and you know your device's serial number
            #         command_msg = ecoflow_pb2.CommandMessage()
            #         command_msg.set_brightness = 5 # Example command
            #         ecoflow_monitor.publish_command("YOUR_DEVICE_SERIAL_NUMBER", command_msg)
            #     except AttributeError:
            #         print("CommandMessage protobuf definition not found or not used in this example.")
            #     time.sleep(5) # Avoid rapid command sending for demo

    except KeyboardInterrupt:
        print("Exiting application...")
    finally:
        ecoflow_monitor.disconnect()
        print("Application terminated.")

[turbotony]

Ik heb het nu bijna aan de praat op een AM64 device maar ik heb nog problemen met de juiste configuratie van de application.yml.

Als ik kijk naar jouw voorbeeld application-example.yml op github staat daarin:

code:

devices:
  powerstreams:
    - HW51xxxxxxxxxxxx
mqtt:
  ecoflow:
    url: ssl://192.168.0.111:8883
  home-assistant:
    url: tcp://192.168.0.113:1883
    username: mosquitto
    password: secret
  enable-discovery: true

Maar in een eerdere post hier van joep03nl staat:

code:

devices:
  powerstreams:
    - HW51ZEH49XXXXXXX
    - HW51ZEH4SXXXXXXX
    - HW51ZOH48XXXXXXX  
  batteries:
    - R621xxxxxxxxxxxx
mqtt:
  client:
    server-uri: tcp://192.168.30.139:1883
    user-name: mosquitto
    password: secret
    enable-discovery: true
smart:
  enabled: true
  meter-topic: smart/p1
  enabled-topic: smart/enabled
  charger-topic: smart/charger
  soc-topic: smart/soc
  max-power: 333

Hebben we het hier over dezelfde application.yml voor psbridge? Als ik de variant van github configureer krijg ik fouten in psbridge:

code:

13:33:04.159 [main] INFO  com.tomvd.services.EcoflowService - Starting MQTT bridge
13:33:04.183 [main] ERROR io.micronaut.runtime.Micronaut - Error starting Micronaut server: Cannot invoke "String.length()" because "this.input" is null

...als ik die van joep gebruik start psbridge wel...en zie ik dat MQTT in HA ook de entiteiten aanmaakt maar de status is van alle "onbekend".

En wat de configuratie van joep betreft: hoe weet psbridge wat het ip-adres is van de ecoflow devices? Of komen deze via mqtt binnen en moet ik wellicht gewoon geduld hebben en/of alles een keer resetten?

[RudolfR]

@turbotony

Het formaat van de config is onlangs veranderd, van 2 naar 1 broker.
mqtt.ecoflow en mqtt.home-assistant zijn achterhaald. mqtt.client zou genoeg moeten zijn.

Zoals in dit voorbeeld:
https://github.com/tomvd/.../psbridge/application.yml

[turbotony]

@RudolfR

Bedankt voor de info....ik was er inmiddels zelf ook achter gekomen :-S

psbridge lijkt nu goed te starten maar ik loop nog tegen de volgende twee zaken aan:

- ook al heb ik bij "Smart:" "Enabled: false" staan lukt het me niet de SetoutputWatts met de slider in te stellen en zie ik de "OutputWatts" ook steeds veranderen en de slider weer terugspringen. Geen idee waar deze waarden vandaan komen want ik doe nog niets met de smart topics.

- ik heb 2 powerstreams in de application.yml staan, maar de entiteiten in HA worden maar voor 1 PS aangemaakt. Ik heb deze aan laten maken door in HA een MQTT server toe te voegen die naar de Mosquitto server ip verwijst die ook door psbridge wordt gebruikt.....dan zie ik twee apparaten aangemaakt worden, maar er staan twee powerstreams en twee batteries in de application.yml

- hoe stuur ik de smart topics aan? Met MQTT Publish in een automation? Maar wat is dan de topic en het bericht? Of is dit per powerstream, maar hoe specificeer ik dan de PS?

Wat ik wil is niet gebruik maken van enige smart-mode, maar de outputWats van mijn twee powerstreams afzonderlijk in kunnen stellen.

Alle hulp is welkom!

[RudolfR]

@turbotony

smart-mode lijkt een automatische stand te zijn die automatisch het laden/ontladen regelt op basis van gegevens uit de P1 meter, die de gegevens deelt via MQTT (of misschien zet Home Assistant die neer via een mqtt.publish)
Inclusief aansturing van de batterij, en lage SoC bescherming (13%).

Ik heb maar 1 Powerstream; en de code lijkt hier ook maar 1 device aan te maken via discovery.

code:

            device.put("name", "PowerStream1");

Mogelijk is de ondersteuning voor meerdere apparaten nog onvolledig.

[ Voor 11% gewijzigd door RudolfR op 23-06-2025 19:59 ]

[Valkske]

turbotony, die ondersteuning is inderdaad onvolledig, ik kan wel eens kijken of ik het kan fixen, alleen heb ik zelf maar 1 powerstream om te testen

RudolfR, bedankt voor de hulp met de python code, ik zal eens kijken of ik daar iets werkend mee kan maken

[ Voor 30% gewijzigd door Valkske op 23-06-2025 21:16 ]

[turbotony]

Ik zag zojuist dat er in mijn ecoflow powerstream config mijn Shelly nog als smartmeter geconfigureerd was....dus daar zal de smart mode wel de belasting vandaan gehaald hebben!? (Ik heb deze nu verwijderd en zal morgen verder testen)

Maar hoe zet ik de smart mode uit? Ik wil handmatig de outputwatts instellen....

Zou heel mooi zijn als meerdere powerstreams ondersteunt kunnen worden! ....ik wil dat graag testen...

Ik krijg trouwens errors in psbridge als ik geen batteries geconfigureerd heb. Maar het lijkt erop dat Delta2 en Delta2Max niet ondersteunt worden?

[ Voor 50% gewijzigd door turbotony op 23-06-2025 22:53 ]

[RudolfR]

turbotony schreef op maandag 23 juni 2025 @ 22:46:

Maar hoe zet ik de smart mode uit? Ik wil handmatig de outputwatts instellen....

Ik zou denken dat "enabled: false" het beoogde effect heeft:

YAML:

smart:
  enabled: false
  meter-topic: smart/p1
  enabled-topic: smart/enabled
  charger-topic: smart/charger
  soc-topic: smart/soc
  max-power: 333

[turbotony]

RudolfR schreef op dinsdag 24 juni 2025 @ 07:12:
[...]


Ik zou denken dat "enabled: false" het beoogde effect heeft:

YAML:

smart:
  enabled: false
  meter-topic: smart/p1
  enabled-topic: smart/enabled
  charger-topic: smart/charger
  soc-topic: smart/soc
  max-power: 333

Dat dacht ik ook maar de outputwatts bleven dynamisch wijzigen en de setoutputwatts slider had geen effect.....zal het vandaag nog eens proberen.

[Valkske]

Heb de mogelijkheid voor meerdere powerstreams verder afgewerkt, zou moeten werken nu. Ik heb ook nog iets aangepast aan het uitzetten van die smart functie (dus die enabled: false zet) daar zat mogelijk nog een bug.
Ik zou zeggen doe een docker compose pull en docker compose up -d en je zou eens kunnen kijken of dat beter is.

[RudolfR]

@Valkske
Thanks! Draai inmiddels de nieuwe versie; te zien aan de naam van het device; nu een Serial Number van de Powerstream ipv Powerstream1.

Werkt lekker vlot; reageert binnen een aantal seconden op aansturing. Erg blij mee.

Smart mode lijkt me juist erg handig, maar dan hoop ik wel dat ik dat met een eigen batterij kan gebruiken, en bijv. ook kan configureren hoeveel laadvermogen erin gaat en tot hoever de batterij leeg mag.
Misschien kunnen dat (MQTT) settings worden?

Wat opvalt is dat aansturingen onder de 20W niets doen, mogelijk een meetbeperking van mijn BMS, maar dat herinner ik me niet van eerder?

Edit:
Ow, dat is misschien deze logica:

Java:

                int newPowerSetting = Math.max(0,data.currentPower()+gridPower);
                if (Math.abs(data.currentPower() - newPowerSetting) > 10) { // only publish a new powersetting if it changes > 10w
                    sl.getDeviceService().publishPowerSetting(newPowerSetting);
                }

[ Voor 23% gewijzigd door RudolfR op 25-06-2025 17:43 ]

[turbotony]

@Valkske

De nieuwe versie werkt bij mij ook perfect! Ik stuur mijn beide powerstreams nu lokaal aan.

Heel erg bedankt voor dit project....ik denk dat hier meer mensen blij mee gaan zijn.

Het enige dat bij mij nog niet werkt is de soc van de batterijen. Deze ondersteunt lijkt het nog niet meerdere batterijen maar ook geen Delta2 en Delta2Max!? Ik zie namelijk maar 1 battery entity: Battery1 waarbij de "State of charge" "onbekend" is.

Zie jij kans om ook de soc van een Delta2 en Delta2Max uit te lezen? Kan ik daar bij helpen?

Ik lees de betreffende SOC nu via bluetooth uit m.b.v. de "Ecoflow BLE" integratie, maar het zou mooi zijn als jouw integratie het zou ondersteunen....

[Wirehead]

Had even geprobeerd om de Stream AC's erop te koppelen, helaas..

-Stream AC connect op 8893
-Echter checken ze of het cert wel klopt..
mqtt-ecoflow | 1750958711: New connection from 192.168.100.141:64305 on port 8893.
mqtt-ecoflow | 1750958711: OpenSSL Error[0]: error:0A000418:SSL routines::tlsv1 alert unknown ca

Helaas pindakaas dus..

[RudolfR]

@Wirehead

Weet je zeker dat het niet de broker is die het certificaat van de cliënt afkeurt?

[Wirehead]

RudolfR schreef op donderdag 26 juni 2025 @ 19:38:
@Wirehead

Weet je zeker dat het niet de broker is die het certificaat van de cliënt afkeurt?

Geen idee, ik vermoed dat de MQTT server de client refusal toont.

Met MQTT-Explorer kan ik perfect connecteren (ignore cert) - maar ik vermoed dat de Stream AC (let op -niet- powerstream) een cert auth probeert te doen, en dus het cert checked.

Geen idee hoe ik Mosquitto zou kunnen configureren om "whatever" cert te aanvaarden.. Require_certificate is namelijk niet nodig..

edit: yep - error komt van de client, dus je kan niet zomaar meer "selfsigned" spoofen met de Stream AC, helaas...

[ Voor 8% gewijzigd door Wirehead op 26-06-2025 20:06 ]

[turbotony]

Gebruikt iemand van jullie de Mosquitto broker in Home Assistant OS?

Volgens mij ondersteunt die geen anonymous access meer en bij mij krijg ik dan een foutmelding dat de powerstream niet authorized is en dus niet kan verbinden.....maar daar kan ik natuurlijk geen username/password instellen.

Ik gebruik nu EMQX als mqtt broker maar zou liever Mosquitto gebruiken....

[RudolfR]

@turbotony

Jahoor, username/password instellen kan in de configuratie van add-on.

https://github.com/home-a...md#option-logins-optional

[turbotony]

RudolfR schreef op vrijdag 27 juni 2025 @ 09:36:
@turbotony

Jahoor, username/password instellen kan in de configuratie van add-on.

https://github.com/home-a...md#option-logins-optional

Ja, dat is de username/password voor psbridge -> mqtt broker.

Maar het probleem is dat de powerstreams niet met de Mosquitto broker kunnen verbinden:

2025-06-27 10:03:12: Client HW51xxxxxxx disconnected, not authorised.

Ik heb een certificate aangemaakt en in de Mosquitto config gezet.

Maar hoe draait Mosquitto bij jou? In Home Assistant OS of via een Docker container op een andere server?

[RudolfR]

@turbotony

In Home Assistant OS. Ik heb met de Honeypot gebruikt voor het wachtwoord.

Using a honeypot-mosquitto server (little python app you can find in the honeypot folder) it is possible to log credentials from any connecting client. You should see something like this:

2025-04-01 19:47:59,749 - MQTT TLS Honeypot started on port 8883
2025-04-01 19:48:01,303 - Connection from ('192.168.0.227', 50249)
2025-04-01 19:48:01,814 - SSL/TLS handshake successful with ('192.168.0.227', 50249)
2025-04-01 19:48:01,830 - data recvb"\x10h\x00\x04MQTT\x05\xc2\x00x\x00\x00\x10HW51012345678901\x00'device-01234567890123456789012345678901\x00 01234567890123456789012345678901"
2025-04-01 19:48:01,831 - Error parsing MQTT packet: index out of range

(I changed the credentials to fake ones) With the self-signed certificate, clientid HW51012345678901, userid device-01234567890123456789012345678901, password 01234567890123456789012345678901 you can actually connect to mqtt-e.ecoflow.com:8883 using mqtt explorer.

Username/password zijn belangrijk (clientid niet echt)

[turbotony]

@RudolfR

Ok, bedankt....ga ik dat binnenkort eens proberen......voorlopig draait het met EMQX....

[joep03nl]

Username/password kun je ook eenvoudig ophalen met een Powershell scriptje:

code:

# Configuration
$ACCESS_KEY = "your access key from Ecoflow Dev portal"
$SECRET_KEY = "your secret key from Ecoflow Dev portal"
$endpoint = "https://api-e.ecoflow.com" # May be different! Check the Ecoflow Dev Portal for yours.

function Get-Timestamp {
    return [int64](([datetime]::UtcNow - [datetime]'1970-01-01').TotalMilliseconds)
}

function Get-Nonce {
    return (Get-Random -Minimum 100000 -Maximum 999999).ToString()
}

function Get-Signature {
    param (
        [string]$access_key,
        [string]$secret_key,
        [string]$nonce,
        [string]$timestamp
    )
    
    # Sort parameters by ASCII value and concatenate them
    $strToSign = "accessKey=$access_key&nonce=$nonce&timestamp=$timestamp"
    
    # Create HMAC-SHA256 signature
    $hmac = New-Object System.Security.Cryptography.HMACSHA256
    $hmac.Key = [System.Text.Encoding]::UTF8.GetBytes($secret_key)
    $signBytes = $hmac.ComputeHash([System.Text.Encoding]::UTF8.GetBytes($strToSign))
    $signature = -join ($signBytes | ForEach-Object { "{0:x2}" -f $_ })
    
    return $signature
}

function Get-MqttConnectionData {
    $nonce = Get-Nonce
    $timestamp = Get-Timestamp
       
    # Generate the signature
    $sign = Get-Signature -access_key $ACCESS_KEY -secret_key $SECRET_KEY -nonce $nonce -timestamp $timestamp
    
    $headers = @{
        "accessKey" = $ACCESS_KEY
        "nonce" = $nonce
        "timestamp" = $timestamp
        "sign" = $sign
    }
    
    # URL for querying device data
    $url = "$endpoint/iot-open/sign/certification"
    
    # Send request
    return Invoke-RestMethod -Uri $url -Method Get -Headers $headers
}

$connectionData = Get-MqttConnectionData
$connectionData

en dan uitvoeren met:

code:

powershell -ExecutionPolicy Bypass .\script.ps1

Zie https://gist.github.com/lwsrbrts

[turbotony]

@joep03nl

Goeie tip! Ga ik proberen....

[turbotony]

@joep03nl

Bij mij lijkt het powershell script wel te werken maar niet het juiste account op te leveren;

Ik krijg een "certificateAccount" en "certificatePassword" terug, maar als ik die in Mosquitto als user configureer zijn de powerstreams not steeds "unauthorised"....

Heb jij op deze manier het benodigde account voor Mosquitto achterhaald?

[RudolfR]

Ik krijg uit het script ook andere gegevens dan via de honeypot methode.

[joep03nl]

turbotony schreef op maandag 30 juni 2025 @ 15:19:
@joep03nl
Bij mij lijkt het powershell script wel te werken maar niet het juiste account op te leveren;

Ik krijg een "certificateAccount" en "certificatePassword" terug, maar als ik die in Mosquitto als user configureer zijn de powerstreams not steeds "unauthorised"....

Klopt, je krijgt inderdaad iets anders terug (wat niet werkt). Wellicht een verouderde methode.
Mea culpa.

[turbotony]

Ik heb nu de accounts/passwords achterhaald mbv het honeypot script. Dit gaf op Ubuntu wel een "Error parsing MQTT packet: index out of range" maar op basis van "data recvb" kon ik toch de accounts met het password zien.

Dus alles draait nu zoals ik wil met de Mosquitto broker.

Nogmaals heel veel dank @Valkske voor het ontwikkelen van deze cloud-independant oplossing!

(kan ik nu verder met de integratie van Fireson voor de cloud onafhankelijke oplossing voor mijn Hyper2000....)

[RudolfR]

@Valkske

Is het mogelijk om psbridge iets robuuster te maken? Bij mij herstelt de verbinding niet na een restart van de broker. Ook prima als een (automatische) docker restart dat oplost, doordat de applicatie in de container er mee stopt.

[Valkske]

RudolfR, volgens mij als de applicatie crasht (als de broker er niet meer is), zou hij een auto-restart moeten doen en zo uiteindelijk reconnecten

[turbotony]

@Valkske

Is het mogelijk om psbridge aan te passen, zodat ook meerdere batteries gebruikt kunnen worden en ook de Delta2 en Delta2Max ondersteunt worden?

...zou mooi zijn als ik geen bluetooth (proxy) nodig heb om dit uit te lezen.

[Valkske]

Andere batterijen ondersteunen, zelfs moest ik er de tijd en motivatie voor hebben, gaat erg lastig worden, aangezien ik die zelf niet heb. Bij dit soort niet officiele oplossingen komt er veel trial and error bij kijken, met het device zelf dus.
Het doel van psbridge was ook niet om ecoflow batterijen te ondersteunen; zelf heb ik even een river pro2 gebruikt tot ik overgeschakeld ben op een grote accu van powerqueen die ik nu ook met een bluetooth proxy uitlees om de soc ervan op een mqtt topic te zetten (doe ik in HA) zodat psbridge dat in rekening brengt bij het laden/ontladen. (en omgekeerd lees ik dan weer het charger topic uit in home assistant om de smartplug van de charger aan/uit te zetten)

[turbotony]

Valkske schreef op donderdag 3 juli 2025 @ 09:07:
Andere batterijen ondersteunen, zelfs moest ik er de tijd en motivatie voor hebben, gaat erg lastig worden, aangezien ik die zelf niet heb. Bij dit soort niet officiele oplossingen komt er veel trial and error bij kijken, met het device zelf dus.
Het doel van psbridge was ook niet om ecoflow batterijen te ondersteunen; zelf heb ik even een river pro2 gebruikt tot ik overgeschakeld ben op een grote accu van powerqueen die ik nu ook met een bluetooth proxy uitlees om de soc ervan op een mqtt topic te zetten (doe ik in HA) zodat psbridge dat in rekening brengt bij het laden/ontladen. (en omgekeerd lees ik dan weer het charger topic uit in home assistant om de smartplug van de charger aan/uit te zetten)

Ok.....snap ik....dan lees ik de soc voorlopig via bluetooth uit en ga ik zelf wat knutselen met mqtt...