[Enphase] Envoy / IQ Gateway lokaal uitlezen voor domotica

[H4nsie]

antoin schreef op zondag 16 oktober 2022 @ 17:10:
[...]


Maar het moet idd beter worden geprogrammeerd om een beetje te blijven werken met alle Enphase authenticatie fratsen. De python code voor Home Assistant om het Token en de SessionID te krijgen met een username/password lijkt te werken, maar ik ben nog niet zo ver gekomen om die code in de plugin te krijgen.

Ik ga proberen mijn Envoy te (laten) updaten en ga dan met de plugin aan de slag! Dank voor het uitzoeken.

[FendtVario]

@H4nsie Kun je uitleggen wat type 243 betekent, is dat iets Domotics specifiek? Want de response op /api/v1/production/inverters geeft altijd devType 1. Mijn envoy draait nog op V5 en dan is de response (korte versie)

code:

[
  {
    "serialNumber": "482220*****",
    "lastReportDate": 1666024136,
    "devType": 1,
    "lastReportWatts": 1,
    "maxReportWatts": 232
  },
  { ... }
]

Op basis waarvan bepaal je dan de productie per dag per paneel? En komen jouw waarden overeen met wat Enphase rapporteert via hun app?

[johoo]

Ik heb een Envoy Metered S met firmware D5.0.62. De inverters zijn IQ7Amet 520-00082-r01-v04.27.04 en 540-000169-r01-v04.27.09.

Heb ik er voordeel bij om de laatste firmware te installeren?

[Pazo]

@johoo Als alles zonder problemen werkt is er geen noodzaak om nieuwe firmware te installeren. Kans is dat het vanzelf een keer gebeurt, of je moet het uitzetten in de installer toolkit app.

[FendtVario]

Ik ben nog niet aan de slag gegaan met Domoticz of Home Assistant maar wilde wel wat data uitlezen. Op zoek naar een snelle simpele oplossing ben ik uitgekomen bij Telegraf. Je kunt hiermee simpel HTTP request of commando's uitvoeren en uitkomst sla ik op in InfluxDB. Er komt niet veel data uit, total opbrengst van de PV, huidige opbrengst in watt van de PV en huidige opbrengst in watt per paneel/omvormer.

De uitkomst staat op Github. Dit draait nu op een Raspberry en is "goed genoeg" voor wat ik nu wil. Wellicht ook goed genoeg voor iemand hier.

[H4nsie]

FendtVario schreef op dinsdag 18 oktober 2022 @ 00:09:
@H4nsie Kun je uitleggen wat type 243 betekent, is dat iets Domotics specifiek? Want de response op /api/v1/production/inverters geeft altijd devType 1. Mijn envoy draait nog op V5 en dan is de response (korte versie)

code:

knip

Op basis waarvan bepaal je dan de productie per dag per paneel? En komen jouw waarden overeen met wat Enphase rapporteert via hun app?

Mijn Envoy draait ook nog op V5 (reden waarom ik de mijn plugin nog niet kan updaten naar v7-compatible).

Inderdaad bedoelde ik Domoticz specifiek, devicetype 243 is een 'uitgebreidere kWh teller', met (grafische) logging per dag/maand/jaar. Zie onder. Ja, waarden komen overeen met de app.

[mikkelnl]

@antoin @H4nsie Ik las jullie posts over de Domoticz plugin en de laatste firmware van Envoy en volg het graag. Ben helaas niet thuis genoeg in scripting om dezelfde aanpassingen te doen die @antoin heeft gedaan om het werkend te krijgen, dus ik wacht rustig af. :-)

[Ruisbak]

vhlemoine schreef op maandag 17 oktober 2022 @ 07:48:
[...]


python3

import requests
url = "https://envoy.local/api/v1/production/inverters"
k={'sessionid':'yoursessionid'}
data=requests.get(url, cookies=k, verify=False).json()

Zou je willen proberen een PR te maken voor de plugin van @H4nsie ?
Er staat al een issue open op zijn GitHub.
De D7.0.88 gebruikers zitten met smart te wachten.
Hans heeft al een ticket aangemaakt bij Enphase om zijn Envoy te laten updaten.
Waarvoor dank!

[Victorfvk]

@antoin I had to change the following line also to get it working:

< systemXML = requests.get('http://' + Parameters["Address"] + '/info.xml')

> systemXML = requests.get('http://' + Parameters["Address"] + '/info.xml', cookies=cookies, verify=False)

@H4nsie Is there a way to increase the update frequency?
Great plugin by the way, I made the changes of Antoin and it works!

[antoin]

Victorfvk schreef op zaterdag 22 oktober 2022 @ 16:13:
@antoin I had to change the following line also to get it working:

< systemXML = requests.get('http://' + Parameters["Address"] + '/info.xml')

> systemXML = requests.get('http://' + Parameters["Address"] + '/info.xml', cookies=cookies, verify=False)

@H4nsie Is there a way to increase the update frequency?
Great plugin by the way, I made the changes of Antoin and it works!

Ah, you were probably using version 1.0.3. I was still using version 1.0.2 that didn't have this line in it yet. But yes, every envoy request URL needs the SessionID cookie and the ignoring of the self signed certificate for firmware D7.

The frequency can probably be increased a bit, but an earlier post sugested it can only be increased to max 1 minute by provoking the envoy to re-read all inverters (basically do a reset). I don't know if we should do this by default, as it may probably also trigger something else. By default, the envoy reads all inverters every 5 minutes. Perhaps we can make it an option?

Currently working with H4nsie on a version 1.0.5 where the plugin lets you choose which firmware version you have, and where you can enter the SessionID in the Domoticz interface for Firmware D7 for people that know how to get the SessionID from a browser and change the expire date for the cookie. Probably needs some manual for some people.

And then in a later version we want to automate getting the Token and SessionID with the help of the enlighten username/password/serialnumber so you don't need to do the manual steps to get the SessionID. We could use some help with that.

[mikevosje]

Ik heb sinds midden september ook panelen liggen, maar krijg de totale productie waarde niet terug in mn home assistant. Als ik production.json open, zie ik dus bij alle lifetime of totale waarde 0.0 staan. Wel krijg ik de actuele opwekkingswaarde terug en kan ik zien hoeveel elk paneel opwekt. Iemand een idee wat er dan mis kan zijn of meer mensen last van?

In dit topic ook gezocht op lifetime, maar geen resultaten gevonden hoe dit op te lossen.

[antoin]

Ok, voor diegenen die niet zo thuis zijn hoe een SessionID cookie op te halen hierbij een korte uitleg hoe ik het heb gedaan.

Als eerste heb je een "Cookie editor" nodig. Dit is een kleine browser extensie die je in staat stelt om cookies te wijzigen. We moeten de cookie die de envoy ons geeft aanpassen omdat hij anders zou verlopen zodra we de browser sluiten.
Ik gebruik zelf Firefox, maar ik denk dat andere browsers vergelijkbare plugins hebben.
In Firefox, ga naar "Extra" -> "Add-ons en thema's", click links op "Extensies" en zoek naar "Cookie editor":



Installeer een cookie editor plugin, en je krijgt nu rechtsboven een plugin:




Nu gaan we lokaal inloggen op de envoy met firmware D7 met behulp van een token.
We gaan eerst het token ophalen bij https://entrez.enphaseenergy.com/
Log in met je Enlighten username en password:



Nu moet je je systeem en gateway selecteren:



Je vind de naam van je systeem onderaan je Enlighten app of website:




Als je je systeemnaam hebt ingevoerd kun je de gateway kiezen.
Klik nu op "Create access token"en je krijgt een token om lokaal op je envoy in te loggen.

Open nu een nieuwe browser tab en ga naar het IP adres van je envoy. Je ziet dan dit:





Copy en paste het Token in het veld, en klik op submit.
Als het inloggen is gelukt, dan heeft de envoy nu een cookie gezet in je browser om te zorgen dat je kunt rondklikken in je envoy zonder dat je wordt uitgelogd.

Nu kunnen we deze cookie bekijken en wijzigen.
Open nu de Cookie editor plugin, en kies voor "Manage all cookies":



Zoek nu linksboven naar de cookies die zijn gezet voor het IP adres van jouw envoy:




Je ziet nu je SessionID. Hoera, Gelukt. Maar we zijn nog niet klaar.
Klik op je SessionID. Je ziet nu rechtsonder dat hier de optie "IsSession" is aangevinkt.
Dat willen we niet. Het betekent dat de Cookie niet meer geldig is zodra de browser wordt gesloten. En we willen dat Domoticz het SessionID cookie nog even kan gebruiken ;-).
Haal daarom het vinkje bij "IsSession" weg, en vul een fictieve datum ver in de toekomst in tot wanneer je wil dat deze cookie geldig is.
Vergeet daarna niet om de cookie opnieuw op te slaan!!



Nu kun je de SessionID kopieren en gebruiken in Domoticz of ander python of shell script met curl door een cookie te zetten met cookies=sessionid='hetdoorjouzojuistgekopieerdeSessionID'

[Pazo]

Klinkt goed @antoin . Maar heeft cookie autodelete of het weigeren van cookies wat ik zoveel mogelijk doe daar invloed op? Waarschijnlijk werkt het dan niet?

[antoin]

Pazo schreef op zaterdag 22 oktober 2022 @ 19:14:
Klinkt goed @antoin . Maar heeft cookie autodelete of het weigeren van cookies wat ik zoveel mogelijk doe daar invloed op? Waarschijnlijk werkt het dan niet?

Ik ben ook geen fan van cookies :-)



Maar deze 1e van mijn eigen envoy wil ik wel bewaren.
Je kunt in Firefox een uitzondering maken dat hij de cookie van je envoy niet weggooit als de browser sluit:





Ik weet niet exact hoe het voor andere browsers werkt.
Ik denk dat de cookie wordt verwijderd door de browser zodra deze sluit waarna de envoy de SessionID weggooit. Dus als je dat voor deze cookie niet wil, dan moet je hem in je uitzonderingen zetten als je normaal gesproken alle cookies verwijdert bij het sluiten.

Ik ben geen expert in cookies. Maar mijn SessionID cookie werkt nu al bijna een week.

[antoin]

Ik heb vanochtend een interessant experiment uitgevoerd. Ik moest nog even wat klussen in de meterkast, dus de envoy moest van de stroom af.
Nadat het systeem opnieuw was opgestart was de SessionID natuurlijk niet meer geldig.
Opnieuw ingelogd op de envoy in een browser, met hetzelfde Token als voorheen dat nog wel geldig was, en ik kreeg een nieuw SessionID. Dezelfde procedure gevolgd als eerder beschreven, en het nieuwe SessionID weer ingevuld in de Domoticz plugin van H4nsie. Alles draait weer.

Maar een permanente oplossing moet dus worden om bij een reboot of authenticatie fout opnieuw een Token op te halen bij Enphase met je Enlighten username/password en met dat Token een nieuw SessionID cookie ophalen op je envoy om te gebruiken voor het uitlezen totdat de authenticatie weer verloopt.

[Ruisbak]

[b]antoin in "[Enphase] Haal meer uit je Envoy!"...

Maar een permanente oplossing moet dus worden om bij een reboot of authenticatie fout opnieuw een Token op te halen bij Enphase met je Enlighten username/password en met dat Token een nieuw SessionID cookie ophalen op je envoy om te gebruiken voor het uitlezen totdat de authenticatie weer verloopt.

De eerste stap die je noemt lijkt mij ongewenst i.v.m. security.
Je gebruikersnaam en wachtwoord beter niet in een script gebruiken.
Het is ook niet nodig want het Token dat je bij Enphase ophaalt heeft een geldigheidsduur van 1 jaar.
Beter het Token in het script gebruiken, om het SessionID cookie automatisch te genereren.

Kleine moeite om tegen het aflopen van het token, eens per jaar, zelf even een nieuwe aan te maken met je gebruikersnaam en wachtwoord.

[antoin]

Ruisbak schreef op zondag 23 oktober 2022 @ 23:26:
[...]


De eerste stap die je noemt lijkt mij ongewenst i.v.m. security.
Je gebruikersnaam en wachtwoord beter niet in een script gebruiken.

Ik ben het met je eens Ruisbak.
Hoewel de username/password niet in het script komt te staan maar als parameter wordt meegegeven in de UI, zal het wel in de Domoticz DB ergens worden opgeslagen. En ik weet niet of dat encrypted gebeurt. Hoe gaat dat met andere Domoticz scripts waarbij je een credential moet meegeven?

Bij HA moet je ook je username/password opgeven ;-(

[ Voor 4% gewijzigd door antoin op 24-10-2022 13:48 ]

[mielus]

2022-10-28: korte update: nieuwe inzichten zie commentaar van de config files.

Ik zie een hoop mensen hun best doen om met v7.x firmware en internet tokens hun rapportage aan de lan kant weer aan de praat te krijgen. Ik ben principieel paranoide over internet gekoppelde apparatuur: ook al werkt het nu, je bent afhankelijk van het beleid van enphase in de toekomst, wat als je voor een token geld moet gaat betalen? Of enphase failliet gaat? Of er nog onbekende exploits zijn.
Kortom ik wil v5.x firmware houden (en bv ook blokkeren dat mijn systeem op afstand uitgezet kan worden, er bogus firmware op de micro's gezet kan worden of andere nare dingen) Dat hoop ik te doen door de envoy alleen via nginx naar buiten te laten gaan, daar mag mbv een POST dan data worden geupload en verder niks.
Ik ben nog bezig dit te verbeteren, maar het werkt al aardig, ik snap nog niet veel van het ssl deel, dat blijft foutmeldingen geven zodra ik bv de http key_exchange location open zet, als er een nginx guru meer verstand heeft hoor ik het graag.
Met alleen http emu_reports/performance_report rapporteren de micro's netjes hun Watts, ook temperatuur AC voltage enzo (wat je aan de lan zijde niet kan uitlezen zo ver ik weet...) Als het lukt om de captures van nginx te ontcijferen, zou je daar in principe dus de temperatuur ed uit moeten kunnen halen. Verbeteringen hoor ik graag.
Misschien dat soms de andere locations ook nodig zijn, in elk geval 1x om de firmware versie van de micro's door te geven en het feit dat je ook CT spoelen hebt.

Enlighten is prima tevreden:

aanpassingen firewall:

code:

iptables -t nat -A PREROUTING -s $ENVOY/32 -p tcp -m tcp --dport 80 -j DNAT --to-destination $NGINX:$NGINX_HTTP
iptables -t nat -A PREROUTING -s $ENVOY/32 -p tcp -m tcp --dport 443 -j DNAT --to-destination $NGINX:$NGINX_HTTPS
iptables -t nat -A POSTROUTING -s $ENVOY/32 -d $EIGENLAN -j ACCEPT  #de envoy zit in een eigen vlan
iptables -t nat -A PREROUTING -s $ENVOY/32 -p icmp -j DNAT --to-destination $EIGENROUTER #die envoy pingt wat af, zo gaat dat ook niet naar buiten
#iptables -t nat -A POSTROUTING -s $ENVOY/32 -d 8.8.8.8 -j MASQUERADE
#iptables -t nat -A POSTROUTING -s $ENVOY/32 -j MASQUERADE  # mocht je wel internet volledig open willen zetten
iptables -t nat -A POSTROUTING -s $ENVOY/32 -j RETURN

code:

#nginx.conf
user nginx;
worker_processes auto;

error_log  /var/log/nginx/error.log notice;
pid        /var/run/nginx.pid;

events {}

http {
        include       /etc/nginx/mime.types;
        server_names_hash_bucket_size 128;  

    log_format post_logs escape=none
                '[$time_local] '
                '$request_method $scheme://$host$request_uri => $status '
                '$body_bytes_sent "$http_referer" '
                '"$http_user_agent" "$http_x_forwarded_for"';

    log_format hexdump escape=none '[$request_method $scheme://$host$request_uri][$request_body]';

    access_log  /var/log/nginx/access.log post_logs;
    access_log  /etc/nginx/hexdump.log hexdump;
    default_type application/octet-stream;
    sendfile on;

    client_max_body_size 128M;
    large_client_header_buffers 2 1k;

    include conf.d/*.conf;
}

code:

#conf.d/envoy.conf
    server {
        listen 18000;
        listen [::]:18000;

        server_name reports.enphaseenergy.com;


#-#        # enlighten stuurt commando's naar de envoy via een response body met status 200 als antwoord op een POST
#-#        # die body begint altijd met serienr van de envoy en daarna een versleuteld iets
#-#        # met deze sub_filter kan je de opdracht vanuit enlighten onklaar maken, maar de
#-#        # envoy gaat dan in "ik heb geen verbinding modus" stuurt nog wel rapporten, maar enlighten doet er niks mee
#-#        # TODO helpt een powercycle van de envoy?
#-#        # TODO zou er een manier zijn om de hele response body eraf te slopen?
#-#        sub_filter '1' ' ';
#-#        sub_filter '2' ' ';
#-#        sub_filter '3' ' ';
#-#        sub_filter '4' ' ';
#-#        sub_filter '5' ' ';
#-#        sub_filter '6' ' ';
#-#        sub_filter '7' ' ';
#-#        sub_filter '8' ' ';
#-#        sub_filter '9' ' ';
#-#        sub_filter '0' ' ';
#-#        sub_filter 'a' ' ';
#-#        sub_filter 'b' ' ';
#-#        sub_filter 'c' ' ';
#-#        sub_filter 'd' ' ';
#-#        sub_filter 'e' ' ';
#-#        sub_filter 'f' ' ';
#-#        sub_filter 'g' ' ';
#-#        sub_filter 'h' ' ';
#-#        sub_filter 'i' ' ';
#-#        sub_filter 'j' ' ';
#-#        sub_filter 'k' ' ';
#-#        sub_filter 'l' ' ';
#-#        sub_filter 'm' ' ';
#-#        sub_filter 'n' ' ';
#-#        sub_filter 'o' ' ';
#-#        sub_filter 'p' ' ';
#-#        sub_filter 'q' ' ';
#-#        sub_filter 'r' ' ';
#-#        sub_filter 's' ' ';
#-#        sub_filter 't' ' ';
#-#        sub_filter 'u' ' ';
#-#        sub_filter 'v' ' ';
#-#        sub_filter 'w' ' ';
#-#        sub_filter 'x' ' ';
#-#        sub_filter 'y' ' ';
#-#        sub_filter 'z' ' ';
#-#        sub_filter '.*' ' '; #bestaat er een wildcard?
#-#        sub_filter '  ' ' ';
#-#        #sub_filter_types "application/vnd.enphase.envoy";
#-#        sub_filter_types "*"; #match all
#-#        sub_filter_once off;
#-#
#-#        # TODO eigenlijk alleen de 200 OK moeten een rewrite krijgen, maar het lukt nog niet daar op te sturen
#-#        # zou alleen aanpassen van een 200 met een opdracht voor de envoy
#-#        # naar een 204 voldoende zijn om de enoy happy te houden en
#-#        # de opdracht vanuit enlighten te stoppen?
#-#        # dit zijn dus aanpassingen in de return header, uit enlighten dus
#-#        # ondanks deze response header aanpassingen, zie de envoy toch nog een corrupt gemaakte taak
#-#        # maar als het lukt echt helemaal de response body eraf te slopen houden we de envoy goed voor de gek denk ik
#-#        proxy_hide_header Status;             # weglaten origine status
#-#        add_header Status "204 No Content";   # we maken er 204 van, geen opdracht voor de envoy dus
#-#                                              # TODO blijkbaar is de status header niet de reponse header return code
#-#        proxy_hide_header Content-Type;
#-#        proxy_hide_header ETag;
#-#        add_header Content-Length "0";
#-#        proxy_hide_header Cache-Control;
#-#        add_header Cache-Control "no-cache";
#-#        proxy_hide_header Transfer-Encoding;

        location /emu_reports/performance_report {
            # dit geeft de standen: watt temp ac/dc volt van alle micro's door
            # ook de uitlezing van de CT spoelen
            # maar nog niet: firmware versie van micro's en dat CT spoelen zijn aangesloten
            limit_except POST {
              deny  all;
            }
            client_body_in_file_only on;            #expliceit de inhoud bewaren
            client_body_temp_path /etc/nginx/logs;  #lang leve docker volumes
            proxy_pass http://reports.enphaseenergy.com:80;
        }

        location /emu_reports/task_complete {
            #
            return 204;  # met een 204 blijft de envoy blij, enlighten krijg echter geen bevestiging en blijft dezelfde opdracht sturen
                         # zou vanuit enlighten gezien er maar 1 opdracht per keer worden uitgezet of meerdere tegelijk?
                         # als het maar 1 tegelijk is, is dat een mooie manier om de "disable power production" knop tegen te houden
                         # dit zou dus een goede manier kunnen zijn om nooit meer een nieuwe opdracht te krijgen vanuit enlighten
                         # maar telkens te blijven hangen in een reeds uitgevoerd opdracht zoals "check signal strenght" of "save report setting standard"
            #return 208;
            limit_except POST {
              deny  all;
            }
            proxy_redirect off;
            #proxy_pass http://reports.enphaseenergy.com:80;
        }

        location /emu_reports/inventory_report {
            # is dit naar aanleiding van een opdracht vanuit enlighten of zowieso periodiek?
            # kan lang worden geblockt zonder dat de envoy in paniek raakt
            #return 204;  #niet doorsturen, maar ok richting de envoy geven
            limit_except POST {
              deny  all;
            }
            proxy_redirect off;
            proxy_pass http://reports.enphaseenergy.com:80;
        }
       location /emu_reports/configuration_report {
            # is dit naar aanleiding van een opdracht vanuit enlighten of zowieso periodiek?
            # kan lang worden geblockt zonder dat de envoy in paniek raakt
            # return 204;  #niet doorsturen, maar ok richting de envoy geven
            limit_except POST {
              deny  all;
            }
            proxy_redirect off;
            proxy_pass http://reports.enphaseenergy.com:80;
        }

        location / {
            # geen andere locaties gezien tot nu toe....
            return 204; #no content # enlighten stuurt 204 als er geen taak voor de envoy is
                                    # en een 200 met een opdracht in de response body
            #return 406; #not acceptable
            #return 202; #accepted
            #return 200; #ok
            #return 400; #bad request
        }

    }

    server {
        listen 18000;
        listen [::]:18000;

        server_name home.enphaseenergy.com;
        #lijkt alleen maar gebruikt te worden voor internet connectiviteit test

        return 200; #altijd goed dus :-)
    }

Over ssl wordt een sleutel uitgewisseld, het verkeer over http wordt hier waarschijnlijk mee versleuteld

code:

#conf.d/reports.enphaseenergy.com.conf
    server {
        listen 18443 ssl;
        listen [::]:18443 ssl;

        server_name reports.enphaseenergy.com;

        #maak deze zelf aan met nginx-util add_ssl reports.enphaseenergy.com
        ssl_certificate '/etc/nginx/conf.d/reports.enphaseenergy.com.crt';
        ssl_certificate_key '/etc/nginx/conf.d/reports.enphaseenergy.com.key';

        ssl_session_cache 'shared:SSL:32k';
        ssl_session_timeout '64m';

        proxy_redirect              off;

        #https://serverfault.com/questions/583374/configure-nginx-as-reverse-proxy-with-upstream-ssl
        ssl_verify_client off;
        #ssl_protocols        SSLv3 TLSv1 TLSv1.1 TLSv1.2;
        #ssl_ciphers RC4:HIGH:!aNULL:!MD5;
        ssl_prefer_server_ciphers on;

        location /emu_reports/key_exchange {
            # het lijkt zo te zijn dat de envoy maar 1 ding doet over https
            # deze key is enkele dagen geldig
            # deze key is nodig om de andere rapporten aan te leveren
            # ik weet niet of er opdrachten in de respone vanuit enlighten kunnen zitten

            #return 202;
            limit_except POST {
              deny  all;
            }
            proxy_set_header Host $host;
            proxy_ssl_name $host;
            proxy_ssl_server_name on;
            proxy_ssl_session_reuse off;
            proxy_ssl_verify off;
            proxy_redirect off;

            #proxy_pass_request_headers off; #dit zijn de envoy headers, die zijn nodig

            # commando's van enlighten naar de envoy zitten mogelijk in de reponse van de POST
            # zouden we die kunnen blocken met http://nginx.org/en/docs/http/ngx_http_sub_module.html
            # sub_filter '<a href="http://127.0.0.1:8080/'  '<a href="https://$host/';
            # sub_filter '<img src="http://127.0.0.1:8080/' '<img src="https://$host/';
            # sub_filter_once on;

            proxy_pass https://reports.enphaseenergy.com:443;
        }

        location / {
          return 204; #tot nu toe heb ik geen andere locations gezien over https
        }
    }

[ Voor 41% gewijzigd door mielus op 28-10-2022 18:36 . Reden: update nalv nieuwe inzichten ]

[Ralphie]

Ik heb nog een Enphase systeem (installatie over een week of 10), maar ben me wel alvast aan het inlezen op hoe het eea uit te lezen.

Dit topic zit boordevol info en al deze info zette me wel aan het denken hoe secure het is. Het zal vast niet op de gemiddelde Tweaker van toepassing zijn, maar ik "vind" in Nederland 69 systemen die extern benaderbaar zijn en met de info uit dit topic kan ik met de password calculator in ieder systeem komen waarop ik geklikt heb.

Geen idee of het kwaad kan, maar kon klaarblijkelijk wel de Power Production remote disablen.

Misschien toch je externe IP even dubbelchecken of je er niet tussen staat?

https://www.shodan.io/sea...nphase+country%3A%22NL%22

[Richard_AFC]

Hoi,

Sinds afgelopen donderdag heb ik een Envoy S Metered hier hangen met een 9-tal zonnepanelen. Nadat de installateur klaar was had ik de gateway direct aan Home Assistant gehangen. Hierin viel mij direct op dat ik de totalen niet kon in zien:



Na wat speurwerk heb ik het idee dat je deze waardes (ongeveer alles waar 0Wh achter staat), pas kunt zien wanneer de stroomspoelen aangesloten zijn. Dat is bij mij thuis niet gedaan door de installateur. Heeft iemand hier de bevestiging op mijn vermoeden?

[mr.DJ95]

Richard_AFC schreef op maandag 24 oktober 2022 @ 16:23:
Hoi,

Sinds afgelopen donderdag heb ik een Envoy S Metered hier hangen met een 9-tal zonnepanelen. Nadat de installateur klaar was had ik de gateway direct aan Home Assistant gehangen. Hierin viel mij direct op dat ik de totalen niet kon in zien:

[Afbeelding]

Na wat speurwerk heb ik het idee dat je deze waardes (ongeveer alles waar 0Wh achter staat), pas kunt zien wanneer de stroomspoelen aangesloten zijn. Dat is bij mij thuis niet gedaan door de installateur. Heeft iemand hier de bevestiging op mijn vermoeden?

Ja dit is correct. Je mist de CT spoelen. Check het Enphase topic ook even hier uitgebreid in besproken. Achteraf kan, ben er over aan het twijfelen zou 2 uur kosten volgens de installateur. Als die had gevraagd of ik het wilde hebben bij het opstellen van de offerte had ik uiteraard ja gezegd.

Voor home assistant heb ik het nu anders opgelost in de utility meter met een Riemann Sum.

[Richard_AFC]

mr.DJ95 schreef op maandag 24 oktober 2022 @ 17:19:
[...]


Ja dit is correct. Je mist de CT spoelen. Check het Enphase topic ook even hier uitgebreid in besproken. Achteraf kan, ben er over aan het twijfelen zou 2 uur kosten volgens de installateur. Als die had gevraagd of ik het wilde hebben bij het opstellen van de offerte had ik uiteraard ja gezegd.

Voor home assistant heb ik het nu anders opgelost in de utility meter met een Riemann Sum.

Thanks! Nu vraag ik mij alleen af of dat wel accuraat gaat werken aangezien er bij mij nog een PV-verdeler tussen zit op zolder..

[Ruisbak]

mielus schreef op maandag 24 oktober 2022 @ 14:04:
Ik zie een hoop mensen hun best doen om met v7.x firmware en internet tokens hun rapportage aan de lan kant weer aan de praat te krijgen. Ik ben principieel paranoide over internet gekoppelde apparatuur: ook al werkt het nu, je bent afhankelijk van het beleid van enphase in de toekomst, wat als je voor een token geld moet gaat betalen? Of enphase failliet gaat? Of er nog onbekende exploits zijn.
Kortom ik wil v5.x firmware houden (en bv ook blokkeren dat mijn systeem op afstand uitgezet kan worden, er bogus firmware op de micro's gezet kan worden of andere nare dingen) Dat hoop ik te doen door de envoy alleen via nginx naar buiten te laten gaan, daar mag mbv een POST dan data worden geupload en verder niks.
...

Ik snap ff niet wat je nu aan het roeptoeteren bent.
Paranoide over internet gekoppelde apparatuur?
Jou envoy hangt net als die van mij aan het LAN. Daar is met de v7 firmware niets aan veranderd.
Over exploits gesproken, de v5 firmware die jij wil behouden is zo lek als wat, met de bekende password generator.

Dat is in v7 allemaal niet meer van toepassing. De security van v7 is beter op orde.
Nieuwe systemen worden nu eenmaal opgeleverd met de v7 firmware, dus ja wij zijn bezig dat aan onze Domoticz te hangen.
Allemaal in het LAN, dus niets gekoppeld aan het internet.

[RichieB]

Ralphie schreef op maandag 24 oktober 2022 @ 15:21:
[...]
Dit topic zit boordevol info en al deze info zette me wel aan het denken hoe secure het is. Het zal vast niet op de gemiddelde Tweaker van toepassing zijn, maar ik "vind" in Nederland 69 systemen die extern benaderbaar zijn en met de info uit dit topic kan ik met de password calculator in ieder systeem komen waarop ik geklikt heb.
[...]

Hoe veilig iets is heeft nogal te maken met hoe de gebruikers er mee om gaan. De Envoy is gemaakt voor een intern netwerk, niet om aan internet te hangen. Je zou dit kunnen melden bij het SOC / abuse desk van de provider. Die kan dan haar klanten weer inlichten.

[ Voor 6% gewijzigd door RichieB op 24-10-2022 18:47 ]

[RichieB]

Ruisbak schreef op maandag 24 oktober 2022 @ 18:37:
[...]
Paranoide over internet gekoppelde apparatuur?
Jou envoy hangt net als die van mij aan het LAN. Daar is met de v7 firmware niets aan veranderd.
[...]

Hé, spreek voor jezelf! Mijn Envoy hangt net als de rest van mijn andere IoT meuk in een eigen VLAN met strikte firewall regels zodat een eventuele aanvaller niet bij mijn belangrijke systemen kan, mocht er een IoT ding gehackt worden.

[Ruisbak]

RichieB schreef op maandag 24 oktober 2022 @ 18:50:
[...]

Hé, spreek voor jezelf! Mijn Envoy hangt net als de rest van mijn andere IoT meuk in een eigen VLAN met strikte firewall regels zodat een eventuele aanvaller niet bij mijn belangrijke systemen kan, mocht er een IoT ding gehackt worden.

Heel verstandig met die v5 firmware.
Voor de liefhebbers, nog een link naar een Tech Brief over de v7 update.

[ Voor 17% gewijzigd door Ruisbak op 24-10-2022 19:08 ]

[LinuZZ]

Ruisbak schreef op maandag 24 oktober 2022 @ 18:37:
[...]

Ik snap ff niet wat je nu aan het roeptoeteren bent.
Paranoide over internet gekoppelde apparatuur?
Jou envoy hangt net als die van mij aan het LAN. Daar is met de v7 firmware niets aan veranderd.
Over exploits gesproken, de v5 firmware die jij wil behouden is zo lek als wat, met de bekende password generator.

Dat is in v7 allemaal niet meer van toepassing. De security van v7 is beter op orde.
Nieuwe systemen worden nu eenmaal opgeleverd met de v7 firmware, dus ja wij zijn bezig dat aan onze Domoticz te hangen.
Allemaal in het LAN, dus niets gekoppeld aan het internet.

Persoonlijk vind ik roeptoeteren niet echt een positieve benadering. Wat @mielus heeft bereikt en wil delen is een succesvolle connectie met Enphase vanuit de envoy waarin de data die hij wil delen (opbrengst van de panelen) wordt geüpload zonder de eventuele nadelen. @mielus wil hierin dus de functionaliteit zoals aangeschaft behouden en geen nieuwe features die mogelijk ten koste gaan van andere features. Het is wat mij betreft niet ten onrechte paranoïde er zijn namelijk veel meer dan een handvol voorbeelden waar (met name IoT) leveranciers ineens features intrekken, verwijderen, of failliet gaan en een onwerkbaar product achterlaten.

[LinuZZ]

mielus schreef op maandag 24 oktober 2022 @ 14:04:
Ik zie een hoop mensen hun best doen om met v7.x firmware en internet tokens hun rapportage aan de lan kant weer aan de praat te krijgen. Ik ben principieel paranoide over internet gekoppelde apparatuur: ook al werkt het nu, je bent afhankelijk van het beleid van enphase in de toekomst, wat als je voor een token geld moet gaat betalen? Of enphase failliet gaat? Of er nog onbekende exploits zijn.
Kortom ik wil v5.x firmware houden (en bv ook blokkeren dat mijn systeem op afstand uitgezet kan worden, er bogus firmware op de micro's gezet kan worden of andere nare dingen) Dat hoop ik te doen door de envoy alleen via nginx naar buiten te laten gaan, daar mag mbv een POST dan data worden geupload en verder niks.
Ik ben nog bezig dit te verbeteren, maar het werkt al aardig, ik snap nog niet veel van het ssl deel, dat blijft foutmeldingen geven zodra ik bv de http key_exchange location open zet, als er een nginx guru meer verstand heeft hoor ik het graag.
Met alleen http emu_reports/performance_report rapporteren de micro's netjes hun Watts, ook temperatuur AC voltage enzo (wat je aan de lan zijde niet kan uitlezen zo ver ik weet...) Als het lukt om de captures van nginx te ontcijferen, zou je daar in principe dus de temperatuur ed uit moeten kunnen halen. Verbeteringen hoor ik graag.
Misschien dat soms de andere locations ook nodig zijn, in elk geval 1x om de firmware versie van de micro's door te geven en het feit dat je ook CT spoelen hebt.

Enlighten is prima tevreden:
[Afbeelding]
aanpassingen firewall:

code:

iptables -t nat -A PREROUTING -s $ENVOY/32 -p tcp -m tcp --dport 80 -j DNAT --to-destination $NGINX:$NGINX_HTTP
iptables -t nat -A PREROUTING -s $ENVOY/32 -p tcp -m tcp --dport 443 -j DNAT --to-destination $NGINX:$NGINX_HTTPS
iptables -t nat -A POSTROUTING -s $ENVOY/32 -d $EIGENLAN -j ACCEPT  #de envoy zit in een eigen vlan
iptables -t nat -A POSTROUTING -s $ENVOY/32 -d 8.8.8.8 -j MASQUERADE
#iptables -t nat -A POSTROUTING -s $ENVOY/32 -j MASQUERADE  # mocht je wel internet volledig open willen zetten
iptables -t nat -A POSTROUTING -s $ENVOY/32 -j RETURN

code:

#nginx.conf
user nginx;
worker_processes auto;

error_log  /var/log/nginx/error.log notice;
pid        /var/run/nginx.pid;

events {}

http {
        include       /etc/nginx/mime.types;
        server_names_hash_bucket_size 128;  

    log_format post_logs escape=none
                '[$time_local] '
                '$request_method $scheme://$host$request_uri => $status '
                '$body_bytes_sent "$http_referer" '
                '"$http_user_agent" "$http_x_forwarded_for"';

    log_format hexdump escape=none '[$request_method $scheme://$host$request_uri][$request_body]';

    access_log  /var/log/nginx/access.log post_logs;
    access_log  /etc/nginx/hexdump.log hexdump;
    default_type application/octet-stream;
    sendfile on;

    client_max_body_size 128M;
    large_client_header_buffers 2 1k;

    include conf.d/*.conf;
}

code:

#conf.d/envoy.conf
    server {
        listen 18000;
        listen [::]:18000;

        server_name reports.enphaseenergy.com;

        location /emu_reports/performance_report {
            # dit geeft de standen: watt temp ac/dc volt van alle micro's door
            # maar nog niet: firmware versie van micro's en CT spoelen
            limit_except POST {
              deny  all;
            }
            proxy_pass http://reports.enphaseenergy.com:80;
        }

        location /emu_reports/task_complete {
            # zodra ik dit aanzet gaat er een poging plaats vinden om dingen over https te doen
            return 208;
            limit_except POST {
              deny  all;
            }
            #proxy_pass https://reports.enphaseenergy.com:80;
        }

        location /emu_reports/inventory_report {
            # na het aanzetten van de envoy, een post lijkt me geen kwaad kunnen
            return 208;
            limit_except POST {
              deny  all;
            }
            #proxy_pass http://reports.enphaseenergy.com:80;
        }

        location /emu_reports/configuration_report {
            # na het aanzetten van de envoy, een post lijkt me geen kwaad kunnen
            return 208;
            limit_except POST {
              deny  all;
            }
            #proxy_pass http://reports.enphaseenergy.com:80;
        }

        location / {
            return 204;
        }
    }

    server {
        listen 18000;
        listen [::]:18000;

        server_name home.enphaseenergy.com;
        #lijkt alleen maar gebruikt te worden voor internet connectiviteit test

        return 200; #altijd goed dus :-)
    }

Het ssl deel heb ik nog niet goed aan de praat, maar lijkt nu nog niet uit te maken

code:

#conf.d/reports.enphaseenergy.com.conf
    server {
        listen 18443 ssl;
        listen [::]:18443 ssl;

        server_name reports.enphaseenergy.com;

        #maak deze zelf aan met nginx-util add_ssl reports.enphaseenergy.com
        ssl_certificate '/etc/nginx/conf.d/reports.enphaseenergy.com.crt';
        ssl_certificate_key '/etc/nginx/conf.d/reports.enphaseenergy.com.key';
        ssl_session_cache 'shared:SSL:32k';
        ssl_session_timeout '64m';

        proxy_redirect              off;

        #https://serverfault.com/questions/583374/configure-nginx-as-reverse-proxy-with-upstream-ssl
        ssl_verify_client off;
        #ssl_protocols        SSLv3 TLSv1 TLSv1.1 TLSv1.2;
        #ssl_ciphers RC4:HIGH:!aNULL:!MD5;
        ssl_prefer_server_ciphers on;

        location /emu_reports/performance_report {
            limit_except POST {
              deny  all;
            }
            proxy_set_header Host $host;
            proxy_ssl_name $host;
            proxy_ssl_server_name on;
            proxy_ssl_session_reuse off;
            proxy_ssl_verify off;
            proxy_pass https://reports.enphaseenergy.com:443;
        }

        location /emu_reports/key_exchange {
            return 208;
            limit_except POST {
              deny  all;
            }
            proxy_set_header Host $host;
            proxy_ssl_name $host;
            proxy_ssl_server_name on;
            proxy_ssl_session_reuse off;
            proxy_ssl_verify off;
            #proxy_pass https://reports.enphaseenergy.com:443;
        }

        location /emu_reports/task_complete {
            return 208;
            limit_except POST {
              deny  all;
            }
            proxy_set_header Host $host;
            proxy_ssl_name $host;
            proxy_ssl_server_name on;
            proxy_ssl_session_reuse off;
            proxy_ssl_verify off;
            #proxy_pass https://reports.enphaseenergy.com:443;
        }

        location / {
          return 204;
        }
    }

Zover ik weet kun je niet "tussen" een ssl verbinding in gaan zitten met een reverse proxy zonder de private key. Dat is nou net het idee van de encrypted verbinding . de POST commands filteren van de rest van de communicatie zal dus ook niet lukken over https. Verder leuk om te zien dit. Ik zal het zelf niet gaan doen maar begrijp je zeker

[AmNL]

Sinds niet al te lange tijd ligt bij mij ook een systeem met Enpase micro omvormers en envoy. Omdat ofwel Enphase ofwel de leverancier niet perse snel is, is mijn systeem nog niet geactiveerd en zit ik dus lekker te rommelen om het zelf uit te lezen.

Er zijn nu twee zaken die mij opvallen;
1). Als ik /api/v1/production/inverters benader geven die 's morgens tot zeker een uur of elf per inverter een opbrengst aan van 0 Watt, ondanks dat de envoy aangeeft dat alle 16 panelen produceren en production.json gewoon een waarde geeft op wNow. Hoe komt dit? Zou dit opgelost worden wanneer de boel geactiveerd wordt?
2). Ik heb een python scriptje op mijn raspberry draaien die iedere minuut via de production.json de wNow uitleest en in een sql database gooit, echter (zoals anderen in dit topic ook aangeven) update hij niet exact regelmatig ('s morgens wel per minuut, maar later eens per 5 minuten). Ik probeer dit te ondervangen door installer/pcu_comm_check aan te spreken (geprobeerd eens per minuut, per 30 seconden of iedere 10 seconden), maar dit verandert niets. Iemand betere ideeën?

[RichieB]

@AmNL Gewoon rustig wachten tot je leverancier de tijd heeft gehad om je systeem bij Enphase aan te melden..

[sir_knudde]

@AmNL Volgens mij moet het systeem daarna tenminste een dag zonder foutmeldingen hebben gedraaid, voordat je mail van enphase krijgt.

[mikkelnl]

AmNL schreef op dinsdag 25 oktober 2022 @ 11:08:
2). Ik heb een python scriptje op mijn raspberry draaien die iedere minuut via de production.json de wNow uitleest en in een sql database gooit, echter (zoals anderen in dit topic ook aangeven) update hij niet exact regelmatig ('s morgens wel per minuut, maar later eens per 5 minuten). Ik probeer dit te ondervangen door installer/pcu_comm_check aan te spreken (geprobeerd eens per minuut, per 30 seconden of iedere 10 seconden), maar dit verandert niets. Iemand betere ideeën?

[Afbeelding]

Denk inderdaad dat het een kwestie van geduld is...

Ben wel benieuwd naar je Python scriptje! Mij lukte zoiets niet. En op welke firmware draai je?

[AmNL]

mikkelnl schreef op woensdag 26 oktober 2022 @ 05:55:
[...]

Denk inderdaad dat het een kwestie van geduld is...

Ben wel benieuwd naar je Python scriptje! Mij lukte zoiets niet. En op welke firmware draai je?

Ik draai op D5.0.62. Heb hem even gauw voor je op Github gegooid. Ik heb mezelf slechts wat leren python kloppen, dus bij voorbaat excuus als het niet clean is. (Bijvoorbeeld sql password hardcoden in het pythonscript is wel aardig nono denk ik ) Heb diverse andere scripts (die niet met sql en dergelijke werken) gebruikt als uitgangspunten.

GitHub

Even je eigen gegevens inkloppen in regel 12, 37, 38, 39, 49 and 57 (dat kan cleaner, ik weet het)

Edit; Oh ja, het script zet je database verder niet op of zo. Mijn database heeft een table genaamd Production met de volgende eigenschappen:

[ Voor 19% gewijzigd door AmNL op 26-10-2022 07:55 ]

[mikkelnl]

AmNL schreef op woensdag 26 oktober 2022 @ 07:45:
[...]

Ik draai op D5.0.62. Heb hem even gauw voor je op Github gegooid. Ik heb mezelf slechts wat leren python kloppen, dus bij voorbaat excuus als het niet clean is. (Bijvoorbeeld sql password hardcoden in het pythonscript is wel aardig nono denk ik ) Heb diverse andere scripts (die niet met sql en dergelijke werken) gebruikt als uitgangspunten.

GitHub

Even je eigen gegevens inkloppen in regel 12, 37, 38, 39, 49 and 57 (dat kan cleaner, ik weet het)

Edit; Oh ja, het script zet je database verder niet op of zo. Mijn database heeft een table genaamd Production met de volgende eigenschappen:
[Afbeelding]

Super! Ik vrees alleen dat de nieuwe firmware dit niet meer toelaat Moet ff tijd vinden en dan zal ik een poging wagen :-)

[AmNL]

mikkelnl schreef op woensdag 26 oktober 2022 @ 10:24:
[...]

Super! Ik vrees alleen dat de nieuwe firmware dit niet meer toelaat Moet ff tijd vinden en dan zal ik een poging wagen :-)

Dat zou inderdaad best kunnen maar dan hobby ik er de kunststukjes van een ander wel weer in. Zijn zat mensen mee bezig geloof ik (niet alleen hier).

[mielus]

Ruisbak schreef op maandag 24 oktober 2022 @ 18:37:
[...]

Ik snap ff niet wat je nu aan het roeptoeteren bent.

Ik zal een poging doen het toe te lichten, @LinuZZ heeft het al aardig door.

Paranoide over internet gekoppelde apparatuur?
Jou envoy hangt net als die van mij aan het LAN. Daar is met de v7 firmware niets aan veranderd.

Klopt, maar er wordt een tunnel gemaakt vanuit Enphase naar jouw v5/v7 envoy
Je moet dan vertrouwen op de interne veiligheid van Enphase, ik doe dat liever niet.
Ook ben ik paranoïde over wat Enphase in de toekomst gaat doen. Met v7 heb je een token nodig van Enphase om gegevens aan je LAN kant uit te lezen. Bij v5 heb je dit probleem niet. Er wordt dus een afhankelijkheid gemaakt van Enphase, als ze geld gaan vragen voor die token of failliet gaan heb je dus een probleem met je v7 firmware, met v5 niet.
Volgens mij is er ook nog geen oplossing voor de stream/meter api (Is deze geschrapt in v7?)
En ik vind het jammer dat je aan de LAN kant niet alles van je micro's kan uitlezen, temp AC/DC voltage enzo v7 gaat dat ook niet verhelpen. Wellicht een decode van de rapportage die ik met nginx afvang wel.

Over exploits gesproken, de v5 firmware die jij wil behouden is zo lek als wat, met de bekende password generator.

Het is echt slecht dat het installer wachtwoord blijkbaar niet aangepast kan worden onder v5, misschien heeft Enphase hun zaakjes beter op orde in v7 maar:
Mijn v5 envoy zit in een eigen vlan, kan geen tunnel maken met Enphase en is dus niet bereikbaar vanaf het internet door niemand (tenzij iemand mijn router/firewall weet te hacken.)
Je kan ook de firewall helemaal dicht zetten, maar dan ook geen rapportage in enlighten.
Ik wilde mensen die nu nog v5 hebben en net als mij dachten een mogelijke oplossing aanreiken: behoud van alle LAN uitleesmogelijkheden zonder token, nog steeds all info in enlighten, geen onverwachte firmware push en naar mijn idee meer secure.

Dat is in v7 allemaal niet meer van toepassing. De security van v7 is beter op orde.
Nieuwe systemen worden nu eenmaal opgeleverd met de v7 firmware

Nog steeds denk ik dat mijn oplossing meer secure is: nl. geen tunnel naar mijn envoy
Nieuwe systemen kunnen wellicht nu nog een rollback krijgen naar v5, ik vermoed dat over een tijdje het beleid is: "doen we niet, unsupported"

dus ja wij zijn bezig dat aan onze Domoticz te hangen.
Allemaal in het LAN, dus niets gekoppeld aan het internet.

Men vergist zich in het "niets gekoppeld aan het internet" dat wilde ik even duidelijk maken.
Zonder internet geen vers token en een tunnel vanuit Enphase naar mijn eigen envoy wat ik als een security risk ervaar, v5 v7 maakt niet uit.
Allemaal prima als men dat niet erg vind, ik ben meer paranoïde.
Mijn doelstelling is dus: Vanuit enlighten manager deze knop onbruikbaar maken (ook evt met v7 firmware):
Maar mijn micro's en CT spoelen rapporteren nog steeds hun meetgegevens.

In elk geval ben ik er achter dat alleen location /emu_reports/performance_report doorlaten en 208's geven op de andere locaties niet voldoende is, na een paar dagen vind de envoy dat hij niet meer verbonden is en stopt met data verzenden.
Uitzetten/aanzetten van envoy helpt, maar dat is niet echt een fijne oplossing, na een paar dagen stoppen de uploads weer.
Maar misschien moet ik niet 208 terug geven voor de andere locaties, maar gewoon 200
Of nog net iets meer doorlaten. Ik heb nu ook location /emu_reports/inventory_report en location /emu_reports/configuration_report een pass gegeven. Ik ga weer wat kleine tweaks proberen.

In elk geval heb ik nog een kleine typo ontdekt:

code:

 server {
        listen 18000;
        listen [::]:18000;

        server_name reports.enphaseenergy.com;

...
...
...
        location /emu_reports/task_complete {
            # zodra ik dit aanzet gaat er een poging plaats vinden om dingen over https te doen: oorzaak = typo
            #return 200;
            #return 208;
            limit_except POST {
              deny  all;
            }
            proxy_pass http://reports.enphaseenergy.com:80;  #oeps: ik had hier https staan!
        }
..
..
..

[ Voor 0% gewijzigd door mielus op 26-10-2022 21:10 . Reden: typo ]

[berend_]

mielus schreef op woensdag 26 oktober 2022 @ 14:02:
[...]
Mijn v5 envoy zit in een eigen vlan, kan geen tunnel maken met Enphase en is dus niet bereikbaar vanaf het internet door niemand (tenzij iemand mijn router/firewall weet te hacken.)
Je kan ook de firewall helemaal dicht zetten, maar dan ook geen rapportage in enlighten.
Ik wilde mensen die nu nog v5 hebben en net als mij dachten een mogelijke oplossing aanreiken: behoud van alle LAN uitleesmogelijkheden zonder token, nog steeds all info in enlighten, geen onverwachte firmware push en naar mijn idee meer secure.

Goed man, ik heb ook mijn Envoy in een vlan en geblokkeerd in mijn firewall.
Nu lees ik alles lokaal uit (helaas geen voltage) en heb niet echt behoefte om het te laten uploaden in Enlighten. Maar als dit uploaden ook echt alleen zonder onverwachte poespas kan dan is het misschien wel interessant. Al is het alleen al voor het idee van de geldigheid van de garantie

[FendtVario]

AmNL schreef op dinsdag 25 oktober 2022 @ 11:08:
...
2). Ik heb een python scriptje op mijn raspberry draaien die iedere minuut via de production.json de wNow uitleest en in een sql database gooit, echter (zoals anderen in dit topic ook aangeven) update hij niet exact regelmatig ('s morgens wel per minuut, maar later eens per 5 minuten). Ik probeer dit te ondervangen door installer/pcu_comm_check aan te spreken (geprobeerd eens per minuut, per 30 seconden of iedere 10 seconden), maar dit verandert niets. Iemand betere ideeën?

Ik herken dit gedrag ja. Er is ook nog een /ivp/peb/newscan endpoint. Heb dit nog niet geprobeerd maar misschien helpt dat. Die wordt regelmatig door de webpagina die op de Envoy draait aangeroepen.

Mocht je niet willen coderen; hier nog een (schaamteloze) promo van mijn oplossing met Telegraf om de Envoy uit te lezen, alleen v5.

[FendtVario]

@mielus interessante aanpak. Lijkt me redelijk arbeidsintensief, maar die extra data uit de micro-omvormers zou wel mooi zijn om lokaal te hebben. Die krijg je niet uit de Envoy API inderdaad.

Je schreef dat je het SSL deel nog niet werkt. Ik zie dat je endpoints als /emu_reports/performance_report wel voor HTTP als HTTPS hebt gedefinieerd. Gebruikt Envoy dan ook HTTP?

Volgens mij is de enige manier om tussen een SSL verbinding te gaan zitten als diegene die de verbinding maakt (de Envoy dus) niet de attributen in het certificaat of de certificaat keten valideert. Maar ik zie dat ze in dit geval een wildcard certificaat gebruiken van DigiCert dus dan hebben ze niet veel om op te controleren en dit certificaat is maar een jaar geldig. (ook reactie op @LinuZZ)

Dus als je je certificaat maakt zou je in ieder geval dezelfde gegevens moeten invullen als Enphase heeft gedaan.

[mielus]

FendtVario schreef op woensdag 26 oktober 2022 @ 22:01:
@mielus interessante aanpak. Lijkt me redelijk arbeidsintensief, maar die extra data uit de micro-omvormers zou wel mooi zijn om lokaal te hebben. Die krijg je niet uit de Envoy API inderdaad.

Ik weet zeker dat die data in de POST van /emu_reports/performance_report zitten, maar het lijkt meer dan simpele compressie. Ik zie het envoy serienummer en dan onherleidbare data. Wellicht toch nog een soort simpele hash codering gebruikt, zal me niks verbazen als de envoy serienr de key is, ala het installer password algoritme.

Je schreef dat je het SSL deel nog niet werkt. Ik zie dat je endpoints als /emu_reports/performance_report wel voor HTTP als HTTPS hebt gedefinieerd. Gebruikt Envoy dan ook HTTP?

Zo ver ik nu kan zien gaan alle rapporten over http.
Https gaf eerst foutmeldingen, maar dat was een fout van mij, ik heb de correctie verwerkt in mijn 1e post.
De enige https url is: https://reports.enphaseenergy.com/emu_reports/key_exchange
Die zal wel gebruikt worden om de tunnel op te zetten vermoed ik.

Volgens mij is de enige manier om tussen een SSL verbinding te gaan zitten als diegene die de verbinding maakt (de Envoy dus) niet de attributen in het certificaat of de certificaat keten valideert. Maar ik zie dat ze in dit geval een wildcard certificaat gebruiken van DigiCert dus dan hebben ze niet veel om op te controleren en dit certificaat is maar een jaar geldig. (ook reactie op @LinuZZ)

Dus als je je certificaat maakt zou je in ieder geval dezelfde gegevens moeten invullen als Enphase heeft gedaan.
[Afbeelding]

Zoiets vermoede ik al, maar doet nginx dat inderdaad niet al automatisch met nginx-util add_ssl reports.enphaseenergy.com?
Anyhow, nu geen foutmeldingen, de envoy lijkt tevreden, enlighten lijkt tevreden, de knop "disable power production" heeft geen effect. Ik kijk het een paar dagen aan

[RichieB]

FendtVario schreef op woensdag 26 oktober 2022 @ 22:01:
[...]
Volgens mij is de enige manier om tussen een SSL verbinding te gaan zitten als diegene die de verbinding maakt (de Envoy dus) niet de attributen in het certificaat of de certificaat keten valideert. Maar ik zie dat ze in dit geval een wildcard certificaat gebruiken van DigiCert dus dan hebben ze niet veel om op te controleren
[...]

Het idee bij SSL is dat je de hele keten van server certificaat tot vertrouwd Root CA certificaat controleert. Als je zelf het certificaat gaat namaken komt het niet meer van een Root CA die door de Envoy vertrouwd wordt. Dat de rapporten nu (nog) geen SSL gebruik is mazzel. Zodra ze dat veranderen gaat deze proxy via nginx niet meer werken.

[mielus]

AmNL schreef op dinsdag 25 oktober 2022 @ 11:08:
2). Ik heb een python scriptje op mijn raspberry draaien die iedere minuut via de production.json de wNow uitleest en in een sql database gooit, echter (zoals anderen in dit topic ook aangeven) update hij niet exact regelmatig ('s morgens wel per minuut, maar later eens per 5 minuten). Ik probeer dit te ondervangen door installer/pcu_comm_check aan te spreken (geprobeerd eens per minuut, per 30 seconden of iedere 10 seconden), maar dit verandert niets. Iemand betere ideeën?

Ik gebruik dit icm homeassistant: https://github.com/vk2him/Enphase-Envoy-mqtt-json
Leest de CT klemmen uit met een resolutie van ongeveer een seconde via de stream api.
Wel zo handig als je snel extra dingen wil schakelen zoals thuisaccu lader, elektrische boiler enzo.

Wel v5 firmware nodig.

[mielus]

RichieB schreef op woensdag 26 oktober 2022 @ 22:56:
[...]

Het idee bij SSL is dat je de hele keten van server certificaat tot vertrouwd Root CA certificaat controleert. Als je zelf het certificaat gaat namaken komt het niet meer van een Root CA die door de Envoy vertrouwd wordt. Dat de rapporten nu (nog) geen SSL gebruik is mazzel. Zodra ze dat veranderen gaat deze proxy via nginx niet meer werken.

Ik ben geen expert in het hele ssl gebeuren. Misschien heb ik het mis, maar ik kijk er zo tegenaan:
Ik heb controle over de dns waar de envoy zijn query's doet en met wie de envoy denkt te babbelen.
De enlighten servers weten niet of ze nu met een envoy babbelen of met de nginx proxy.
Zolang er niet een certificaat in de firmware envoy zit kan "man in the middle" prima werken lijkt mij.
Gezien die certificaten iha jaarlijks verlopen vermoed ik dat dit niet in de firmware zit.
Het zou nog kunnen dat er een opslag medium in die envoy zit waar certificaten op staan, als ze het goed willen doen dan voor elke envoy een andere. Maar gezien de security track record van Enphase tot nu toe gok ik van niet.
En het kan best dan Enphase in de toekomst dit gaat blocken, jammer dan, ik mis weinig aan enlighten de enige extra data die ik daar (nu nog gratis) kan bekijken zijn de temp, AC/DC voltages van de micro's. Is interessante info als er tijdelijke uitval van productie is, bv omdat de hele buurt flink aan het terugleveren is en de "250V" grens om de hoek komt kijken of als de micro's heel erg heet worden.

[AmNL]

FendtVario schreef op woensdag 26 oktober 2022 @ 21:29:
[...]


Ik herken dit gedrag ja. Er is ook nog een /ivp/peb/newscan endpoint. Heb dit nog niet geprobeerd maar misschien helpt dat. Die wordt regelmatig door de webpagina die op de Envoy draait aangeroepen.

Thanks, ga ik ook nog eens mee spelen (en intussen geduld hebben met installateur/Enphase).
Een van de redenen dat ik het zelf maar in python heb geklopt is dat ik python min of meer begrijp en ik al een sql database had draaien (weerstationprojectje). Had niet zoveel zin er dan weer influxdb naast te zetten en zo.

mielus schreef op woensdag 26 oktober 2022 @ 23:07:
[...]

Ik gebruik dit icm homeassistant: https://github.com/vk2him/Enphase-Envoy-mqtt-json
Leest de CT klemmen uit met een resolutie van ongeveer een seconde via de stream api.
Wel zo handig als je snel extra dingen wil schakelen zoals thuisaccu lader, elektrische boiler enzo.
[Afbeelding]
Wel v5 firmware nodig.

Ah ja, deze heb ik ook voorbij zien komen en overwogen te gebruiken, alleen een simpele uitlezing van wNow was het eerste wat ik nodig vond en dat was wat simpeler even in elkaar te kloppen.
Wat mij overigens opvalt is dat er (ook wanneer er gewoon productie is) bij het uitlezen van die stream toch ook vaak 0 staat. Als er over een klein uurtje productie is zal ik even update met een screenshotje.

Update:
zoals je ziet in production.json produceren ze 4 watt, terwijl ik in de datastream bij production de p op 0.0 zie staan.

[ Voor 12% gewijzigd door AmNL op 27-10-2022 08:52 ]

[RichieB]

mielus schreef op woensdag 26 oktober 2022 @ 23:50:
[...]

De enlighten servers weten niet of ze nu met een envoy babbelen of met de nginx proxy.

Inderdaad maar de Envoys weet wel of ze met de Enlighten server praten of niet. Dat kunnen ze zien door de hele SSL certificaat keten te controleren tot aan het Root CA certificaat. Die Root CA moet in een lijst van CA’s staan die in de Envoy firmware zit. Staat de CA niet in de lijst dan kan de SSL verbinding worden geweigerd door de Envoy. [/quote]

Zolang er niet een certificaat in de firmware envoy zit kan "man in the middle" prima werken lijkt mij.
[…]

Je bedoelt een SSL Client Certificaat? Dat is voor deze controle niet nodig.

[mielus]

RichieB schreef op donderdag 27 oktober 2022 @ 08:58:
[...]

Inderdaad maar de Envoys weet wel of ze met de Enlighten server praten of niet. Dat kunnen ze zien door de hele SSL certificaat keten te controleren tot aan het Root CA certificaat. Die Root CA moet in een lijst van CA’s staan die in de Envoy firmware zit. Staat de CA niet in de lijst dan kan de SSL verbinding worden geweigerd door de Envoy. [/quote]

[...]

Ok dank voor de uitleg, ik heb het idee dat de v5 envoy deze controle nu niet doet (want ik krijg geen foutmeldingen en kan vrolijk de https data bekijken) en twijfel ernstig of het Root CA certificaat überhaupt ergens in de envoy is opgeslagen

Je bedoelt een SSL Client Certificaat? Dat is voor deze controle niet nodig.

Met een goede SSL client certificaat infrastuctuur zou de nginx proxy zich niet kunnen voordoen als envoy richting de enlighten servers. De enlighten servers zien dan: geen geldig client certificaat, dus geen envoy die wij kennen.
Maar ja gaat Enphase al deze moeite doen?

[RichieB]

@mielus Een SSL Client Certificaat gebruik je om te voorkomen dat ongeautoriseerde clients (zoals nginx) de server kunnen benaderen. Dit is echter best complex om goed te implementeren met apparatuur die bij klanten staat. Om te voorkomen dat iemand man-in-the-middle doet is een eenvoudige controle van het SSL server certificaat voldoende. Als je in het SSL verkeer kan kijken doet de Envoy die controle inderdaad niet.

[mielus]

AmNL schreef op donderdag 27 oktober 2022 @ 08:11:
zoals je ziet in production.json produceren ze 4 watt, terwijl ik in de datastream bij production de p op 0.0 zie staan.

Ik weet niet wat de resolutie van die CT spoelen is, 4W per micro is natuurlijk erg weinig, je moet er dan voldoende hebben die dit terug leveren, het-Q relais kan dacht ik +/- 20W opslurpen, dus als je met CT spoelen meet achter het Q-relais is dat al een verklaring voor het verschil. In elk geval weet ik uit ervaring dat de micro's een gemiddelde per x min geven, waardoor er op moment x geen teruglevering kan zijn, maar door de uitmiddelling lijkt het wel zo te zijn, zeker bij lage opbrengst staan ze te oscilleren. Door zelf te meten zie je het verschil:
Blauw is mijn meting (veel updates), groen de wNow(weinig updates) kleurverschil is slecht te zien in de post.

Het valt me op ik al eerder teruglevering kan meten dan de micro zelf rapporteert, maar deze micro heeft ook een slechte verbinding met de envoy, ik meet met zwave tussenstekkers, zal ook wel niet perfect zijn.

[AmNL]

mielus schreef op donderdag 27 oktober 2022 @ 11:06:
[...]

Ik weet niet wat de resolutie van die CT spoelen is, 4W per micro is natuurlijk erg weinig, je moet er dan voldoende hebben die dit terug leveren, het-Q relais kan dacht ik +/- 20W opslurpen, dus als je met CT spoelen meet achter het Q-relais is dat al een verklaring voor het verschil.

Ik snap je punt maar dat is niet wat er aan de orde is. wellicht heeft mijn enthousiasme om al bij 4 watt te screenshotten gezorgd voor wat verwarring, maar nu bij 860 watt is er niets veranderd


Ik denk dat de oorzaak van dit verschil er in ligt dat metering nog op "Meters not enabled" staat. Ik zou de wizard natuurlijk zelf kunnen doorlopen, maar gezien de boel nog niet geactiveerd is bij Enphase/door installateur wacht ik liever met te erg zelf rommelen, voor ze moeilijk gaan doen.

[macmenco]

mielus schreef op woensdag 26 oktober 2022 @ 14:02:
[...]

Ik zal een poging doen het toe te lichten, @LinuZZ heeft het al aardig door.


[...]

Klopt, maar er wordt een tunnel gemaakt vanuit Enphase naar jouw v5/v7 envoy
Je moet dan vertrouwen op de interne veiligheid van Enphase, ik doe dat liever niet.
Ook ben ik paranoïde over wat Enphase in de toekomst gaat doen. Met v7 heb je een token nodig van Enphase om gegevens aan je LAN kant uit te lezen. Bij v5 heb je dit probleem niet. Er wordt dus een afhankelijkheid gemaakt van Enphase, als ze geld gaan vragen voor die token of failliet gaan heb je dus een probleem met je v7 firmware, met v5 niet.
Volgens mij is er ook nog geen oplossing voor de stream/meter api (Is deze geschrapt in v7?)
En ik vind het jammer dat je aan de LAN kant niet alles van je micro's kan uitlezen, temp AC/DC voltage enzo v7 gaat dat ook niet verhelpen. Wellicht een decode van de rapportage die ik met nginx afvang wel.

[...]

Het is echt slecht dat het installer wachtwoord blijkbaar niet aangepast kan worden onder v5, misschien heeft Enphase hun zaakjes beter op orde in v7 maar:
Mijn v5 envoy zit in een eigen vlan, kan geen tunnel maken met Enphase en is dus niet bereikbaar vanaf het internet door niemand (tenzij iemand mijn router/firewall weet te hacken.)
Je kan ook de firewall helemaal dicht zetten, maar dan ook geen rapportage in enlighten.
Ik wilde mensen die nu nog v5 hebben en net als mij dachten een mogelijke oplossing aanreiken: behoud van alle LAN uitleesmogelijkheden zonder token, nog steeds all info in enlighten, geen onverwachte firmware push en naar mijn idee meer secure.


[...]

Nog steeds denk ik dat mijn oplossing meer secure is: nl. geen tunnel naar mijn envoy
Nieuwe systemen kunnen wellicht nu nog een rollback krijgen naar v5, ik vermoed dat over een tijdje het beleid is: "doen we niet, unsupported"


[...]

Men vergist zich in het "niets gekoppeld aan het internet" dat wilde ik even duidelijk maken.
Zonder internet geen vers token en een tunnel vanuit Enphase naar mijn eigen envoy wat ik als een security risk ervaar, v5 v7 maakt niet uit.
Allemaal prima als men dat niet erg vind, ik ben meer paranoïde.
Mijn doelstelling is dus: Vanuit enlighten manager deze knop onbruikbaar maken (ook evt met v7 firmware):
Maar mijn micro's en CT spoelen rapporteren nog steeds hun meetgegevens.
[Afbeelding]
In elk geval ben ik er achter dat alleen location /emu_reports/performance_report doorlaten en 208's geven op de andere locaties niet voldoende is, na een paar dagen vind de envoy dat hij niet meer verbonden is en stopt met data verzenden.
Uitzetten/aanzetten van envoy helpt, maar dat is niet echt een fijne oplossing, na een paar dagen stoppen de uploads weer.
Maar misschien moet ik niet 208 terug geven voor de andere locaties, maar gewoon 200
Of nog net iets meer doorlaten. Ik heb nu ook location /emu_reports/inventory_report en location /emu_reports/configuration_report een pass gegeven. Ik ga weer wat kleine tweaks proberen.

In elk geval heb ik nog een kleine typo ontdekt:

code:

 server {
        listen 18000;
        listen [::]:18000;

        server_name reports.enphaseenergy.com;

...
...
...
        location /emu_reports/task_complete {
            # zodra ik dit aanzet gaat er een poging plaats vinden om dingen over https te doen: oorzaak = typo
            #return 200;
            #return 208;
            limit_except POST {
              deny  all;
            }
            proxy_pass http://reports.enphaseenergy.com:80;  #oeps: ik had hier https staan!
        }
..
..
..

Een heel gezond idee om de boel te beperken. Ik ga hier ook zeker mee aan de slag, bedankt voor de voorzet. Vorige week woensdag een presentatie over deze gezien : https://www.divd.nl/reports/solarman/

[wnwiigrtz]

Super leuk dat iedereen hier zo lekker bezig is. O.a. door deze post van @vhlemoine was ik weer getriggerd zelf toch ook weer op zoek te gaan waarom het met de D7 software zo lastig is om er data uit te halen. Op de een of andere manier leek dat authorizeren met dat token toch niet lekker te werken, meesturen in de headers van het request werkte ook niet, ik bleef dan maar een 401 Unauthorized krijgen.

Met behulp van deze aanpassingen van @antoin is het mij gelukt om de plugin van @H4nsie in Domoticz te krijgen, maar dat je met de hand het sessieId ergens uit de console van je webbrowser moet halen vond ik nogal omslachtig. Dus ben ik de Tech Briefing gekozen zoals @Ruisbak deze hier eerder plaatste en er eens goed voor gaan zitten, maar, volgens mij is het gelukt!

De enige stap om het hele proces compleet te maken was een request op https://{Gateway_ip}/auth/check_jwt., met daarin de token die op https://entrez.enphaseenergy.com/tokens is te verkrijgen. Wanneer de token goed is, komt hieruit een cookie met daarin het sessionId. Deze kan op zijn beurt weer gebruikt worden om de URL's op de IQ Gateway aan te roepen.

Dus, van voor tot achter:

1. Haal de info op van je Enphase systeem via https://{Gateway_ip}/info.xml, hierin zit o.a. de firmware/softwar versie en het serienummer.
2. Gebruik je gebruikersnaam/e-mailadres en het wachtwoord van je Enlighten account voor het ophalen van een (eerste) sessionId door een POST uit te voeren op https://enlighten.enphaseenergy.com/login/login.json.
3. Gebruik het serienummer, je gebruikersnaam en het verkregen sessieId voor het uitvoeren van een POST op https://entrez.enphaseenergy.com/tokens, sending .
4. Gebruik de authToken die uit dit request is gekomen en voer een GET uit op https://{Gateway_ip}/auth/check_jwt. Als je authToken goed is krijg je "<!DOCTYPE html><h2>Valid token.</h2>" terug. In het request zitten tevens cookies.
5. Gebruik uit deze cookies het sessionId voor het aanroepen van de overige URL's (zoals bijv. https://{Gateway_ip}/production.json en https://Gateway_ip}/api/v1/production/inverters/) op je lokale IQ Gateway.

Ik verwacht dus dat er binnenkort een nieuwe update van de plugin komt, waarbij je voor de koppeling met je IQ Gateway gewoon alleen maar het e-mailadres en het wachtwoord van je Enlighten account
hoeft in te vullen in de instellingen zoals hieronder, in plaats van dat getob met zo'n sessieId, dat doet de plugin dan voor je.



@H4nsie Hoe kan ik je het beste mijn aangepaste versie van jouw plugin (v1.0.4) sturen?

[RichieB]

@wnwiigrtz Mooi stappenplan! Wat er nog bij moet is het een strategie voor het vernieuwen van het sessionId:

1. Als het sessionId niet meer lijkt te werken, haal dan een nieuwe op via https://{Gateway_ip}/auth/check_jwt
2. Als het authToken niet meer lijkt te werken in stap 1, haal dan een nieuwe op door de informatie van https://{Gateway_ip}/info.xml te gebruiken op https://entrez.enphaseenergy.com/tokens en ga naar stap 1

[Pazo]

Het gaat mijn pet af en toe allemaal wat te boven, maar ik vind mooi wat er allemaal uitgedokterd wordt

[mielus]

Ik heb een update gedaan van de config files in mijn 1e post: mielus in "[Enphase] Haal meer uit je Envoy!"
In het kort gaat het zo:
Om gegeven uitwisseling mogelijk te maken moet de evoy al een sleutel hebben verkregen via POST naar https://reports.enphaseenergy.com//emu_reports/key_exchange
De envoy stuurt periodiek mbv een POST naar http://reports.enphaseene...eports/performance_report de laatste meetwaarden
Enlighten geeft een respons 204: alles ok en geen taken staan klaar of 200: alles ok, maar je moet doen wat in de response body staat.
Als de taak is uitgevoerd stuurt de envoy een POST http://reports.enphaseenergy.com/emu_reports/task_complete
Er zijn 2 manieren om te zorgen dat je envoy geen ongewenste dingen gaat doen:
Zorgen dat de task_complete door nginx niet wordt doorgestuurd door een return 204 te doen.
Het lijkt dan zo te zijn dat er geen nieuwe taken bijkomen vanuit enlighten.
Of door de repons met een taak voor de envoy niet door te sturen.
Het is me gelukt om de respons ongeldig te maken, de envoy gaat dan stoppen met versturen naar enlighten (lan api blijft werken) een powercycle zou kunnen helpen om weer de communicatie op gang te brengen of langer wachten. Als het lukt om te ontcijferen wat er in de repons staat zou je gericht sommige dingen tegen kunnen houden.

Voorlopig lijkt het tegenhouden task_complete van de envoy goed te werken: de meetwaarden verschijnen in enlighten en de envoy doet hopelijk geen nare dingen.
Ik kijk het weer een tijdje aan, als er nog tips zijn om de respons compleet te herschrijven via nginx hoor ik het graag.

[FendtVario]

Ik ga ook eens experimenteren met Nginx ertussen. Bedankt voor de aanzet @mielus. Dat de envoy alles over http verstuurd geeft niet echt vertrouwen, beetje vreemd in 2022. Aan de andere kant is een brakke SSL implementatie net zo gevaarlijk. Mijn antwoord over waarden van het certificaat was te optimistisch, de keten naar een CA certificaat moet ook nog kloppen zoals @RichieB zegt.

Het net voltage kun je ook uit je slimme meter halen. Evenals het aantal Ampere. Als ik deze pagina goed begrijp heb je een meter nodig die minimaal DSMR 4 protocol rapporteerd.

[ Voor 4% gewijzigd door FendtVario op 28-10-2022 21:21 ]

[LinuZZ]

FendtVario schreef op vrijdag 28 oktober 2022 @ 21:21:
Ik ga ook eens experimenteren met Nginx ertussen. Bedankt voor de aanzet @mielus. Dat de envoy alles over http verstuurd geeft niet echt vertrouwen, beetje vreemd in 2022. Aan de andere kant is een brakke SSL implementatie net zo gevaarlijk. Mijn antwoord over waarden van het certificaat was te optimistisch, de keten naar een CA certificaat moet ook nog kloppen zoals @RichieB zegt.

Het net voltage kun je ook uit je slimme meter halen. Evenals het aantal Ampere. Als ik deze pagina goed begrijp heb je een meter nodig die minimaal DSMR 4 protocol rapporteerd.

Misschien rapporteert de envoy wel over http omdat/wanneer https mislukt?

Het voltage bij de meter kan trouwens wezenlijk anders zijn dan bij de omvormers. In mijn geval zit er tussen de meter en de eerste omvormer niet zon groot verschil maar tussen de eerste omvormer en de laatste in de (te lange) string zit toch 4-5 volt verschil. Ik heb dan ook een keer gehad dat 2 omvormers uitvielen door een te hoge spanning terwijl de rest gewoon door bleef leveren.

[wnwiigrtz]

RichieB schreef op vrijdag 28 oktober 2022 @ 00:34:
@wnwiigrtz Mooi stappenplan! Wat er nog bij moet is het een strategie voor het vernieuwen van het sessionId:

1. Als het sessionId niet meer lijkt te werken, haal dan een nieuwe op via https://{Gateway_ip}/auth/check_jwt
2. Als het authToken niet meer lijkt te werken in stap 1, haal dan een nieuwe op door de informatie van https://{Gateway_ip}/info.xml te gebruiken op https://entrez.enphaseenergy.com/tokens en ga naar stap 1

Thnx. En ja, klopt, hij moet het eigenlijk zelf automatisch ophalen als het verlopen is, maar ik vond het om 00:30 op een doordeweekse avond wel even goed zo.

Als ik de tech brief die @Ruisbak hier postte mag geloven, is het token 1 jaar geldig. Dus voorlopig werkt het wel even zo, maar ik heb persoonlijk een hekel aan dingen die dan verlopen en je dan met de hand weer iets moet bijwerken/aanpassen. Zeker als het na een jaar is. Zit ik volgend jaar november lekker in Domoticz te kijken, werkt het niet, zoek ik me weer helemaal suf hier op 't forum én in m'n geheugen om uit te zoeken hoe dat ook alweer moest. Wil er gewoon geen (zo min mogelijk) omkijken naar hebben, dus als dingen automatisch/vanzelf kunnen, dan heeft dat mijn voorkeur.

Voor de liefhebbers, ik heb een simple voorbeeld scriptje in Python online gezet, waar ik stap 1 t/m 5 uitvoer en je aan het einde als het goed is de data uit de IQ Gateway terugkrijgt. Enige wat je hiervoor moet doen is bovenin het script het ip-adres van de IQ Gateway en je username en wachtwoord van je Enlighten Account in te vullen, de rest werkt vanzelf. Zie https://pastebin.com/8pa1hKU6 voor 't scriptje.

[Ruisbak]

wnwiigrtz schreef op zaterdag 29 oktober 2022 @ 11:52:
[...]


Thnx. En ja, klopt, hij moet het eigenlijk zelf automatisch ophalen als het verlopen is, maar ik vond het om 00:30 op een doordeweekse avond wel even goed zo.

Als ik de tech brief die @Ruisbak hier postte mag geloven, is het token 1 jaar geldig. Dus voorlopig werkt het wel even zo, maar ik heb persoonlijk een hekel aan dingen die dan verlopen en je dan met de hand weer iets moet bijwerken/aanpassen. Zeker als het na een jaar is. Zit ik volgend jaar november lekker in Domoticz te kijken, werkt het niet, zoek ik me weer helemaal suf hier op 't forum én in m'n geheugen om uit te zoeken hoe dat ook alweer moest. Wil er gewoon geen (zo min mogelijk) omkijken naar hebben, dus als dingen automatisch/vanzelf kunnen, dan heeft dat mijn voorkeur.

Voor de liefhebbers, ik heb een simple voorbeeld scriptje in Python online gezet, waar ik stap 1 t/m 5 uitvoer en je aan het einde als het goed is de data uit de IQ Gateway terugkrijgt. Enige wat je hiervoor moet doen is bovenin het script het ip-adres van de IQ Gateway en je username en wachtwoord van je Enlighten Account in te vullen, de rest werkt vanzelf. Zie https://pastebin.com/8pa1hKU6 voor 't scriptje.

Geweldig gedaan!
Nu hopen dat @H4nsie een poging wil wagen om dit in zijn (development) script te gieten.
Ondanks dat hij waarschijnlijk zelf de D7 firmware nog niet heeft.
Ik test het graag even uit.

[discusws]

Verkeerde topic

[ Voor 92% gewijzigd door discusws op 30-10-2022 14:05 ]

[vhlemoine]

@wnwiigrtz

4. Gebruik de authToken die uit dit request is gekomen en voer een GET uit op https://{Gateway_ip}/auth/check_jwt. Als je authToken goed is krijg je "<!DOCTYPE html><h2>Valid token.</h2>" terug. In het request zitten tevens cookies.


How to pass the authToken to https://{gateway_ip}/auth/check_jwt ?

[henkkeumus]

Cool dit, dit weekend dit topic maar eens even doorlezen.

Ik heb op dit moment de HACS intergratie draaien omdat de normale intergratie van Envoy een timeout geeft.
https://github.com/briancmpbll/home_assistant_custom_envoy

Vervolgens een Riemann SOM intergrale helper aangemaakt die de waarde van mijn panelen omzet naar KwH waarmee ik een sensor in het energie dashboard kan zetten en het bij kan houden.

[Ruisbak]

vhlemoine schreef op maandag 31 oktober 2022 @ 09:16:
@wnwiigrtz

4. Gebruik de authToken die uit dit request is gekomen en voer een GET uit op https://{Gateway_ip}/auth/check_jwt. Als je authToken goed is krijg je "<!DOCTYPE html><h2>Valid token.</h2>" terug. In het request zitten tevens cookies.


How to pass the authToken to https://{gateway_ip}/auth/check_jwt ?

You can check the fully working script here.

[antoin]

Ruisbak schreef op maandag 31 oktober 2022 @ 09:46:
[...]


You can check the fully working script here.

Als ik het goed zie heeft deze code nog geen retry voor een nieuw Token/SessionID als een request een "401 not authorized" terug krijgt van de envoy.

@wnwiigrtz: Het Token is inderdaad 6 maanden of een jaar geldig, maar de SessionID kan eerder verlopen. Mij staat iets bij dat de andere parameters in de cookie na 1 maand verlopen. Mijn vorige SessionID hield het meer dan een week uit totdat ik zelf de envoy rebootte. Maar ik heb het ook al een keer gehad dat hij er een keer mee stopte en ik een nieuw SessionID moest ophalen. Volgens mij was dat 1 maand nadat ik het Token had gegenereerd. Omdat we een Python script gebruiken en geen formele browser zal de SessionID waarschijnlijk alleen verlopen als Domoticz langere tijd geen request doet, en/of als de envoy code het zelf tijd vind om opnieuw te authenticeren na 1 maand. (De envoy weet met een directe aanroep immers niet dat een sessie is geëindigd zoals bij een formele browser). Als Domoticz langere tijd geen request doet, dan zal Domoticz waarschijnlijk uit staan, en bij het opstarten een nieuw Token/SessionID ophalen als ik de Python code goed lees.
Moet je alleen niet vergeten om Domoticz ook een schop te geven als de envoy een keer reboot.

Ik zal komend weekend ook maar eens upgraden naar plugin versie 1.0.6
En dan kijken of de SessionID na een maand nog werkt.

[Ruisbak]

antoin schreef op maandag 31 oktober 2022 @ 20:15:
[...]

Ik zal komend weekend ook maar eens upgraden naar plugin versie 1.0.6
En dan kijken of de SessionID na een maand nog werkt.

Precies dat, die heb ik hier nu ook draaien.

Het Token is overigens 1 jaar geldig, dat staat in de Enphase Tech Brief.
Volgens mij kan een SessionID net zo lang bestaan als de sessie loopt, dus niet per se een maand.
Maar zeker weten doe ik dat ook niet.
We gaan het zien, voorlopig blijf ik er even vanaf om het te weten te komen.

[vhlemoine]

Expiration date of Token

1. To check the expiration date of the Token you can paste your token to https://jwt.io in the encoded part on the left.
2. On the right "DECODED" part check the payload data, like
{"aud": "serialnumber","iss": "Entrez","enphaseUser": "owner","exp": 1697692549,"iat": 1666156549,"jti": "xxxx-xxxx-xxxx-xxxxx","username": "username"}
3. the "exp" shows the expiration date

[Markus80]

Beste forumleden, ik heb een vraag over mijn zonnepanelen. Misschien een beetje off-topic maar hopelijk kan iemand mij hierbij helpen. Ik heb sinds kort 24 panelen op mijn dak liggen. Na wat hickups werkte dit goed tot Zondagmiddag ergens. Toen werd er geen productie meer geregistreerd. De juiste groene lampjes branden op mijn Envoy. Wat zou de oorzaak hier van kunnen zijn en hoe los ik dit op? Mijn installateur geeft geen thuis.

[Panzer_V]

Markus80 schreef op dinsdag 1 november 2022 @ 12:25:
Beste forumleden, ik heb een vraag over mijn zonnepanelen. Misschien een beetje off-topic maar hopelijk kan iemand mij hierbij helpen. Ik heb sinds kort 24 panelen op mijn dak liggen. Na wat hickups werkte dit goed tot Zondagmiddag ergens. Toen werd er geen productie meer geregistreerd. De juiste groene lampjes branden op mijn Envoy. Wat zou de oorzaak hier van kunnen zijn en hoe los ik dit op?

[Afbeelding]

Wat zegt je slimme meter?

Oftewel, registreert de Envoy geen productie meer of is er geen productie meer?

[ZuidLimburg]

Markus80 schreef op dinsdag 1 november 2022 @ 12:25:
Beste forumleden, ik heb een vraag over mijn zonnepanelen. Misschien een beetje off-topic maar hopelijk kan iemand mij hierbij helpen. Ik heb sinds kort 24 panelen op mijn dak liggen. Na wat hickups werkte dit goed tot Zondagmiddag ergens. Toen werd er geen productie meer geregistreerd. De juiste groene lampjes branden op mijn Envoy. Wat zou de oorzaak hier van kunnen zijn en hoe los ik dit op? Mijn installateur geeft geen thuis.

[Afbeelding]

Zo te zien heb je een 3-fase installatie met metered Envoy. Wat is de status van je Q-relay? Welke status hebben de leds op je Q-relay?

[Pazo]

@Markus80 De Envoy al een keer van de stroom gehaald en opnieuw op laten starten? Dit probleem had ik enkele weken geleden ook: alles leek te werken, maar Enlighten gaf 0 aan. Na een herstart deed alles het weer, zelf de cijfers van eerder die dag werden weergegeven / teruggehaald.

[Markus80]

Bedankt voor de reacties!

Panzer_V schreef op dinsdag 1 november 2022 @ 12:26:
[...]

Wat zegt je slimme meter?

Oftewel, registreert de Envoy geen productie meer of is er geen productie meer?

geen idee hoe ik de slimme meter moet uitlezen, ga ik onderzoeken

ZuidLimburg schreef op dinsdag 1 november 2022 @ 13:30:
[...]


Zo te zien heb je een 3-fase installatie met metered Envoy. Wat is de status van je Q-relay? Welke status hebben de leds op je Q-relay?

ik heb een enkele fase installatie verdeelt over 2 Q-relays, beiden hebben 2 groene leds

Pazo schreef op dinsdag 1 november 2022 @ 13:44:
@Markus80 De Envoy al een keer van de stroom gehaald en opnieuw op laten starten? Dit probleem had ik enkele weken geleden ook: alles leek te werken, maar Enlighten gaf 0 aan. Na een herstart deed alles het weer, zelf de cijfers van eerder die dag werden weergegeven / teruggehaald.

Dit heb ik vanochtend gedaan maar heeft geen effect gehad

[Panzer_V]

Markus80 schreef op dinsdag 1 november 2022 @ 13:55:
Bedankt voor de reacties!

[...]


geen idee hoe ik de slimme meter moet uitlezen, ga ik onderzoeken

Gewoon naar dat ding lopen en op het knopje duwen. Dan zie je snel genoeg of er stroom geexporteerd wordt of niet.

[ZuidLimburg]

[quote]Markus80 schreef op dinsdag 1 november 2022 @ 13:55:
Bedankt voor de reacties!

[...]


geen idee hoe ik de slimme meter moet uitlezen, ga ik onderzoeken


[...]


ik heb een enkele fase installatie verdeelt over 2 Q-relays, beiden hebben 2 groene leds


[...]

Je hebt dus 24 panelen x circa 400 WP = 9600W / 230 = >41A aan vermogen op een enkelfase hoofdzekering? Wat heb je dan voor hoofdzekering op jouw aansluiting? Ik zie dat jouw metered Envoy geen productie registreert, maar ook geen verbruik. Zoals Panzer aangeeft: check even je actuele vermogen op de slimme meter om te zien wat er aan de hand is...

[sipje]

Ik hoop dat iemand kan helpen. Ik heb gisteren mijn envoy en panelen in gebruik genomen. Ik wilde de Envoy blokkeren voor internettoegang, maar ik heb helaas ook de D7 firmware op de envoy staan. Ik kon er gisteren wel bij komen door een token te genereren voor de uncommissioned Envoy. Daarna kon ik mooi json data ophalen.
Nu, een dag later, werkt het token niet meer. Ik heb op dezelfde manier weer een token aangemaakt, maar ik krijg een 401 als ik die gebruik. in een request. Als ik het token in de weginterface van de envoy invul, staat er "Bad Token". Ik kan het token decoderen op https://jwt.io/, dus daar lijkt niks mis mee (het token is overigens maar 1 dag geldig).

Weet iemand hoe ik toch weer toegang kan krijgen tot mijn Envoy zonder dat ik hem aan internet moet koppelen?

rant: Ik ben er wel een beetje ziek van moet ik zeggen: een smak geld betaald voor luxere omvormers en een prijzige gateway om vervolgens niet bij mijn eigen data te kunnen zonder dat ik mijn adresgegevens en omvormerdata naar Enphase moet sturen, belachelijk.

[antoin]

vhlemoine schreef op dinsdag 1 november 2022 @ 08:17:

Expiration date of Token

1. To check the expiration date of the Token you can paste your token to https://jwt.io in the encoded part on the left.
2. On the right "DECODED" part check the payload data, like
{"aud": "serialnumber","iss": "Entrez","enphaseUser": "owner","exp": 1697692549,"iat": 1666156549,"jti": "xxxx-xxxx-xxxx-xxxxx","username": "username"}
3. the "exp" shows the expiration date

I'd rather do this locally on my commandline or in the python script instead of leaking this to an external website. Decoding a Json web token is not that hard:

pyjwt3 decode --no-verify <YourWebToken>

code:

antoin@walhalla:~$ pyjwt3 decode --no-verify eyJra**********************************************..................***************MAMQ

{"aud": "1222********", "iss": "Entrez", "enphaseUser": "owner", "exp": 1697383039, "iat": 1665847039, "jti": "f11abec5-6e9f-4b8f-a666-a34c777c888f", "username": "******@****.nl"}

antoin@walhalla:~$ date -d @1697383039
Sun 15 Oct 2023 05:17:19 PM CEST

Would be a nice extra feature in the plugin to refresh the token a day before expiry.

I do have a security concern with the way Enphase implemented the oauth webtoken though:

-When your password is compromised, you can reset your password -yourself-
-When your SessionID is compromised, you can reset your envoy -yourself-
-But when your webtoken is compromised, it is still valid for a year, without a possibility to revoke it.

Must dive a little bit deeper into RFC7519 to understand the revocation process, but I don't think webtokens can be revoked.

[antoin]

sipje schreef op dinsdag 1 november 2022 @ 18:40:

Weet iemand hoe ik toch weer toegang kan krijgen tot mijn Envoy zonder dat ik hem aan internet moet koppelen?

Ik ben bang dat je envoy toch internet toegang moet hebben om het door jou gegenereerde webtoken bij enphase op te halen zodat die geldig is op de lokale webinterface van je envoy....

Maar dat jouw token maar 1 dag geldig is is vreemd. Heb je je envoy al volledig van het internet afgekoppeld? Wat staat er achter "enphaseUser": in je webtoken?

En voor wat jouw rant betreft: Als Enphase het zo moeilijk gaat maken om toegang te krijgen tot je eigen envoy, dan zullen veel mensen de envoy wellicht uitzetten. De omvormers werken prima zonder envoy. Misschien moeten we ons gaan concentreren op het decrypten van het signaal wat uit de omvormers komt, en gewoon zelf een open source envoy ontwikkelen ;-)

[Ruisbak]

antoin schreef op dinsdag 1 november 2022 @ 19:32:
[...]

...

En voor wat jouw rant betreft: Als Enphase het zo moeilijk gaat maken om toegang te krijgen tot je eigen envoy, dan zullen veel mensen de envoy wellicht uitzetten. De omvormers werken prima zonder envoy. Misschien moeten we ons gaan concentreren op het decrypten van het signaal wat uit de omvormers komt, en gewoon zelf een open source envoy ontwikkelen ;-)

Veel mensen de envoy uit zetten? Welnee, het overgrote deel van de gebruikers kijkt in de App van Enphase en dat werkt allemaal prima.
Dat wij hier zitten te tweaken om het er lokaal uit te halen is echt in de marge voor Enphase.
Maak je geen illusies.

[Ruisbak]

antoin schreef op dinsdag 1 november 2022 @ 19:09:
[...]

...
-But when your webtoken is compromised, it is still valid for a year, without a possibility to revoke it.

Must dive a little bit deeper into RFC7519 to understand the revocation process, but I don't think webtokens can be revoked.

This crossed my mind as well and although you need local access to the Envoy, you do have a valid point.
If you find a way to revoke them, let us all know please.

[antoin]

Ruisbak schreef op dinsdag 1 november 2022 @ 19:46:
[...]

Maak je geen illusies.

Er stond niet voor niets een smiley achter ;-)

[sipje]

antoin schreef op dinsdag 1 november 2022 @ 19:32:
[...]


Ik ben bang dat je envoy toch internet toegang moet hebben om het door jou gegenereerde webtoken bij enphase op te halen zodat die geldig is op de lokale webinterface van je envoy....

Daar was ik al bang voor. Heb hem nu gedeblokkeerd en aangemeld by enphase. Ik kan nu in ieder geval weer data inzien.

En voor wat jouw rant betreft: Als Enphase het zo moeilijk gaat maken om toegang te krijgen tot je eigen envoy, dan zullen veel mensen de envoy wellicht uitzetten. De omvormers werken prima zonder envoy. Misschien moeten we ons gaan concentreren op het decrypten van het signaal wat uit de omvormers komt, en gewoon zelf een open source envoy ontwikkelen ;-)

Daar zat ik stiekem ook al aan te denken.... moeten we wel een interface naar de Powerline hebben, of misschien is de envoy wel makkelijk te herprogrammeren, dan heb ik daar het geld in ieder geval niet voor weggegooid.

[mielus]

sipje schreef op dinsdag 1 november 2022 @ 21:10:
Daar zat ik stiekem ook al aan te denken.... moeten we wel een interface naar de Powerline hebben, of misschien is de envoy wel makkelijk te herprogrammeren, dan heb ik daar het geld in ieder geval niet voor weggegooid.

Op de envoy staat gewoon linux, er is een teardown gedaan, en daarbij een serial console gemaakt:
https://thecomputerperson...enphase-envoy-s-teardown/
Als het lukt om een dump van de flashchip uitlezen, daar even in rond te kijken en een eigen linux image erop zetten is dat wel te doen denk ik.
Het hele board is wel ondergespoten met een soort 'lacker" dat maakt het wel moeilijk om de flash chip uit te lezen. Ik vermoed dat er ook nog een usb/tftp flash methode zoals met de meeste openwrt devices. Dus als we eenmaal een werkende custom firmware hebben hoeft niet iedereen zijn envoy open te slopen.
Ondertussen ben ik hoopvol dat nginx als reverse proxy firmware upgrades tegenhoud en blijf ik lekker op v5 zitten. (zie mijn eerdere posts)

[JAbel]

Hallo,
Ik heb sinds 2 weken ook 9 panelen liggen met de enphase omvormers. Wat mij opvalt is dat er verschil is tussen wat het systeem aangeeft te hebben geexporteerd ( teruglevering) en wat de slimme meter ( en ook mijn energieleverancier) registreert. 82,04 kwh en via Enlight app 92,4 kwh. Zijn de CT spoelen in de Envoy dan minder nauwkeurig of ligt dit juist aan de slimme meter?
Heeft iemand daar meer ervaring mee?

[martijn v o]

Waarschijnlijk de meetmethode. De opbrengst kun je laten weergeven via de micros of de envoy. Dat kun je instellen en daar zit wat verschil tussen.

[InfoTracer]

JAbel schreef op woensdag 2 november 2022 @ 12:48:
Hallo,
Ik heb sinds 2 weken ook 9 panelen liggen met de enphase omvormers. Wat mij opvalt is dat er verschil is tussen wat het systeem aangeeft te hebben geexporteerd ( teruglevering) en wat de slimme meter ( en ook mijn energieleverancier) registreert. 82,04 kwh en via Enlight app 92,4 kwh. Zijn de CT spoelen in de Envoy dan minder nauwkeurig of ligt dit juist aan de slimme meter?
Heeft iemand daar meer ervaring mee?

Hou je er wel rekening mee dat je slimme meter alleen de terug levering ziet/meet min het gebruik binnen je huis.
Simpel voorbeeld: Lever je 500watt terug en heb je een 100watt lamp aan staan dan ziet je slimme meter een teruglevering van 400watt.

[RichieB]

InfoTracer schreef op woensdag 2 november 2022 @ 16:15:
[...]
een 100watt lamp
[...]

Foei! Je bedoelt 20 led lampen van 5 Watt.

[JAbel]

Hallo,
Klopt, daar heb ik al rekening mee gehouden. Op de app kan je dit namelijk allemaal mooi zien. Dus ik vergelijk alleen de daadwerkelijke teruglevering van de app met die op de slimme meter. Daar dus een verschil van 10 Kwh.

[FendtVario]

Bestaat er ergens een (zo compleet mogelijk) overzicht van bekende endpoints op de Envoy? De TS heeft mij enorm geholpen met data ophalen. In een andere post hier zie ik nu bijv. https://{gateway_ip}/auth/check_jwt die niet in de TS staat.
Het mooiste zou nog zijn als er een endpoint is waarop je de opbrengst per omvormer kan zien en niet alleen het huidige wattage, maar die heb ik nog niet voorbij zien komen.

[Jeuvie]

[b]Markus80 in "[Enphase] Haal meer uit je Envoy!"
[Afbeelding]

Wat voor app gebruik jij? Die van mij registreert geen teruglevering.

[antoin]

FendtVario schreef op vrijdag 4 november 2022 @ 22:19:
Bestaat er ergens een (zo compleet mogelijk) overzicht van bekende endpoints op de Envoy? De TS heeft mij enorm geholpen met data ophalen. In een andere post hier zie ik nu bijv. https://{gateway_ip}/auth/check_jwt die niet in de TS staat.

Welke "de" envoy? Welke firmware?
De TS is gebaseerd op de D5 firmware.
https://{gateway_ip}/auth/check_jwt is een nieuwe URL in de D7 firmware
Misschien kan de TS worden aangepast met wat we nu weten over de D7 firmware en de authenticatie.

FendtVario schreef op vrijdag 4 november 2022 @ 22:19:
Het mooiste zou nog zijn als er een endpoint is waarop je de opbrengst per omvormer kan zien en niet alleen het huidige wattage, maar die heb ik nog niet voorbij zien komen.

Die zul je niet als URL in de envoy vinden.
De opbrengst wordt berekend door de wattages met regelmaat uit te lezen, op te slaan in een database, en dan te extrapoleren. Die geschiedenis wordt opgeslagen of op de enphase servers, zodat enlighten daaruit de opbrengst kan berekenen, of in je eigen Domoticz/HA/domotica database zodat die uit de geschiedenis de opbrengst kan berekenen.

Er zit wel enkele geschiedenis in de envoy voor het geval er geen contact kan worden gemaakt met de enphase servers, maar dat is maximaal enkele dagen, en die buffer wordt weer geleegd zodra er weer contact is met de enphase servers. De envoy is gewoon een simpel apparaat die waardes meet en doorgeeft. Die berekent zelf helemaal niets.

[Pazo]

antoin schreef op vrijdag 4 november 2022 @ 23:08:
Misschien kan de TS worden aangepast met wat we nu weten over de D7 firmware en de authenticatie.

Dat vind ik wel een goede maar ook een lastige. Omdat ik zelf op versie 5 zit en nog niet van plan ben om naar versie 7 te gaan, heb ik er nog geen feeling bij en kan ik ook niet zaken testen / proberen die hier worden genoemd.

[antoin]

Ruisbak schreef op dinsdag 1 november 2022 @ 19:54:
[...]


This crossed my mind as well and although you need local access to the Envoy, you do have a valid point.
If you find a way to revoke them, let us all know please.

I did some research on this, and a Json Web Token (JWT) can not be revoked.
The only method is to blacklist a compromised JWT on the (web)server side.
(https://dev.to/pazvanti/h...te-a-compromised-jwt-23ld)

This means that only Enphase can invalidate a compromised JWT by pushing it to a blacklist on your local envoy, so that your envoy's webserver can then use that blacklist before accepting the token.

So, Enphase gave us a nice interface to generate a JWT that is valid for a year, but no interface to invalidate it when it gets compromised. I also don't think a JWT blacklist is implemented on the envoy's webserver. Who dares to contact Enphase with a request to block a compromised Web Token? ;-)

[vhlemoine]

Firmware version D7

When reading data from envoy.local via python scripts, data is refreshed every 5 minutes.

When running https://envoy.local in a browser, logging in via token and click "installer login", the browser script starts updating inverterdata every minute, subsequently python script can read changed data every minute.

Is this a familiar problem, any idea to solve this without the need of a browser?

[RichieB]

@vhlemoine Did you try this already?

[sipje]

FendtVario schreef op vrijdag 4 november 2022 @ 22:19:
Bestaat er ergens een (zo compleet mogelijk) overzicht van bekende endpoints op de Envoy? De TS heeft mij enorm geholpen met data ophalen. In een andere post hier zie ik nu bijv. https://{gateway_ip}/auth/check_jwt die niet in de TS staat.
Het mooiste zou nog zijn als er een endpoint is waarop je de opbrengst per omvormer kan zien en niet alleen het huidige wattage, maar die heb ik nog niet voorbij zien komen.

Die is er helaas niet. Wat ik nu doe is iedere 30 seconden op het endpoint /api/v1/production/inverters alle inverter data ophalen. Nieuwe metingen sla ik dan op in een database en daar kun je mee doen wat je wilt.

Ook haal ik op /api/v1/production de "wattHoursLifetime" op en sla ik die op. In home assistant kun je die data weer ophalen en in je energiedashboard tonen.

Overigens moest ik de envoy eerst een keer online laten gaan, anders werkte een nieuw opgevraagd token niet. Nu heb ik de firewall weer dicht gezet en kan ik gewoon nieuwe tokens opvragen die de envoy wel accepteert. Helaas zijn die tokens bij mij iedere keer maar 12 uur geldig. Ik heb een scriptje gemaakt dat een nieuw token opvraagt als de envoy geen nieuwe sessionId kan aanmaken.

[Acradavos]

Wellicht niet helemaal de goede plek, maar ik heb een probleem in combinatie met Home Assistant.

Na het onderbreken van de stroom, kloppen de gegevens in mijn Energy Dashboard niet meer.

Normale werking:



Niet juiste werking:



Ik zou die dag dus 517.82 kWh opgewerkt hebben, echter is dat de totale opgewerkte energie sinds ingebruikname.

Ik gebruik de custom Enphase integratie met de volgende sensor:

sensor.envoy_(serienummer)_today_s_energy_production

De maandgegevens zijn nu ook al niet meer kloppend.

[Panzer_V]

Acradavos schreef op maandag 7 november 2022 @ 16:19:
Wellicht niet helemaal de goede plek, maar ik heb een probleem in combinatie met Home Assistant.

Na het onderbreken van de stroom, kloppen de gegevens in mijn Energy Dashboard niet meer.

Normale werking:

[Afbeelding]

Niet juiste werking:

[Afbeelding]

Ik zou die dag dus 517.82 kWh opgewerkt hebben, echter is dat de totale opgewerkte energie sinds ingebruikname.

Ik gebruik de custom Enphase integratie met de volgende sensor:

sensor.envoy_(serienummer)_today_s_energy_production

De maandgegevens zijn nu ook al niet meer kloppend.

Wat je zelf al zegt. Niet het juiste topic. Hier kan je je vraag beter stellen.

https://gathering.tweakers.net/forum/list_messages/2058344

[Acradavos]

Panzer_V schreef op maandag 7 november 2022 @ 16:29:
[...]


Wat je zelf al zegt. Niet het juiste topic. Hier kan je je vraag beter stellen.

https://gathering.tweakers.net/forum/list_messages/2058344

Ik vroeg het toch juist hier, omdat het inhoudelijk meer over de Enphase sensor gaat.

[Ind!go]

Met dank aan deze topic ben ik erachter gekomen waarom mij envoy te weinig meet. Met de installer login heb ik kunnen zien dat er maar op 1 fase wordt gemeten. De CT's van de andere fases zijn goed aangesloten met de pijltjes naar de juiste richting. Moet ik nog in de configuratie iets aanpassen om de andere fases activeren om te gaan meten?

[gAzu]

Ja Ind!go, in de installer toolkit kan je bij punt 6 de meterconfiguratie aanpassen.
Hier kan per meter je kiezen voor 1 2 of 3 fasen.
Staat ergens onder aan de pagina.
Als daar staat L1 (of L(A) ik weet het even niet meer uit mn hoofd) en je hebt 6 ct's aangesloten dan heb je het lek boven.
Pas zowel de consumptie als de productiemeter aan naar het juiste aantal aangesloten fasen.

[gAzu]

Net rolde er in de installer toolkit trouwens een nieuwe softwareversie binnen:
07.06.17 het vraagtekentje erachter zegt: voor IQ8 pv only installations in the EMEA area

Verder staat er de 07.04.28 voor opslagsystemen met een netgebonden batterij
En de 05.00.62 voor pv only systemen.

Geen 7.00.88 in het rijtje, maar die zit helaas wel in mijn envoy.
De IT geeft aan dat de juiste versie automatisch naar de Envoy wordt geladen.
Waar de 7.00.88 dan precies voor is volgens Enphase kan ik dus niet zien.

Voor wat de security betreft zie ik open systemen langs komen als risico en de verbinding met enlighten.
Maar vergeet ook je installateur en zijn netwerkomgeving niet. die kan ook bij je systeem.
Ook via die weg zou een hacker toegang kunnen krijgen op je installatie.
Net als via een hack van een ander apparaat op je lan.

Misschien niet de meest voor de hand liggende manieren, maar het kán wel.

[gAzu]

Oja, ik heb ook nog nergens iets gelezen over het eventueel uitlezen van de high resolution data.
Die vind je onder het System Dashboard. Je moet denk ik wel als installer zijn ingelogd.

Hier vind je per fase de production en consumption stroomsterkte, de netspanning, de aggregatie van de productie en consumptie vermogens (totalen) en de powerfactoren en de netfrequentie
In hoge resolutie, dus meerdere waarden per seconde.