[Enphase] Envoy / IQ Gateway lokaal uitlezen voor domotica

[Copitano]

Lawrentz schreef op zondag 24 maart 2024 @ 09:58:
De vreugde was van korte duur. Vanmorgen om 8:27 de laatste update van alle devices van de panelen. Daarna niet meer. Maar het heeft dus wel gewerkt.

code:

curl: (22) The requested URL returned error: 401 Unauthorized

Het eeste script geeft nog geen update van de devices. Lijkt er dus op dat daar inderdaad de meetspoelen voor nodig zijn.

Vraag:
Welke communicatiegateway heb je?

Envoy S Metered maar zonder meetspoelen dus.

Btw, Enphase heeft ook kleine meetspoelen:
https://enphase.com/nl-nl...ation/kleine-meetspoel-ct
Wellicht kan je bij je installateur kan navragen of deze meetspoelen ook bij jou passen en werken.

Ik ga daar eens naar kijken, maar zou eigenlijk niet nodig moeten zijn. Het heeft hiervoor perfect gewerkt met de oude inlog methode.

Vraag:
Krijg je in Enlighten of je App wel alle data te zien?

Ja.

EDIT: Na opnieuw het installateurstoken te hebben opgevraagd en in geplakt loopt het nu weer voor de panelen. Even afwachten hoe lang. Als ik het goed begrijp blijft een installateurs token maar heel kort (6 of 12 uur) geldig. Met een token via de gebruikersaccount login werkt niet.

[ Voor 29% gewijzigd door Copitano op 24-03-2024 12:28 ]

[Copitano]

@Pazo

Enphase houdt ons lekker bezig zo

[ Voor 14% gewijzigd door Copitano op 24-03-2024 11:25 ]

[breew]

ta_chi79 schreef op zondag 24 maart 2024 @ 10:41:
Mijn HA integratie met Enphase is sinds gister stuk.
Als ik in de logs kijk loopt het vast op het ophalen van een nieuwe token.

code:

2024-03-23 11:55:51.488 ERROR (MainThread) [custom_components.enphase_envoy] Unexpected error fetching envoy Envoy ****** data: Could not get 6 month token: {"timestamp":1711191351423,"message":"Failure in loading token configuration for ****** and ****** envoy"}
Traceback (most recent call last):
  File "/usr/src/homeassistant/homeassistant/helpers/update_coordinator.py", line 318, in _async_refresh
    self.data = await self._async_update_data()
                ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/src/homeassistant/homeassistant/helpers/update_coordinator.py", line 274, in _async_update_data
    return await self.update_method()
           ^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/config/custom_components/enphase_envoy/__init__.py", line 50, in async_update_data
    await envoy_reader.getData()
  File "/config/custom_components/enphase_envoy/envoy_reader.py", line 379, in getData
    await self._getEnphaseToken()
  File "/config/custom_components/enphase_envoy/envoy_reader.py", line 272, in _getEnphaseToken
    token_json = await self._fetch_owner_token_json()
                 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/config/custom_components/enphase_envoy/envoy_reader.py", line 260, in _fetch_owner_token_json
    raise Exception("Could not get 6 month token: " + msg)
Exception: Could not get 6 month token: {"timestamp":1711191351423,"message":"Failure in loading token configuration for ****** and ****** envoy"}

Gebruikte nog de oude posixx integratie, dus die gedeinstalleerd en de briancmpbll geinstalleerd, maar kom daar niet door de setup heen om de envoy toe te voegen omdat de authenticatie misgaat.

Handmatig het shell script in https://enphase.com/downl...oken-based-authentication proberen uit te voeren en daar komt ook geen bruikbaar token uit. Het gaat al mis bij het uitlezen van het sessie id:

code:

user='******'
password='******'
envoy_serial='******'
session_id=$(curl -X POST http://enlighten.enphaseenergy.com/login/login.json? -F "user[email]=$user" -F "user[password]=$password" | jq -r ".session_id")
echo $session_id
web_token=$(curl -X POST http://entrez.enphaseenergy.com/tokens -H "Content-Type: application/json" -d "{\"session_id\": \"$session_id\", \"serial_num\": \"$envoy_serial\",\"username\": \"$user\"}")
echo $web_token
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
100   468  100   171  100   297    802   1393 --:--:-- --:--:-- --:--:--  2186
parse error: Invalid numeric literal at line 1, column 7

  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
100   262  100   171  100    91    867    461 --:--:-- --:--:-- --:--:--  1329
 </html>nter>nginx/1.17.8</center>t</h1></center>d>

De curl post naar http://enlighten.enphaseenergy.com/login/login.json geeft geen sessie id terug, maar een redirect.

code:

curl -X POST http://enlighten.enphaseenergy.com/login/login.json? -F "user[email]=$user" -F "user[password]=$password" -v
Note: Unnecessary use of -X or --request, POST is already inferred.
*   Trying 52.7.205.78:80...
* Connected to enlighten.enphaseenergy.com (52.7.205.78) port 80 (#0)
> POST /login/login.json? HTTP/1.1
> Host: enlighten.enphaseenergy.com
> User-Agent: curl/7.81.0
> Accept: */*
> Content-Length: 297
> Content-Type: multipart/form-data; boundary=------------------------f9ec1078c12674c9
>
* We are completely uploaded and fine
* Mark bundle as not supporting multiuse
< HTTP/1.1 308 Permanent Redirect
< Date: Sun, 24 Mar 2024 09:29:19 GMT
< Content-Type: text/html
< Content-Length: 171
< Connection: keep-alive
< Location: https://enlighten.enphaseenergy.com/login/login.json?
<
<html>
<head><title>308 Permanent Redirect</title></head>
<body>
<center><h1>308 Permanent Redirect</h1></center>
<hr><center>nginx/1.17.8</center>
</body>
</html>
* Connection #0 to host enlighten.enphaseenergy.com left intact

Als ik via de browser inlog op die site krijg ik gewoon online de data van de Envoy te zien, want dat is waar die redirect naar verwijst.

Is er iemand bij wie het nog wel werkt?
Heeft Enphase de API veranderd ineens of is het gewoon een verstoring?

Bij mij werkt het in HA (envoy installer integratie, https://github.com/vincen...t_enphase_envoy_installer).


HASSOS, 2024.3.2

[Kaspers]

Wilde net even een aanpassing doorvoeren via de array builder binnen enlighten manager. Ik heb een installer account en deze bestaat naast een installer account van 'Green Guys', mogelijk bij jullie bekend.

Ik constateer echter dat ik nergens wijzigingen op kan doorvoeren, alle wijzigingeknoppen zijn uitgegrijsd:



en zie ook deze melding bovenaan het dashboard:



Meer mensen deze ervaring?

[Copitano]

Kaspers schreef op zondag 24 maart 2024 @ 12:41:
Wilde net even een aanpassing doorvoeren via de array builder binnen enlighten manager. Ik heb een installer account en deze bestaat naast een installer account van 'Green Guys', mogelijk bij jullie bekend.

Ik constateer echter dat ik nergens wijzigingen op kan doorvoeren, alle wijzigingeknoppen zijn uitgegrijsd:

[Afbeelding]

en zie ook deze melding bovenaan het dashboard:

[Afbeelding]

Meer mensen deze ervaring?

Maandag even bellen met Enphase. Was bij mij ook het geval en hebben ze rechtgezet. Ik kan weer gewoon bij de array builder. Heb ze ook duidelijk gemaakt dat ik het niet op prijs stel dat ze zonder enige vorm van communicatie ongevraagd en ongewenst updates op mijn systeem zetten terwijl dat is uitgevinkt in de installer app. Maarja, trekken ze zich helemaal niets van aan.

[ta_chi79]

breew schreef op zondag 24 maart 2024 @ 11:50:
[...]


Bij mij werkt het in HA (envoy installer integratie, https://github.com/vincen...t_enphase_envoy_installer).
[Afbeelding]

HASSOS, 2024.3.2

Die kende ik nog niet, maar de authenticatie daarin was hetzelfde dus niet geprobeerd.

Uiteindelijk aan de praat gekregen door met m'n installer account (ipv m'n user account) aan te loggen en voila, ineens kwam ik er wel doorheen.

[mike123]

Copitano schreef op zondag 24 maart 2024 @ 00:38:
[...]

Bij mij is al geüpgrade naar V7 en ik heb het niet. Waarschijnlijk zijn dan de meterspoelen nodig. En die heb ik niet. Ik meet dat met een aparte kWh meter en bereken de bruto netto verbruiken met dzVents scripts.

Ik heb inderdaad 2 meetspoelen.

[Copitano]

@Lawrentz En weer een stapje dichterbij. Jou scripts 1 en 2 een beetje omgebouwd voor de 'GET http://{IQ Gateway_ip /ivp/pdm/energy' met dit resultaat in de CLI.

code:

local zonnepanelenNowIdx       = 801 -- Dummy Custom Sensor
local zonnepanelenTodayIdx     = 802 -- Dummy Custom Sensor
local zonnepanelenSevenDaysIdx = 803 -- Dummy Custom Sensor
local zonnepanelenLifetimeIdx  = 804 -- Dummy Custom Sensor

local wattsNow
local wattHoursToday
local wattHoursSevenDays
local wattHoursLifetime


return {
    on = {
        shellCommandResponses = {'productiePanelen'} 
    },

    logging = {
        level  = domoticz.LOG_INFO,
        marker = '031 Log PVProduction'
    },

    execute = function (domoticz, item)
        domoticz.log ('Triggered by 003 Get PV Production')

        if item.statusCode ~= 0 then domoticz.log ("item.statusCode: " .. item.statusCode) end 
        if item.json       ~= nil
        then
-- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
            wattsNow           =                       item.json .wattsNow
            wattHoursToday     = domoticz.utils.round((item.json .wattHoursToday     /    1000), 2)
            wattHoursSevenDays = domoticz.utils.round((item.json .wattHoursSevenDays /    1000), 2)
            wattHoursLifetime  = domoticz.utils.round((item.json .wattHoursLifetime  / 1000000), 2)
-- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
            domoticz.devices    (zonnepanelenNowIdx)       .updateCustomSensor (wattsNow)
            domoticz.devices    (zonnepanelenTodayIdx)     .updateCustomSensor (wattHoursToday)
            domoticz.devices    (zonnepanelenSevenDaysIdx) .updateCustomSensor (wattHoursSevenDays)
            domoticz.devices    (zonnepanelenLifetimeIdx)  .updateCustomSensor (wattHoursLifetime)
-- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
            domoticz.log        ('Opbrengst Nu........: ' .. item.json.wattsNow  .. ' Watt')
            domoticz.log        ('Opbrengst Vandaag...: ' .. wattHoursToday      .. ' kWh')
            domoticz.log        ('Opbrengst 7 dagen...: ' .. wattHoursSevenDays  .. ' kWh')
            domoticz.log        ('Opbrengst Lifetime..: ' .. wattHoursLifetime   .. ' MWh')
-- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
        else
            domoticz.log ('item.json == nil')
        end
    end
}

Echter nog niet in de devices in Dz.
Krijg ook nog een foutmelding in Dz log een foutmelding met iest van een komma of een {

code:

2024-03-24 14:51:01.111 Error: dzVents: Error: (3.1.8) 031 Log PVProduction: Error parsing json to LUA table: /home/pi/domoticz/dzVents/runtime/JSON.lua:1234: /home/pi/domoticz/dzVents/runtime/JSON.lua:808: expected comma or '}' at byte 712 of: {
2024-03-24 14:51:01.111 "production": {
2024-03-24 14:51:01.111 "pcu": {
2024-03-24 14:51:01.111 "wattHoursToday": 9014,
2024-03-24 14:51:01.111 "wattHoursSevenDays": 106246,
2024-03-24 14:51:01.111 "wattHoursLifetime": 23424842,
2024-03-24 14:51:01.111 "wattsNow": 1388
2024-03-24 14:51:01.111 },
2024-03-24 14:51:01.111 "rgm": {
2024-03-24 14:51:01.111 "wattHoursToday": 0,
2024-03-24 14:51:01.111 "wattHoursSevenDays": 0,
2024-03-24 14:51:01.111 "wattHoursLifetime": 0,
2024-03-24 14:51:01.111 "wattsNow": 0
2024-03-24 14:51:01.111 },
2024-03-24 14:51:01.111 "eim": {
2024-03-24 14:51:01.111 "wattHoursToday": 0,
2024-03-24 14:51:01.111 "wattHoursSevenDays": 0,
2024-03-24 14:51:01.111 "wattHoursLifetime": 0,
2024-03-24 14:51:01.111 "wattsNow": 0
2024-03-24 14:51:01.111 }
2024-03-24 14:51:01.111 },
2024-03-24 14:51:01.111 "consumption": {
2024-03-24 14:51:01.111 "eim": {
2024-03-24 14:51:01.111 "wattHoursToday": 0,
2024-03-24 14:51:01.111 "wattHoursSevenDays": 0,
2024-03-24 14:51:01.111 "wattHoursLifetime": 0,
2024-03-24 14:51:01.111 "wattsNow": 0
2024-03-24 14:51:01.111 }
2024-03-24 14:51:01.111 }

Het script ziet er nu zo uit.
Scripts 1 + 2 uitgezet scripts 5 + 6 ingeschakeld (met dezelfde idx-en.Voor de onderste 3 blokjes output heb ik geen idx-en aangemaakt omdat ik daar niets mee doe. Het gaat mij vooral om de items 1,3 en 4 van het eerste blokje output. Very close but not yet there

Iemand enig idee wat die foutmelding betekent ofwel waar moet die komma of '}' moet staan. Enige aanwijzing in de foutmelding byte 712 zegt mij niet zoveel.

[Lawrentz]

Copitano schreef op zondag 24 maart 2024 @ 15:09:
@Lawrentz En weer een stapje dichterbij.

Goed om te vernemen!

Jou scripts 1 en 2 een beetje omgebouwd voor de 'GET http://{IQ Gateway_ip /ivp/pdm/energy' met dit resultaat in de CLI.

code:

local zonnepanelenNowIdx       = 801 -- Dummy Custom Sensor
local zonnepanelenTodayIdx     = 802 -- Dummy Custom Sensor
local zonnepanelenSevenDaysIdx = 803 -- Dummy Custom Sensor
local zonnepanelenLifetimeIdx  = 804 -- Dummy Custom Sensor

local wattsNow
local wattHoursToday
local wattHoursSevenDays
local wattHoursLifetime


return {
    on = {
        shellCommandResponses = {'productiePanelen'} 
    },

    logging = {
        level  = domoticz.LOG_INFO,
        marker = '031 Log PVProduction'
    },

    execute = function (domoticz, item)
        domoticz.log ('Triggered by 003 Get PV Production')

        if item.statusCode ~= 0 then domoticz.log ("item.statusCode: " .. item.statusCode) end 
        if item.json       ~= nil
        then
-- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
            wattsNow           =                       item.json .wattsNow
            wattHoursToday     = domoticz.utils.round((item.json .wattHoursToday     /    1000), 2)
            wattHoursSevenDays = domoticz.utils.round((item.json .wattHoursSevenDays /    1000), 2)
            wattHoursLifetime  = domoticz.utils.round((item.json .wattHoursLifetime  / 1000000), 2)
-- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
            domoticz.devices    (zonnepanelenNowIdx)       .updateCustomSensor (wattsNow)
            domoticz.devices    (zonnepanelenTodayIdx)     .updateCustomSensor (wattHoursToday)
            domoticz.devices    (zonnepanelenSevenDaysIdx) .updateCustomSensor (wattHoursSevenDays)
            domoticz.devices    (zonnepanelenLifetimeIdx)  .updateCustomSensor (wattHoursLifetime)
-- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
            domoticz.log        ('Opbrengst Nu........: ' .. item.json.wattsNow  .. ' Watt')
            domoticz.log        ('Opbrengst Vandaag...: ' .. wattHoursToday      .. ' kWh')
            domoticz.log        ('Opbrengst 7 dagen...: ' .. wattHoursSevenDays  .. ' kWh')
            domoticz.log        ('Opbrengst Lifetime..: ' .. wattHoursLifetime   .. ' MWh')
-- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
        else
            domoticz.log ('item.json == nil')
        end
    end
}

Echter nog niet in de devices in Dz.
Krijg ook nog een foutmelding in Dz log een foutmelding met iest van een komma of een {

code:

2024-03-24 14:51:01.111 Error: dzVents: Error: (3.1.8) 031 Log PVProduction: Error parsing json to LUA table: /home/pi/domoticz/dzVents/runtime/JSON.lua:1234: /home/pi/domoticz/dzVents/runtime/JSON.lua:808: expected comma or '}' at byte 712 of: {
2024-03-24 14:51:01.111 "production": {
2024-03-24 14:51:01.111 "pcu": {
2024-03-24 14:51:01.111 "wattHoursToday": 9014,
2024-03-24 14:51:01.111 "wattHoursSevenDays": 106246,
2024-03-24 14:51:01.111 "wattHoursLifetime": 23424842,
2024-03-24 14:51:01.111 "wattsNow": 1388
2024-03-24 14:51:01.111 },
2024-03-24 14:51:01.111 "rgm": {
2024-03-24 14:51:01.111 "wattHoursToday": 0,
2024-03-24 14:51:01.111 "wattHoursSevenDays": 0,
2024-03-24 14:51:01.111 "wattHoursLifetime": 0,
2024-03-24 14:51:01.111 "wattsNow": 0
2024-03-24 14:51:01.111 },
2024-03-24 14:51:01.111 "eim": {
2024-03-24 14:51:01.111 "wattHoursToday": 0,
2024-03-24 14:51:01.111 "wattHoursSevenDays": 0,
2024-03-24 14:51:01.111 "wattHoursLifetime": 0,
2024-03-24 14:51:01.111 "wattsNow": 0
2024-03-24 14:51:01.111 }
2024-03-24 14:51:01.111 },
2024-03-24 14:51:01.111 "consumption": {
2024-03-24 14:51:01.111 "eim": {
2024-03-24 14:51:01.111 "wattHoursToday": 0,
2024-03-24 14:51:01.111 "wattHoursSevenDays": 0,
2024-03-24 14:51:01.111 "wattHoursLifetime": 0,
2024-03-24 14:51:01.111 "wattsNow": 0
2024-03-24 14:51:01.111 }
2024-03-24 14:51:01.111 }

Het script ziet er nu zo uit.
Scripts 1 + 2 uitgezet scripts 5 + 6 ingeschakeld (met dezelfde idx-en.Voor de onderste 3 blokjes output heb ik geen idx-en aangemaakt omdat ik daar niets mee doe. Het gaat mij vooral om de items 1,3 en 4 van het eerste blokje output. Very close but not yet there

Iemand enig idee wat die foutmelding betekent ofwel waar moet die komma of '}' moet staan. Enige aanwijzing in de foutmelding byte 712 zegt mij niet zoveel.

Jouw API heb ik niet en is het een een beetje "leren zwemmen zonder zwembad" voor mij.
Wat ik zie is dat jouw nested objects wel namen/tags hebben.
Dan denk ik zo dat je het volgende nodig hebt:

code:

            domoticz.log        ('-- -- -- -- -- -- -- -- -- -- -- -- --')
            domoticz.log        (item.json .production)
            domoticz.log        ('-- -- -- -- -- -- -- -- -- -- -- -- --')
            domoticz.log        (item.json .production .pcu)
            domoticz.log        ('-- -- -- -- -- -- -- -- -- -- -- -- --')

            wattsNow           =                       item.json .production .pcu .wattsNow
            wattHoursToday     = domoticz.utils.round((item.json .production .pcu .wattHoursToday     /    1000), 2)
            wattHoursSevenDays = domoticz.utils.round((item.json .production .pcu .wattHoursSevenDays /    1000), 2)
            wattHoursLifetime  = domoticz.utils.round((item.json .production .pcu .wattHoursLifetime  / 1000000), 2)

De nieuwe logregels zijn bedoeld om te kijken of je bij elke stap een niveau dieper komt en het blokje eronder daarop aanpassen.
Deze nieuwe logregels kunnen na gedane arbeid worden uitgeremd of worden verwijderd.

[Copitano]

Lawrentz schreef op zondag 24 maart 2024 @ 15:33:
[...]

Goed om te vernemen!

[...]

Jouw API heb ik niet en is het een een beetje "leren zwemmen zonder zwembad" voor mij.
Wat ik zie is dat jouw nested objects wel namen/tags hebben.
Dan denk ik zo dat je het volgende nodig hebt:

code:

            domoticz.log        ('-- -- -- -- -- -- -- -- -- -- -- -- --')
            domoticz.log        (item.json .production)
            domoticz.log        ('-- -- -- -- -- -- -- -- -- -- -- -- --')
            domoticz.log        (item.json .production .pcu)
            domoticz.log        ('-- -- -- -- -- -- -- -- -- -- -- -- --')

            wattsNow           =                       item.json .production .pcu .wattsNow
            wattHoursToday     = domoticz.utils.round((item.json .production .pcu .wattHoursToday     /    1000), 2)
            wattHoursSevenDays = domoticz.utils.round((item.json .production .pcu .wattHoursSevenDays /    1000), 2)
            wattHoursLifetime  = domoticz.utils.round((item.json .production .pcu .wattHoursLifetime  / 1000000), 2)

De nieuwe logregels zijn bedoeld om te kijken of je bij elke stap een niveau dieper komt en het blokje eronder daarop aanpassen.
Deze nieuwe logregels kunnen na gedane arbeid worden uitgeremd of worden verwijderd.

Dank voor het geduld om mij te helpen
Ik ga er mee aan de slag. Het lijkt nog een klein stapje. Wat ik inmiddels wel uit de CLI kan halen is dat het token in ieder geval tot maart volgend jaar geldig blijft.

[Copitano]

@Lawrentz Ik heb er de vinger nog niet achter kunnen krijgen. Alles wat ik geprobeerd heb geeft hetzelfde resultaat. Production vervangen door energy in verschillende varianten met en zonder spatie met en zonder .pcu. De logregels leveren niets op in het log. Het gaat denk ik vooral hierom:

code:

Error: dzVents: Error: (3.1.8) 031 Log PVProduction: Error parsing json to LUA table: /home/pi/domoticz/dzVents/runtime/JSON.lua:1234: /home/pi/domoticz/dzVents/runtime/JSON.lua:808: expected comma or '}' at byte 711 of:

Het lijkt alsof de regels waar de waarde moet worden overgedragen aan de devices niet eens wordt bereikt en het programma stopt / naar end gaat na '031 Log PV Production'. De foutmelding lijkt te zeggen dat daar een komma of } wordt verwacht en dat een json tabel niet gevuld kan worden, maar dat gaat voorlopig even boven mijn pet. Echter als ik die komma achter '031 Log PV Production' zet met of zonder spatie krijg ik andere foutmeldingen en zie ik ook de resultaten niet meer onder de foutmelding. Het begint nu donkerder te worden en dan komt er sowieso niets meer binnen. Vanavond maar eens flink googlen De oplossing kan nooit ver weg zijn als ik de waardes wel kan zien onder de foutmelding.

[Lawrentz]

Copitano schreef op zondag 24 maart 2024 @ 15:09:
@Lawrentz
Echter nog niet in de devices in Dz.
Krijg ook nog een foutmelding in Dz log een foutmelding met iest van een komma of een {

code:

2024-03-24 14:51:01.111 Error: dzVents: Error: (3.1.8) 031 Log PVProduction: Error parsing json to LUA table: /home/pi/domoticz/dzVents/runtime/JSON.lua:1234: /home/pi/domoticz/dzVents/runtime/JSON.lua:808: expected comma or '}' at byte 712 of: {
2024-03-24 14:51:01.111 "production": {
2024-03-24 14:51:01.111 "pcu": {
2024-03-24 14:51:01.111 "wattHoursToday": 9014,
2024-03-24 14:51:01.111 "wattHoursSevenDays": 106246,
2024-03-24 14:51:01.111 "wattHoursLifetime": 23424842,
2024-03-24 14:51:01.111 "wattsNow": 1388
2024-03-24 14:51:01.111 },
2024-03-24 14:51:01.111 "rgm": {
2024-03-24 14:51:01.111 "wattHoursToday": 0,
2024-03-24 14:51:01.111 "wattHoursSevenDays": 0,
2024-03-24 14:51:01.111 "wattHoursLifetime": 0,
2024-03-24 14:51:01.111 "wattsNow": 0
2024-03-24 14:51:01.111 },
2024-03-24 14:51:01.111 "eim": {
2024-03-24 14:51:01.111 "wattHoursToday": 0,
2024-03-24 14:51:01.111 "wattHoursSevenDays": 0,
2024-03-24 14:51:01.111 "wattHoursLifetime": 0,
2024-03-24 14:51:01.111 "wattsNow": 0
2024-03-24 14:51:01.111 }
2024-03-24 14:51:01.111 },
2024-03-24 14:51:01.111 "consumption": {
2024-03-24 14:51:01.111 "eim": {
2024-03-24 14:51:01.111 "wattHoursToday": 0,
2024-03-24 14:51:01.111 "wattHoursSevenDays": 0,
2024-03-24 14:51:01.111 "wattHoursLifetime": 0,
2024-03-24 14:51:01.111 "wattsNow": 0
2024-03-24 14:51:01.111 }
2024-03-24 14:51:01.111 }

Het script ziet er nu zo uit.
Scripts 1 + 2 uitgezet scripts 5 + 6 ingeschakeld (met dezelfde idx-en.Voor de onderste 3 blokjes output heb ik geen idx-en aangemaakt omdat ik daar niets mee doe. Het gaat mij vooral om de items 1,3 en 4 van het eerste blokje output. Very close but not yet there

Iemand enig idee wat die foutmelding betekent ofwel waar moet die komma of '}' moet staan. Enige aanwijzing in de foutmelding byte 712 zegt mij niet zoveel.

Ik heb de logging omgezet in een json validator en zie dat achteraan een derde '}' ontbreekt.
Dit zou 'm moeten zijn:

code:

{"production": 
  {"pcu":     
    {"wattHoursToday": 9014
    ,"wattHoursSevenDays": 106246
    ,"wattHoursLifetime": 23424842
    ,"wattsNow": 1388
    }
  ,"rgm": 
    {"wattHoursToday": 0
    ,"wattHoursSevenDays": 0
    ,"wattHoursLifetime": 0
    ,"wattsNow": 0 
    }
  ,"eim": 
    {"wattHoursToday": 0
    ,"wattHoursSevenDays": 0 
    ,"wattHoursLifetime": 0
    ,"wattsNow": 0 
    } 
  }
 ,"consumption": 
  {"eim": 
    {"wattHoursToday": 0
    ,"wattHoursSevenDays": 0
    ,"wattHoursLifetime": 0
    ,"wattsNow": 0 
    }
  }
}

Dan de vraag hoe het kan dat die derde '}' ontbreekt

[Lawrentz]

Copitano schreef op zondag 24 maart 2024 @ 18:46:
@Lawrentz Ik heb er de vinger nog niet achter kunnen krijgen. Alles wat ik geprobeerd heb geeft hetzelfde resultaat. Production vervangen door energy in verschillende varianten

Dat gaat niet werken vanwege je json die begint met production.

met en zonder spatie met en zonder .pcu.

Met of zonder spaties maakt geen verschil. Dat kan ik je garanderen.
De pcu heb je na de production nodig om bij de "wattHoursToday", "wattHoursSevenDays", "wattHoursLifetime", "wattsNow" te komen.

De logregels leveren niets op in het log. Het gaat denk ik vooral hierom:

code:

Error: dzVents: Error: (3.1.8) 031 Log PVProduction: Error parsing json to LUA table: /home/pi/domoticz/dzVents/runtime/JSON.lua:1234: /home/pi/domoticz/dzVents/runtime/JSON.lua:808: expected comma or '}' at byte 711 of:

Het lijkt alsof de regels waar de waarde moet worden overgedragen aan de devices niet eens wordt bereikt en het programma stopt / naar end gaat na '031 Log PV Production'. De foutmelding lijkt te zeggen dat daar een komma of } wordt verwacht en dat een json tabel niet gevuld kan worden, maar dat gaat voorlopig even boven mijn pet. Echter als ik die komma achter '031 Log PV Production' zet met of zonder spatie krijg ik andere foutmeldingen en zie ik ook de resultaten niet meer onder de foutmelding. Het begint nu donkerder te worden en dan komt er sowieso niets meer binnen. Vanavond maar eens flink googlen De oplossing kan nooit ver weg zijn als ik de waardes wel kan zien onder de foutmelding.

Wat je kan doen is het script voor nu even uitzetten en een nieuw script maken met dezelfde 'shellCommandResponses =' waar je in kan experimenteren.
Ik twijfel namelijk of je gegevens wel als json binnenkomen.
Ik denk dat het losse regels zijn die gezamenlijk een json zouden moeten voorstellen.
En dan wordt het wat ingewikkelder.

code:

return {
    on = {
        shellCommandResponses = {'inverters'} -- must match with the callback passed to the executeShell command
    },

    logging = {
        level  = domoticz.LOG_INFO,
        marker = '029 Log Inverters'
    },

    execute = function (domoticz, item)

        domoticz.log        ('Triggered by 002 Get Inverters')
        domoticz.log        ('-- -- -- -- -- -- -- -- -- -- -- -- --')
        domoticz.log        (item)
        domoticz.log        ('-- -- -- -- -- -- -- -- -- -- -- -- --')
        domoticz.log        (item .statusCode)
        domoticz.log        ('-- -- -- -- -- -- -- -- -- -- -- -- --')
        domoticz.log        (item .json)
        domoticz.log        ('-- -- -- -- -- -- -- -- -- -- -- -- --')
        domoticz.log        (item .json .production)
        domoticz.log        ('-- -- -- -- -- -- -- -- -- -- -- -- --')
        domoticz.log        (item .json .production .pcu)
        domoticz.log        ('-- -- -- -- -- -- -- -- -- -- -- -- --')
            
    end
}

Die json zou als een lange string moeten zijn in (item).

code:

{["isShellCommandResponse"]=true, ["json"]={{["lastReportDate"]=1711303945, ["maxReportWatts"]=322, ["serialNumber"]="12214000001", ["devType"]=1, ["lastReportWatts"]=0}, {["lastReportDate"]=1711303526, ["maxReportWatts"]=315, ["serialNumber"]="12214000002", ["devType"]=1, ["lastReportWatts"]=0}, {["lastReportDate"]=1711303431, ["maxReportWatts"]=316, ["serialNumber"]="12214000003", ["devType"]=1, ["lastReportWa..........

Wanneer ik in mijn script 'item.data' aanroep gebeurt hetzelfde als in jouw logging.
Daar kunnen we ook wel wat mee maar met een echte json is het een stuk gemakkelijker.

[ Voor 6% gewijzigd door Lawrentz op 24-03-2024 22:43 ]

[Copitano]

Lawrentz schreef op zondag 24 maart 2024 @ 22:13:
Dat gaat niet werken vanwege je json die begint met production.

Okay, dat had ik inmiddels al teruggezet. Het gaf eerder geen andere output. Dus er moet nog iets zijn.

Met of zonder spaties maakt geen verschil. Dat kan ik je garanderen.
De pcu heb je na de production nodig om bij de "wattHoursToday", "wattHoursSevenDays", "wattHoursLifetime", "wattsNow" te komen.

Dan ga ik dat er weer inzetten. Dat gaf vanmiddag ook geen verschil in output. Dus next

Wat je kan doen is het script voor nu even uitzetten en een nieuw script maken met dezelfde 'shellCommandResponses =' waar je in kan experimenteren.
Ik twijfel namelijk of je gegevens wel als json binnenkomen.
Ik denk dat het losse regels zijn die gezamenlijk een json zouden moeten voorstellen.
En dan wordt het wat ingewikkelder.

Het draait al op een 'expirimenteer Pi', maar ik zal een kopie maken om in te expirimenteren en deze even uit zetten. Kunnen we altijd weer terug naar het oorspronkelijke vertrekpunt.

code:

return {
    on = {
        shellCommandResponses = {'inverters'} -- must match with the callback passed to the executeShell command
    },

    logging = {
        level  = domoticz.LOG_INFO,
        marker = '029 Log Inverters'
    },

    execute = function (domoticz, item)

        domoticz.log        ('Triggered by 002 Get Inverters')
        domoticz.log        ('-- -- -- -- -- -- -- -- -- -- -- -- --')
        domoticz.log        (item)
        domoticz.log        ('-- -- -- -- -- -- -- -- -- -- -- -- --')
        domoticz.log        (item .statusCode)
        domoticz.log        ('-- -- -- -- -- -- -- -- -- -- -- -- --')
        domoticz.log        (item .json)
        domoticz.log        ('-- -- -- -- -- -- -- -- -- -- -- -- --')
        domoticz.log        (item .json .production)
        domoticz.log        ('-- -- -- -- -- -- -- -- -- -- -- -- --')
        domoticz.log        (item .json .production .pcu)
        domoticz.log        ('-- -- -- -- -- -- -- -- -- -- -- -- --')
            
    end
}

Die json zou als een lange string moeten zijn in (item).

code:

{["isShellCommandResponse"]=true, ["json"]={{["lastReportDate"]=1711303945, ["maxReportWatts"]=322, ["serialNumber"]="12214000001", ["devType"]=1, ["lastReportWatts"]=0}, {["lastReportDate"]=1711303526, ["maxReportWatts"]=315, ["serialNumber"]="12214000002", ["devType"]=1, ["lastReportWatts"]=0}, {["lastReportDate"]=1711303431, ["maxReportWatts"]=316, ["serialNumber"]="12214000003", ["devType"]=1, ["lastReportWa..........

Wanneer ik in mijn script 'item.data' aanroep gebeurt hetzelfde als in jouw logging.
Daar kunnen we ook wel wat mee maar met een echte json is het een stuk gemakkelijker.

Gekke is eigenlijk dat het script een exacte kopie is van jou tweede script behalve dan de api. Heb het wel tien keer teken voor teken met elkaar vergeleken. Raar dat deze dan ergens een komma of } extra moet hebben. Het lijkt (voor mij dan) als het zoeken naar een speld in een hooiberg. Ben nog heel erg beginner in dzVents. Lenen en aanpassen lukt vaak nog wel maar deze is (nog) net even te hoog gegepen voor mij, maar ik leer graag van anderen

Geen idee of dit help, maar dit krijg ik via de CLI

code:

pi@raspberrypi:~ $  curl -f -k -H 'Authorization: Bearer MyToken' https://MyIP/ivp/pdm/energy
{
    "production": {
        "pcu": {
            "wattHoursToday": 12430,
            "wattHoursSevenDays": 106246,
            "wattHoursLifetime": 23428264,
            "wattsNow": 337
        },
        "rgm": {
            "wattHoursToday": 0,
            "wattHoursSevenDays": 0,
            "wattHoursLifetime": 0,
            "wattsNow": 0
        },
        "eim": {
            "wattHoursToday": 0,
            "wattHoursSevenDays": 0,
            "wattHoursLifetime": 0,
            "wattsNow": 0
        }
    },
    "consumption": {
        "eim": {
            "wattHoursToday": 0,
            "wattHoursSevenDays": 0,
            "wattHoursLifetime": 0,
            "wattsNow": 0
        }
    }
}pi@raspberrypi:~ $

Wat mij opvalt is dat de laatst haak voor pi@etc. staat en niet daarboven.

[ Voor 20% gewijzigd door Copitano op 24-03-2024 23:33 ]

[RichieB]

@Lawrentz & @Copitano Misschien kunnen jullie een eigen topic aanmaken in Smarthome ? Want dit heeft weinig meer met de Enphase Envoy te maken. Een moderator kan jullie berichten dan verplaatsen.

[Copitano]

RichieB schreef op zondag 24 maart 2024 @ 23:35:
@Lawrentz & @Copitano Misschien kunnen jullie een eigen topic aanmaken in Smarthome ? Want dit heeft weinig meer met de Enphase Envoy te maken. Een moderator kan jullie berichten dan verplaatsen.

Misschien even het geheugen opfrissen https://gathering.tweaker...message/72389402#72389402
Past lijkt mij toch wel binnen het kader: Envoy / IQ Gateway lokaal uitlezen voor domotica

[ Voor 9% gewijzigd door Copitano op 24-03-2024 23:47 ]

[Lawrentz]

Copitano schreef op zondag 24 maart 2024 @ 23:14:
[...]

Okay, dat had ik inmiddels al teruggezet. Het gaf eerder geen andere output. Dus er moet nog iets zijn.


[...]

Dan ga ik dat er weer inzetten. Dat gaf vanmiddag ook geen verschil in output. Dus next


[...]


Het draait al op een 'expirimenteer Pi', maar ik zal een kopie maken om in te expirimenteren en deze even uit zetten. Kunnen we altijd weer terug naar het oorspronkelijke vertrekpunt.

code:

return {
    on = {
        shellCommandResponses = {'inverters'} -- must match with the callback passed to the executeShell command
    },

    logging = {
        level  = domoticz.LOG_INFO,
        marker = '029 Log Inverters'
    },

    execute = function (domoticz, item)

        domoticz.log        ('Triggered by 002 Get Inverters')
        domoticz.log        ('-- -- -- -- -- -- -- -- -- -- -- -- --')
        domoticz.log        (item)
        domoticz.log        ('-- -- -- -- -- -- -- -- -- -- -- -- --')
        domoticz.log        (item .statusCode)
        domoticz.log        ('-- -- -- -- -- -- -- -- -- -- -- -- --')
        domoticz.log        (item .json)
        domoticz.log        ('-- -- -- -- -- -- -- -- -- -- -- -- --')
        domoticz.log        (item .json .production)
        domoticz.log        ('-- -- -- -- -- -- -- -- -- -- -- -- --')
        domoticz.log        (item .json .production .pcu)
        domoticz.log        ('-- -- -- -- -- -- -- -- -- -- -- -- --')
            
    end
}

[...]


Gekke is eigenlijk dat het script een exacte kopie is van jou tweede script behalve dan de api. Heb het wel tien keer teken voor teken met elkaar vergeleken. Raar dat deze dan ergens een komma of } extra moet hebben. Het lijkt (voor mij dan) als het zoeken naar een speld in een hooiberg. Ben nog heel erg beginner in dzVents. Lenen en aanpassen lukt vaak nog wel maar deze is (nog) net even te hoog gegepen voor mij, maar ik leer graag van anderen

Geen idee of dit help, maar dit krijg ik via de CLI

code:

pi@raspberrypi:~ $  curl -f -k -H 'Authorization: Bearer MyToken' https://MyIP/ivp/pdm/energy
{
    "production": {
        "pcu": {
            "wattHoursToday": 12430,
            "wattHoursSevenDays": 106246,
            "wattHoursLifetime": 23428264,
            "wattsNow": 337
        },
        "rgm": {
            "wattHoursToday": 0,
            "wattHoursSevenDays": 0,
            "wattHoursLifetime": 0,
            "wattsNow": 0
        },
        "eim": {
            "wattHoursToday": 0,
            "wattHoursSevenDays": 0,
            "wattHoursLifetime": 0,
            "wattsNow": 0
        }
    },
    "consumption": {
        "eim": {
            "wattHoursToday": 0,
            "wattHoursSevenDays": 0,
            "wattHoursLifetime": 0,
            "wattsNow": 0
        }
    }
}pi@raspberrypi:~ $

Deze json is Ok.

Wat mij opvalt is dat de laatst haak voor pi@etc. staat en niet daarboven.

Dat maakt voor de werking niet uit.
Dat hooguit een EOL oid.

[Lawrentz]

Copitano schreef op zondag 24 maart 2024 @ 23:46:
[...]

Misschien even het geheugen opfrissen https://gathering.tweaker...message/72389402#72389402
Past lijkt mij toch wel binnen het kader: Envoy / IQ Gateway lokaal uitlezen voor domotica

Zo denk ik er ook over maar sta ook open voor andere suggesties.

Daarnaast hoop ik, zoals eerder gemeld, dat andere lezers ook wat hebben aan het aanroepen van een http request en verwerken van een json van Enphase.

[ Voor 16% gewijzigd door Lawrentz op 25-03-2024 07:53 ]

[Copitano]

Lawrentz schreef op maandag 25 maart 2024 @ 07:49:
[...]

Deze json is Ok.

[...]

Dat maakt voor de werking niet uit.
Dat hooguit een EOL oid.

Helaas zijn beide scripts vannacht gestopt met data doorgeven en moest ik van morgen voor beiden eerst opnieuw het token ophalen en inplakken. Kennelijk werk ik dus toch met het installateurstoken die maar 12 uur werkt. Per paneel loopt behalve het voorgaande goed. Totalen geeft nog steeds die foutmelding, maar wel met de waardes in de error tab, dus niet in de devices.

Ga in iedergeval maar eens bellen met Enphase of ze het vinkje om overal bij te kunnen in mijn eigenaar account even aan willen zetten. Die tokens zijn een jaar geldig. Maar dat is een andere kwestie.
Bij de status krijg ik dit in het log van Dz

code:

2024-03-25 17:19:01.289 Status: dzVents: Info: 031 Log PVProduction: ------ Start external script: Envoy6.lua: ShellCommandResponse: "productiePanelen"
2024-03-25 17:19:01.290 Status: dzVents: Info: 031 Log PVProduction: Triggered by 003 Get PV Production
2024-03-25 17:19:01.290 Status: dzVents: Info: 031 Log PVProduction: item.json == nil
2024-03-25 17:19:01.291 Status: dzVents: Info: 031 Log PVProduction: ------ Finished Envoy6.lua

Uit item.json == nil trek ik de conclusie dat het script hier via de if else niet toekomt aan het vullen van de devices. Ook heb ik het script nomaals letter voor leter vergeleken met het script voor de afzonderlijke panelen dat wel werkt. Daar zit geen verschil tussen behoudens dan de 'else....'. Het weg laten daarvan maakt uiteraard geen verschil.
Zou het zou kunnen zijn dat de komma of } waar Dz over zeurt zit in de json Envoy aanlevert op de uitvraag?

[ Voor 39% gewijzigd door Copitano op 25-03-2024 17:42 ]

[RichieB]

Copitano schreef op maandag 25 maart 2024 @ 14:02:
[...]

Zou het zou kunnen zijn dat de komma of } waar Dz over zeurt zit in de json Envoy aanlevert op de uitvraag?

Dat lijkt me heel sterk. Dan zou het ongeldige JSON zijn en alle scripts stuk gaan.

Wat helpt in dit soort situaties is een “debug” switch inbouwen die alle ruwe input/output naar bestand stuurt zodat je dat handmatig kan controleren.

[Copitano]

RichieB schreef op maandag 25 maart 2024 @ 22:28:
[...]

Dat lijkt me heel sterk. Dan zou het ongeldige JSON zijn en alle scripts stuk gaan.

Wat helpt in dit soort situaties is een “debug” switch inbouwen die alle ruwe input/output naar bestand stuurt zodat je dat handmatig kan controleren.

Ik kan simpele scripts maken en te lezen, maar voor het maken van een debug switch schiet mijn kennis nog tekort. Maar ik leer graag iets van meer ervaren mede tweakers

[RichieB]

Copitano schreef op zondag 24 maart 2024 @ 23:14:
[...]

Wat mij opvalt is dat de laatst haak voor pi@etc. staat en niet daarboven.

Dat komt omdat de Envoy de JSON niet afsluit met een newline. Die '}' is het laatste teken van het antwoord, daarna krijg je weer je shell prompt die begint met "pi@". De JSON is valide, dus dat is niet het probleem.

[RichieB]

Copitano schreef op zondag 24 maart 2024 @ 15:09:
[...]
Krijg ook nog een foutmelding in Dz log een foutmelding met iest van een komma of een {

code:

2024-03-24 14:51:01.111 Error: dzVents: Error: (3.1.8) 031 Log PVProduction: Error parsing json to LUA table: /home/pi/domoticz/dzVents/runtime/JSON.lua:1234: /home/pi/domoticz/dzVents/runtime/JSON.lua:808: expected comma or '}' at byte 712 of: {
2024-03-24 14:51:01.111 "production": {
2024-03-24 14:51:01.111 "pcu": {
2024-03-24 14:51:01.111 "wattHoursToday": 9014,
2024-03-24 14:51:01.111 "wattHoursSevenDays": 106246,
2024-03-24 14:51:01.111 "wattHoursLifetime": 23424842,
2024-03-24 14:51:01.111 "wattsNow": 1388
2024-03-24 14:51:01.111 },
2024-03-24 14:51:01.111 "rgm": {
2024-03-24 14:51:01.111 "wattHoursToday": 0,
2024-03-24 14:51:01.111 "wattHoursSevenDays": 0,
2024-03-24 14:51:01.111 "wattHoursLifetime": 0,
2024-03-24 14:51:01.111 "wattsNow": 0
2024-03-24 14:51:01.111 },
2024-03-24 14:51:01.111 "eim": {
2024-03-24 14:51:01.111 "wattHoursToday": 0,
2024-03-24 14:51:01.111 "wattHoursSevenDays": 0,
2024-03-24 14:51:01.111 "wattHoursLifetime": 0,
2024-03-24 14:51:01.111 "wattsNow": 0
2024-03-24 14:51:01.111 }
2024-03-24 14:51:01.111 },
2024-03-24 14:51:01.111 "consumption": {
2024-03-24 14:51:01.111 "eim": {
2024-03-24 14:51:01.111 "wattHoursToday": 0,
2024-03-24 14:51:01.111 "wattHoursSevenDays": 0,
2024-03-24 14:51:01.111 "wattHoursLifetime": 0,
2024-03-24 14:51:01.111 "wattsNow": 0
2024-03-24 14:51:01.111 }
2024-03-24 14:51:01.111 }

[...]

Het probleem hier is de extra "}" op regel 20. Die hoort daar niet en maakt de JSON invalid.

[Copitano]

RichieB schreef op maandag 25 maart 2024 @ 22:56:
[...]

Het probleem hier is de extra "}" op regel 20. Die hoort daar niet en maakt de JSON invalid.

Ik zie hem. Dat is het antwoord van Envoy. Dus daar kan ik niets aan veranderen denk ik behalve bellen met Enphase en hopen dat het wordt opgepakt.
Het staat dan zelfs fout in de technical brief op blz. 18/19.

[ Voor 40% gewijzigd door Copitano op 25-03-2024 23:55 ]

[aritmeester]

@RichieB @Copitano
Die accolade is niet teveel hoor, je moet de oorzaak ergens anders zoeken!
De roodomcirkelde accolade sluit "eim" af. De daarop volgende sluit "production" af.
Kijk maar bij het consumption blok uit de documentatie daar staan 'dezelfde' accolades.

[ Voor 7% gewijzigd door aritmeester op 26-03-2024 06:58 ]

[Lawrentz]

Copitano schreef op maandag 25 maart 2024 @ 22:35:
[...]

Ik kan simpele scripts maken en te lezen, maar voor het maken van een debug switch schiet mijn kennis nog tekort. Maar ik leer graag iets van meer ervaren mede tweakers

Zie https://www.domoticz.com/....80.A6_.7D_.28optional.29 voor de debug switch in je script.

Over het algemeen zet je de debug maar kort aan om een overdaad aan logging te voorkomen.

[ Voor 9% gewijzigd door Lawrentz op 26-03-2024 09:38 ]

[Lawrentz]

Copitano schreef op maandag 25 maart 2024 @ 23:03:
[...]

Ik zie hem. Dat is het antwoord van Envoy. Dus daar kan ik niets aan veranderen denk ik behalve bellen met Enphase en hopen dat het wordt opgepakt.
Het staat dan zelfs fout in de technical brief op blz. 18/19.
[Afbeelding]

Ter herinnering:
Die json zou als een lange string moeten zijn in (item).

code:

        domoticz.log        (item)

Van daaruit zou je verder kunnen werken naar een oplossing.
Graag jouw terugkoppeling hierop.

Wat je nu in je logging laat zien wordt bij mij getoond bij het gebruik van ...

code:

        domoticz.log        (item .data)

.
... met alle regels uit de json uitgesplitst op aparte regels.
Daar kunnen we ook wat mee maar dat is wat gecompliceerder en gebruik ik daarom liever een echte json..

[Copitano]

Lawrentz schreef op dinsdag 26 maart 2024 @ 09:37:
[...]

Zie https://www.domoticz.com/....80.A6_.7D_.28optional.29 voor de debug switch in je script.

Over het algemeen zet je de debug maar kort aan om een overdaad aan logging te voorkomen.

Kun je hier iets uit halen?

code:

2024-03-25 23:24:00.737 Status: EventSystem: Script event triggered: /home/pi/domoticz/dzVents/runtime/dzVents.lua
2024-03-25 23:24:00.938 Status: dzVents: Info: Handling shellcommandResponse-events for: "productiePanelen"
2024-03-25 23:24:00.938 Status: dzVents: Info: 031 Log PVProduction: ------ Start external script: Envoy6.lua: ShellCommandResponse: "productiePanelen"
2024-03-25 23:24:00.938 Status: dzVents: Info: 031 Log PVProduction: Triggered by 003 Get PVProduction
2024-03-25 23:24:00.938 Status: dzVents: Info: 031 Log PVProduction: -- -- -- -- -- -- -- -- -- -- -- -- --
2024-03-25 23:24:00.939 Status: dzVents: Info: 031 Log PVProduction: {["isXML"]=false, ["ok"]=false, ["isSystem"]=false, ["isSecurity"]=false, ["trigger"]="productiePanelen", ["isJSON"]=false, ["isShellCommandResponse"]=true, ["timeoutOccurred"]=false, ["dump"]=function, ["statusCode"]=22, ["isGroup"]=false, ["isDevice"]=false, ["isHTTPResponse"]=false, ["baseType"]="shellcommandResponse", ["errorText"]=" % Total % Received % Xferd Average Speed Time Time Time Current Dload Upload Total Spent Left Speed 0 0 0 0 0 0 0 0 --:--:-- --:--:-- --:--:-- 0 0 0 0 0 0 0 0 0 --:--:-- --:--:-- --:--:-- 0 0 0 0 0 0 0 0 0 --:--:-- --:--:-- --:--:-- 0curl: (22) The requested URL returned error: 401 Unauthorized", ["isScene"]=false, ["isHardware"]=false, ["hasLines"]=false, ["data"]="", ["isTimer"]=false, ["isCustomEvent"]=false, ["isVariable"]=false, ["callback"]="productiePanelen", ["shellCommandResponse"]="productiePanelen", ["statusText"]=" % Total % Received % Xferd Average Speed Time Time Time Current Dload Upload Total Spent Left Speed 0 0 0 0 0 0 0 0 --:--:-- --:--:-- --:--:-- 0 0 0 0 0 0 0 0 0 --:--:-- --:--:-- --:--:-- 0 0 0 0 0 0 0 0 0 --:--:-- --:--:-- --:--:-- 0curl: (22) The requested URL returned error: 401 Unauthorized"}
2024-03-25 23:24:00.939 Status: dzVents: Info: 031 Log PVProduction: -- -- -- -- -- -- -- -- -- -- -- -- --
2024-03-25 23:24:00.939 Status: dzVents: Info: 031 Log PVProduction: 22
2024-03-25 23:24:00.939 Status: dzVents: Info: 031 Log PVProduction: -- -- -- -- -- -- -- -- -- -- -- -- --
2024-03-25 23:24:00.939 Status: dzVents: Info: 031 Log PVProduction: nil
2024-03-25 23:24:00.939 Status: dzVents: Info: 031 Log PVProduction: -- -- -- -- -- -- -- -- -- -- -- -- --
2024-03-25 23:24:00.939 Status: dzVents: Info: 031 Log PVProduction: ------ Finished Envoy6.lua

[Lawrentz]

Copitano schreef op dinsdag 26 maart 2024 @ 11:45:
[...]

Kun je hier iets uit halen?

code:

2024-03-25 23:24:00.737 Status: EventSystem: Script event triggered: /home/pi/domoticz/dzVents/runtime/dzVents.lua
2024-03-25 23:24:00.938 Status: dzVents: Info: Handling shellcommandResponse-events for: "productiePanelen"
2024-03-25 23:24:00.938 Status: dzVents: Info: 031 Log PVProduction: ------ Start external script: Envoy6.lua: ShellCommandResponse: "productiePanelen"
2024-03-25 23:24:00.938 Status: dzVents: Info: 031 Log PVProduction: Triggered by 003 Get PVProduction
2024-03-25 23:24:00.938 Status: dzVents: Info: 031 Log PVProduction: -- -- -- -- -- -- -- -- -- -- -- -- --
2024-03-25 23:24:00.939 Status: dzVents: Info: 031 Log PVProduction: {["isXML"]=false, ["ok"]=false, ["isSystem"]=false, ["isSecurity"]=false, ["trigger"]="productiePanelen", ["isJSON"]=false, ["isShellCommandResponse"]=true, ["timeoutOccurred"]=false, ["dump"]=function, ["statusCode"]=22, ["isGroup"]=false, ["isDevice"]=false, ["isHTTPResponse"]=false, ["baseType"]="shellcommandResponse", ["errorText"]=" % Total % Received % Xferd Average Speed Time Time Time Current Dload Upload Total Spent Left Speed 0 0 0 0 0 0 0 0 --:--:-- --:--:-- --:--:-- 0 0 0 0 0 0 0 0 0 --:--:-- --:--:-- --:--:-- 0 0 0 0 0 0 0 0 0 --:--:-- --:--:-- --:--:-- 0curl: (22) The requested URL returned error: 401 Unauthorized", ["isScene"]=false, ["isHardware"]=false, ["hasLines"]=false, ["data"]="", ["isTimer"]=false, ["isCustomEvent"]=false, ["isVariable"]=false, ["callback"]="productiePanelen", ["shellCommandResponse"]="productiePanelen", ["statusText"]=" % Total % Received % Xferd Average Speed Time Time Time Current Dload Upload Total Spent Left Speed 0 0 0 0 0 0 0 0 --:--:-- --:--:-- --:--:-- 0 0 0 0 0 0 0 0 0 --:--:-- --:--:-- --:--:-- 0 0 0 0 0 0 0 0 0 --:--:-- --:--:-- --:--:-- 0curl: (22) The requested URL returned error: 401 Unauthorized"}
2024-03-25 23:24:00.939 Status: dzVents: Info: 031 Log PVProduction: -- -- -- -- -- -- -- -- -- -- -- -- --
2024-03-25 23:24:00.939 Status: dzVents: Info: 031 Log PVProduction: 22
2024-03-25 23:24:00.939 Status: dzVents: Info: 031 Log PVProduction: -- -- -- -- -- -- -- -- -- -- -- -- --
2024-03-25 23:24:00.939 Status: dzVents: Info: 031 Log PVProduction: nil
2024-03-25 23:24:00.939 Status: dzVents: Info: 031 Log PVProduction: -- -- -- -- -- -- -- -- -- -- -- -- --
2024-03-25 23:24:00.939 Status: dzVents: Info: 031 Log PVProduction: ------ Finished Envoy6.lua

code:

["isJSON"]=false
["errorText"]=" ........    : (22) The requested URL returned error: 401 Unauthorized",

[Copitano]

Lawrentz schreef op dinsdag 26 maart 2024 @ 12:14:
[...]

code:

["isJSON"]=false
["errorText"]=" ........    : (22) The requested URL returned error: 401 Unauthorized",

Juist.....
Dan werken de tokens, om het even user of installer, dus niet goed. Helpdesk Enphase bellen dus.

[RichieB]

aritmeester schreef op dinsdag 26 maart 2024 @ 06:57:
@RichieB @Copitano
Die accolade is niet teveel hoor, je moet de oorzaak ergens anders zoeken!
De roodomcirkelde accolade sluit "eim" af. De daarop volgende sluit "production" af.
Kijk maar bij het consumption blok uit de documentatie daar staan 'dezelfde' accolades.

Je heb helemaal gelijk.. ik keek niet goed. De JSON is valid dus de JSON foutmelding is nog onverklaard. Die luidt:

code:

expected comma or '}' at byte 712 of:

dan volgt een JSON string van nog geen 500 bytes. Mist daar inderdaad het afsluitende '}' ? Ook als je de URL met de hand aanroept?

[ Voor 16% gewijzigd door RichieB op 26-03-2024 17:40 ]

[Lawrentz]

Copitano schreef op dinsdag 26 maart 2024 @ 13:10:
[...]

Juist.....
Dan werken de tokens, om het even user of installer, dus niet goed. Helpdesk Enphase bellen dus.

Vergeet niet dat een klein verschil kan zijn tussen Dz en de CLI.
Vandaar altijd eerst een http request via de CLI proberen en vandaaruit naar Dz.
Als het Dz niet meer werkt dan toch maar weer dan weer terug naar de CLI.

Als dezelfde http request via de CLI als voorheen ook niet werkt dan kan je verder kijken.
Zoals eerder aangegeven, met verbose (-v) krijg je de meeste info.

Bij mij is dat incl

code:

*  start date: Jul  8 05:04:06 2023 GMT
*  expire date: Jul  7 05:04:06 2024 GMT

Dan weet ik ook wat me begin juli staat te wachten.
Sinds 8 juli heb ik geen nieuwe token meer nodig gehad.

Wat je via de CLI ook kan proberen of je token nog werkt:

code:

curl -f -k -H 'Authorization: Bearer MyToken' https://YourIP -v

Je krijgt dan geen data maar een 301 Moved Permanently als response code, maar dat is beter dan een 401 Unauthorized.

[Copitano]

Lawrentz schreef op dinsdag 26 maart 2024 @ 19:39:
[...]

Vergeet niet dat een klein verschil kan zijn tussen Dz en de CLI.
Vandaar altijd eerst een http request via de CLI proberen en vandaaruit naar Dz.
Als het Dz niet meer werkt dan toch maar weer dan weer terug naar de CLI.

Als dezelfde http request via de CLI als voorheen ook niet werkt dan kan je verder kijken.
Zoals eerder aangegeven, met verbose (-v) krijg je de meeste info.

Bij mij is dat incl

code:

*  start date: Jul  8 05:04:06 2023 GMT
*  expire date: Jul  7 05:04:06 2024 GMT

Dan weet ik ook wat me begin juli staat te wachten.
Sinds 8 juli heb ik geen nieuwe token meer nodig gehad.

Wat je via de CLI ook kan proberen of je token nog werkt:

code:

curl -f -k -H 'Authorization: Bearer MyToken' https://YourIP -v

Je krijgt dan geen data maar een 301 Moved Permanently als response code, maar dat is beter dan een 401 Unauthorized.

Ik zie je bericht nu pas. Even met andere zaken bezig geweest vandaag. Heb wel op advies van de Nederlandse helpdesk een mail gestuurd naar Enphase. Hoop op een positieve response.

Uit het CLI commando krijg ik dit

code:

*  start date: Mar 14 22:06:08 2024 GMT
*  expire date: Mar 14 22:06:08 2025 GMT

Toch merkwaardig. Ik wed dat ik morgen toch weer een nieuw token moet invoeren om de boel weer aan de praat te krijgen.

[Lawrentz]

Copitano schreef op woensdag 27 maart 2024 @ 00:46:
[...]

Ik zie je bericht nu pas. Even met andere zaken bezig geweest vandaag. Heb wel op advies van de Nederlandse helpdesk een mail gestuurd naar Enphase. Hoop op een positieve response.

Uit het CLI commando krijg ik dit

code:

*  start date: Mar 14 22:06:08 2024 GMT
*  expire date: Mar 14 22:06:08 2025 GMT

Toch merkwaardig. Ik wed dat ik morgen toch weer een nieuw token moet invoeren om de boel weer aan de praat te krijgen.

Waarom een nieuwe token?
De token is nog 50 weken geldig.

Ik denk echt dat het aan je http request ligt.
Probeer je token ook nog even met de http requests uit mijn eerste en derde script, ook al zijn de waarden in de json 0 (nul).

Zie ook je eigen http request in je post Copitano in "[Enphase] Envoy / IQ Gateway lokaal uitlezen voor domotica"

Daarnaast kan je kijken of deze api werkt en wat voor je oplevert

code:

curl -f -k -H 'Accept: application/json' -H 'Authorization: Bearer yourToken' https://192.168.x.y/api/v1/energy

Dat is het ongedocumenteerde broertje van

code:

curl -f -k -H 'Accept: application/json' -H 'Authorization: Bearer yourToken' https://192.168.x.y/ivp/pdm/energy

[ Voor 24% gewijzigd door Lawrentz op 27-03-2024 07:40 ]

[m.eddy]

m.eddy schreef op zaterdag 23 maart 2024 @ 15:30:
[...]


Zelf quote - heerlijk!

Na de upgrade naar V7 van de 12de viel het mij vandaag op dat er na de 19de niets meer geproduceerd was.
Gateway stond in error - Enphase maar eens gebeld dan - na zelf de spanning van de gateway gehaald te hebben. Ding bleef in error - bovenste led rood en onderste groen.

Van support moest ik beide knoppen op de gateway (standard) indrukken. Dit leek niets te doen. Uiteindelijk weer spanning van de gateway af en erop. Daarna nogmaals met de knoppen maar weer hetzelfde. Uiteindelijk sprong het bovenste ledje naar groen.
Support gaf toen aan dat de invertors geen profiel meer hadden en dat ze die opnieuw gepushd hadden. Daarna wachten of de productie op gang kwam (inmiddels 40 minuten in de call).

Zojuist kwamen ze met de melding dat het aan de hardware lag. De gateway zelf dus. Krijg onder rma een nieuwe. Wel vaag dat met alle firmware upgrades het uiteindelijk aan de hardware zou liggen.

Maarja het kan natuurlijk.


Edit: uiteraard heb ik het firmware verhaal aangehaald tijdens de call. Toen kwam dus naar boven dat dit de 12de én de 19de gebeurd is. Dus eerst van 5 naar 7 en de 19de dus naar nog een nieuwere 7 versie. Ik opperde dat het dan wel toevallig is dat de productie na de 19de stopt en dat het dan niet aan de firmware zou liggen maar aan de hardware…. Ze wilden niet uitsluiten dat het aan de firmware lag maar het zeker ook niet bevestigen. Later in het gesprek kwam dus het hardware verhaal.
Allemaal in Engels uiteraard. Nederlandse support alleen ma-vr blijkbaar.
Ben benieuwd of het systeem weer begint te draaien met de nieuwe gateway.

Echt de laatste zelf quote !

Puur om dit verhaal af te ronden. Gisteren kwam de nieuwe gateway binnen. Opgehangen en in de Toolkit app in het service menu de "Replace IQ Gateway" aangetikt. Dan even het oude en nieuwe serial scannen en het is geregeld.
Dit werkte wonderbaarlijk goed eigenlijk. Blijkbaar was de oude echt stuk - kapot gerepareerd door alle firmware updates blijkbaar.

[Pazo]

@m.eddy is die oude echt helemaal overleden? Of nog bruikbaar om mee te hobbyen? Lijk me interessant om te kijken of er firmware-technisch mee te rommelen is. Unit zou handig zijn om aan het internet te hangen, en dan met wireshark te monitoren waarmee de gateway allemaal connectie maakt, en dan kijken of tijdens vragen van updates de locatie van de firmwarebestanden te achterhalen is, om vervolgens te kijken of oudere versies los te downloaden zijn en dat te flashen, bij v7 terug naar v5 zetten. Ga ik met mijn huidige gateway natuurlijk niet doen.

[Copitano]

Pazo schreef op woensdag 27 maart 2024 @ 14:35:
@m.eddy is die oude echt helemaal overleden? Of nog bruikbaar om mee te hobbyen? Lijk me interessant om te kijken of er firmware-technisch mee te rommelen is. Unit zou handig zijn om aan het internet te hangen, en dan met wireshark te monitoren waarmee de gateway allemaal connectie maakt, en dan kijken of tijdens vragen van updates de locatie van de firmwarebestanden te achterhalen is, om vervolgens te kijken of oudere versies los te downloaden zijn en dat te flashen, bij v7 terug naar v5 zetten. Ga ik met mijn huidige gateway natuurlijk niet doen.

ha,ha,ha, ambitieus

[Pazo]

Copitano schreef op woensdag 27 maart 2024 @ 14:51:
[...]

ha,ha,ha, ambitieus

Ja, leuk toch om mee te rommelen?
Ik heb Wireshark als eens losgelaten op mijn gateway, en ben al meerdere pagina / API endpoints tegen gekomen die we nog niet kennen. Als de gateway een update moet doen, moet ie dat bestand binnenhalen vanaf de Enphase server zou je denken. Die moet dus te onderscheppen zijn, althans, de locatie waarvan het bestand gedownload wordt. Maar ik ga op mijn eigen gateway niet op de update knop drukken zolang ik op v5 zit

[Copitano]

Lawrentz schreef op woensdag 27 maart 2024 @ 07:02:
[...]

Waarom een nieuwe token?
De token is nog 50 weken geldig.

Zodra er geen data meer binnenkomt leek het voor mij aanvankelijk zo dat de 12 uur dat een 'installer' token geldig is, was verlopen. Zodra ik dan een nieuw token ophaalde en ingeplakt had werkte het in ieder geval voor de afzonderlijke panelen weer (jou scripts 3 en 4). Voor de door mij aangepaste scripts voor energy (5 +6) ipv production (jou scripts 1 + 2) met de foutmelding maar wel de gewenste data in de foutmelding. Ook als ik even wat anders probeer en vervolgens weer terugkeer naar het oorspronkelijke script met het werkende token, werkt het token in eens niet meer. Nieuwe er in en het loopt weer. Die datum van 14 maart zag ik ook pas nadat ik met de CLI aan de slag was gegaan.

Ik denk echt dat het aan je http request ligt.
Probeer je token ook nog even met de http requests uit mijn eerste en derde script, ook al zijn de waarden in de json 0 (nul).
Zie ook je eigen http request in je post Copitano in "[Enphase] Envoy / IQ Gateway lokaal uitlezen voor domotica"

Het derde script werkt dus wel steeds, maar voor beperkte tijd.
Het eerste script met energy ipv production en het werkende token van script 3 geeft deze foutmelding.

code:

2024-03-27 14:44:01.281 Error: dzVents: Error: (3.1.8) 028 Log PVPanels: An error occurred when calling event handler Envoy2
2024-03-27 14:44:01.281 Error: dzVents: Error: (3.1.8) 028 Log PVPanels: /home/pi/domoticz/scripts/dzVents/scripts/Envoy2.lua:30: attempt to perform arithmetic on a nil value (field 'wattHoursToday')

En die is anders dan eerder.

Daarnaast kan je kijken of deze api werkt en wat voor je oplevert

code:

curl -f -k -H 'Accept: application/json' -H 'Authorization: Bearer yourToken' https://192.168.x.y/api/v1/energy

Dat is het ongedocumenteerde broertje van

code:

curl -f -k -H 'Accept: application/json' -H 'Authorization: Bearer yourToken' https://192.168.x.y/ivp/pdm/energy

Met script 5+6

code:

pi@raspberrypi:~ $ curl -f -k -H 'Authorization: Bearer MyToken' https://192.168.x.xxx/api/v1/energy -v
* Expire in 0 ms for 6 (transfer 0x15ac950)
*   Trying 192.168.x.xxx...
* TCP_NODELAY set
* Expire in 200 ms for 4 (transfer 0x15ac950)
* Connected to 192.168.x.xxx (192.168.x.xxx) port 443 (#0)
* ALPN, offering h2
* ALPN, offering http/1.1
* successfully set certificate verify locations:
*   CAfile: none
  CApath: /etc/ssl/certs
* TLSv1.3 (OUT), TLS handshake, Client hello (1):
* TLSv1.3 (IN), TLS handshake, Server hello (2):
* NPN, negotiated HTTP1.1
* TLSv1.2 (IN), TLS handshake, Certificate (11):
* TLSv1.2 (IN), TLS handshake, Server key exchange (12):
* TLSv1.2 (IN), TLS handshake, Server finished (14):
* TLSv1.2 (OUT), TLS handshake, Client key exchange (16):
* TLSv1.2 (OUT), TLS change cipher, Change cipher spec (1):
* TLSv1.2 (OUT), TLS handshake, Next protocol (67):
* TLSv1.2 (OUT), TLS handshake, Finished (20):
* TLSv1.2 (IN), TLS handshake, Finished (20):
* SSL connection using TLSv1.2 / ECDHE-RSA-AES256-GCM-SHA384
* ALPN, server did not agree to a protocol
* Server certificate:
*  subject: CN=envoy-122xxxxxxxxx
*  start date: Mar 14 22:06:08 2024 GMT
*  expire date: Mar 14 22:06:08 2025 GMT
*  issuer: CN=envoy-122xxxxxxxxx
*  SSL certificate verify result: self signed certificate (18), continuing anyway.
> GET /api/v1/energy HTTP/1.1
> Host: 192.168.x.xxx
> User-Agent: curl/7.64.0
> Accept: */*
> Authorization: Bearer MyToken
> 
< HTTP/1.1 200 OK
< Server: openresty/1.17.8.1
< Date: Wed, 27 Mar 2024 12:32:45 GMT
< Content-Type: application/json
< Content-Length: 274
< Connection: keep-alive
< Set-Cookie: sessionId=nD3FxiZhfWlRhdQFc9a2OL1380z3Dj4W; Secure; HttpOnly; path=/
< Strict-Transport-Security: max-age=63072000; includeSubdomains
< X-Frame-Options: DENY
< X-Content-Type-Options: nosniff
< 
[
  {
    "type": "Production",
    "wattHoursToday": 0,
    "wattHoursSevenDays": 0,
    "wattHoursLifetime": 0,
    "wattsNow": 0
  },
  {
    "type": "Consumption",
    "wattHoursToday": 0,
    "wattHoursSevenDays": 0,
    "wattHoursLifetime": 0,
    "wattsNow": 0
  }
]
* Connection #0 to host 192.168.x.xxx left intact

Foutmelding in het Dz log:

code:

2024-03-27 13:28:01.252 Error: dzVents: Error: (3.1.8) 031 Log PVProduction: An error occurred when calling event handler Envoy6
2024-03-27 13:28:01.252 Error: dzVents: Error: (3.1.8) 031 Log PVProduction: /home/pi/domoticz/scripts/dzVents/scripts/Envoy6.lua:29: attempt to index a nil value (field 'production')

[Copitano]

Pazo schreef op woensdag 27 maart 2024 @ 14:57:
[...]


Ja, leuk toch om mee te rommelen?
Ik heb Wireshark als eens losgelaten op mijn gateway, en ben al meerdere pagina / API endpoints tegen gekomen die we nog niet kennen. Als de gateway een update moet doen, moet ie dat bestand binnenhalen vanaf de Enphase server zou je denken. Die moet dus te onderscheppen zijn, althans, de locatie waarvan het bestand gedownload wordt. Maar ik ga op mijn eigen gateway niet op de update knop drukken zolang ik op v5 zit

Nou inderdaad. D7 geeft hier een hoop uitzoekwerk om de data in Dz te krijgen. Maar dat was je waarschijnlijk niet ontgaan

[Lawrentz]

Copitano schreef op woensdag 27 maart 2024 @ 15:10:
[...]

Zodra er geen data meer binnenkomt leek het voor mij aanvankelijk zo dat de 12 uur dat een 'installer' token geldig is, was verlopen. Zodra ik dan een nieuw token ophaalde en ingeplakt had werkte het in ieder geval voor de afzonderlijke panelen weer (jou scripts 3 en 4). Voor de door mij aangepaste scripts voor energy (5 +6) ipv production (jou scripts 1 + 2) met de foutmelding maar wel de gewenste data in de foutmelding. Ook als ik even wat anders probeer en vervolgens weer terugkeer naar het oorspronkelijke script met het werkende token, werkt het token in eens niet meer. Nieuwe er in en het loopt weer. Die datum van 14 maart zag ik ook pas nadat ik met de CLI aan de slag was gegaan.

[...]

Het derde script werkt dus wel steeds, maar voor beperkte tijd.
Het eerste script met energy ipv production en het werkende token van script 3 geeft deze foutmelding.

code:

2024-03-27 14:44:01.281 Error: dzVents: Error: (3.1.8) 028 Log PVPanels: An error occurred when calling event handler Envoy2
2024-03-27 14:44:01.281 Error: dzVents: Error: (3.1.8) 028 Log PVPanels: /home/pi/domoticz/scripts/dzVents/scripts/Envoy2.lua:30: attempt to perform arithmetic on a nil value (field 'wattHoursToday')

En die is anders dan eerder.


[...]

Met script 5+6

code:

pi@raspberrypi:~ $ curl -f -k -H 'Authorization: Bearer MyToken' https://192.168.x.xxx/api/v1/energy -v
* Expire in 0 ms for 6 (transfer 0x15ac950)
*   Trying 192.168.x.xxx...
* TCP_NODELAY set
* Expire in 200 ms for 4 (transfer 0x15ac950)
* Connected to 192.168.2.112 (192.168.x.xxx) port 443 (#0)
* ALPN, offering h2
* ALPN, offering http/1.1
* successfully set certificate verify locations:
*   CAfile: none
  CApath: /etc/ssl/certs
* TLSv1.3 (OUT), TLS handshake, Client hello (1):
* TLSv1.3 (IN), TLS handshake, Server hello (2):
* NPN, negotiated HTTP1.1
* TLSv1.2 (IN), TLS handshake, Certificate (11):
* TLSv1.2 (IN), TLS handshake, Server key exchange (12):
* TLSv1.2 (IN), TLS handshake, Server finished (14):
* TLSv1.2 (OUT), TLS handshake, Client key exchange (16):
* TLSv1.2 (OUT), TLS change cipher, Change cipher spec (1):
* TLSv1.2 (OUT), TLS handshake, Next protocol (67):
* TLSv1.2 (OUT), TLS handshake, Finished (20):
* TLSv1.2 (IN), TLS handshake, Finished (20):
* SSL connection using TLSv1.2 / ECDHE-RSA-AES256-GCM-SHA384
* ALPN, server did not agree to a protocol
* Server certificate:
*  subject: CN=envoy-122xxxxxxxxx
*  start date: Mar 14 22:06:08 2024 GMT
*  expire date: Mar 14 22:06:08 2025 GMT
*  issuer: CN=envoy-122xxxxxxxxx
*  SSL certificate verify result: self signed certificate (18), continuing anyway.
> GET /api/v1/energy HTTP/1.1
> Host: 192.168.x.xxx
> User-Agent: curl/7.64.0
> Accept: */*
> Authorization: Bearer MyToken
> 
< HTTP/1.1 200 OK
< Server: openresty/1.17.8.1
< Date: Wed, 27 Mar 2024 12:32:45 GMT
< Content-Type: application/json
< Content-Length: 274
< Connection: keep-alive
< Set-Cookie: sessionId=nD3FxiZhfWlRhdQFc9a2OL1380z3Dj4W; Secure; HttpOnly; path=/
< Strict-Transport-Security: max-age=63072000; includeSubdomains
< X-Frame-Options: DENY
< X-Content-Type-Options: nosniff
< 
[
  {
    "type": "Production",
    "wattHoursToday": 0,
    "wattHoursSevenDays": 0,
    "wattHoursLifetime": 0,
    "wattsNow": 0
  },
  {
    "type": "Consumption",
    "wattHoursToday": 0,
    "wattHoursSevenDays": 0,
    "wattHoursLifetime": 0,
    "wattsNow": 0
  }
]
* Connection #0 to host 192.168.x.xxx left intact

Foutmelding in het Dz log:

code:

2024-03-27 13:28:01.252 Error: dzVents: Error: (3.1.8) 031 Log PVProduction: An error occurred when calling event handler Envoy6
2024-03-27 13:28:01.252 Error: dzVents: Error: (3.1.8) 031 Log PVProduction: /home/pi/domoticz/scripts/dzVents/scripts/Envoy6.lua:29: attempt to index a nil value (field 'production')

Ik trek een paar conclusies:
- Je token is Ok. Je krijgt keurig een return code 200
- Dz is in de basis Ok. je krijgt keurig de errors in de logging die je door de huidige situatie mag verwachten.
- Je setup van je Envoy is anders dan bij, oa door het ontbreken van meetspoelen.
- Verder denk ik dat er mogelijk nog iets anders is waar ik de vinger niet achter krijg.
- Het resultaat is dat je nog niet zover belt als je wilt zijn.
Zo heb ik ook geen mogelijke oplossingen meer, ondanks de meerdere pogingen daartoe.

Ik blijf wel meelezen en haak wel weer aan als ik iets zie waar ik wat mee kan en waar ik je verder mee kan helpen.
Succes verder met je speurtocht.

[m.eddy]

Pazo schreef op woensdag 27 maart 2024 @ 14:35:
@m.eddy is die oude echt helemaal overleden? Of nog bruikbaar om mee te hobbyen? Lijk me interessant om te kijken of er firmware-technisch mee te rommelen is. Unit zou handig zijn om aan het internet te hangen, en dan met wireshark te monitoren waarmee de gateway allemaal connectie maakt, en dan kijken of tijdens vragen van updates de locatie van de firmwarebestanden te achterhalen is, om vervolgens te kijken of oudere versies los te downloaden zijn en dat te flashen, bij v7 terug naar v5 zetten. Ga ik met mijn huidige gateway natuurlijk niet doen.

Nou hij gaf dus een error status bij:


Alleen de details daarvan kon ik niet zien in de enlighten manager. De medewerker gaf tijdens de analyse afgelopen zaterdag aan dat hij stuk was. Verdere details gaven ze niet.

De nieuwe gateway werkt goed dus mijn probleem is opgelost.

Maar het blijft een raar gevoel en te toevallig dat hij na de beide firmware updates problemen kreeg.

Wellicht is ie nog goed genoeg om mee te hobbyen.

[Copitano]

Lawrentz schreef op woensdag 27 maart 2024 @ 16:29:
[...]

Ik trek een paar conclusies:
- Je token is Ok. Je krijgt keurig een return code 200
- Dz is in de basis Ok. je krijgt keurig de errors in de logging die je door de huidige situatie mag verwachten.
- Je setup van je Envoy is anders dan bij, oa door het ontbreken van meetspoelen.
- Verder denk ik dat er mogelijk nog iets anders is waar ik de vinger niet achter krijg.
- Het resultaat is dat je nog niet zover belt als je wilt zijn.
Zo heb ik ook geen mogelijke oplossingen meer, ondanks de meerdere pogingen daartoe.

Ik blijf wel meelezen en haak wel weer aan als ik iets zie waar ik wat mee kan en waar ik je verder mee kan helpen.
Succes verder met je speurtocht.

Fijn dat je tot zover geholpen hebt. Hopelijk levert mijn mail aan support van enphase iets op en kunnen we daar dan mee verder

[Lightmanster]

Dankzij deze thread al een heel eind gekomen. Heb een DHZ account en met de api call heb ik een owner token te pakken gekregen met geldigheid van 1 jaar dus grootste gedeelte gaat goed.

Helaas zit er een bug in huidige firmware waardoor dagopbrengst en lifteime opbrengst niet goed wordt weergegeven. ({ip}/api/v1/production)

Alternatief is {ip}/ivp/pdm/energy, maar die is alleen beschikbaar via installer token die maar 12 uur geldig is. Ik wil deze dus automagisch opvragen via een zelfde script als de owner. Maar ik weet de url niet voor installer token. Iemand nog tips ?

Dankl

[Pazo]

Grrr, zojuist ontdekt dat ook ik ten prooi ben gevallen aan de v7 update, zit nu op 7.0.88
Het is 1 april, maar helaas geen grap. HA naar de klote.

[ Voor 6% gewijzigd door Pazo op 01-04-2024 21:30 ]

[Panzer_V]

Pazo schreef op maandag 1 april 2024 @ 21:29:
Grrr, zojuist ontdekt dat ook ik ten prooi ben gevallen aan de v7 update, zit nu op 7.0.88
Het is 1 april, maar helaas geen grap. HA naar de klote.

De standaard HA integratie werkt perfect kan ik je vertellen.

[ardvark99]

Pazo schreef op maandag 1 april 2024 @ 21:29:
Grrr, zojuist ontdekt dat ook ik ten prooi ben gevallen aan de v7 update, zit nu op 7.0.88
Het is 1 april, maar helaas geen grap. HA naar de klote.

Welkom bij de club

[fenrir]

Pazo schreef op maandag 1 april 2024 @ 21:29:
Grrr, zojuist ontdekt dat ook ik ten prooi ben gevallen aan de v7 update, zit nu op 7.0.88
Het is 1 april, maar helaas geen grap. HA naar de klote.

Kak.
Maar zet je dan nu wireshark aan om te kijken of je de bron van de updates kunt achterhalen?

[Pazo]

fenrir schreef op maandag 1 april 2024 @ 22:01:
[...]

Kak.
Maar zet je dan nu wireshark aan om te kijken of je de bron van de updates kunt achterhalen?

Nou helaas stond wireshark niet aan.
Maar ik zag in de grafieken van HA dat rond 21:00 de data ermee ophield, en in Pi-hole zie ik rond dat tijdstip het adres upgrade-fleet.enphaseenergy.com voorbij komen. Had ik dat eerder geweten, dan had ik die geblokeerd...

[m.eddy]

Pazo schreef op maandag 1 april 2024 @ 21:29:
Grrr, zojuist ontdekt dat ook ik ten prooi ben gevallen aan de v7 update, zit nu op 7.0.88
Het is 1 april, maar helaas geen grap. HA naar de klote.

Ai da’s waarschijnlijk stap 1 van 2. Binnen een paar dagen volgt wellicht de volgende upgrade naar D7.6.168.
Bij die stap ging het bij mij dus mis….

Hoop voor jouw op een beter verloop.

[Ies Korpershoek]

m.eddy schreef op dinsdag 2 april 2024 @ 00:46:
[...]


Ai da’s waarschijnlijk stap 1 van 2. Binnen een paar dagen volgt wellicht de volgende upgrade naar D7.6.168.
Bij die stap ging het bij mij dus mis….

Hoop voor jouw op een beter verloop.

Volgens mij is er daarna nog 1. Ik zag 7.6.172 voorbij komen.

[bes-r]

Ies Korpershoek schreef op dinsdag 2 april 2024 @ 07:14:
[...]

Volgens mij is er daarna nog 1. Ik zag 7.6.172 D7.6.175 (f79c8d) voorbij komen.

Kleine correctie. Hier is alweer een nieuwere variant geïnstalleerd.

[Panzer_V]

Hé, ze updaten nu ook Envoys die altijd al op 7 hebben gezeten. Ik had enkele dagen terug gecheckt en zat toen nog op 7.1.xxx en zag zojuist dat ik nu ook op 7.6.175 zit. (Envoy standaard hier)

Ze hebben de update smaak goed te pakken daar 😉

Ps. Alle micro’s starten hier nu keurig op. Dus geen crippled systeem hier.
Ps2. HA blijft ook normaal werken. De standaard Enphase integratie gebruik ik.
Ps3. @Pazo , nog gelukt om in HA te schakelen naar de standaard Enphase integratie?

[ Voor 37% gewijzigd door Panzer_V op 02-04-2024 07:33 ]

[mike123]

m.eddy schreef op dinsdag 2 april 2024 @ 00:46:
[...]


Ai da’s waarschijnlijk stap 1 van 2. Binnen een paar dagen volgt wellicht de volgende upgrade naar D7.6.168.
Bij die stap ging het bij mij dus mis….

Hoop voor jouw op een beter verloop.

Hoe lang zat er bij jou tussen de eerste en volgende versie?
Mijn Envoy metered is 15 Maart geüpdatet en ik zit nu nog op 7.0.88.

[Pazo]

m.eddy schreef op dinsdag 2 april 2024 @ 00:46:
[...]


Ai da’s waarschijnlijk stap 1 van 2. Binnen een paar dagen volgt wellicht de volgende upgrade naar D7.6.168.
Bij die stap ging het bij mij dus mis….

Hoop voor jouw op een beter verloop.

Goed dat je het zegt, dan ga ik Wireshark nu wel aanzetten en hopelijk vang ik dat moment.

Panzer_V schreef op dinsdag 2 april 2024 @ 07:28:
Ps3. @Pazo , nog gelukt om in HA te schakelen naar de standaard Enphase integratie?

Gisteren even snel de integratie van @vinniefireman geïnstalleerd. Lijkt te werken maar heb nog niet alles doorlopen / gecheckt. Het mooie / fijne daarvan is dat je alleen gebruikersnaam en wachtwoord in hoeft te vullen, en geen tokens.

[ Voor 39% gewijzigd door Pazo op 02-04-2024 09:08 ]

[Panzer_V]

Pazo schreef op dinsdag 2 april 2024 @ 09:05:
[...]


Goed dat je het zegt, dan ga ik Wireshark nu wel aanzetten en hopelijk vang ik dat moment.


[...]


Gisteren even snel de integratie van @vinniefireman geïnstalleerd. Lijkt te werken maar heb nog niet alles doorlopen / gecheckt. Het mooie / fijne daarvan is dat je alleen gebruikersnaam en wachtwoord in hoeft te vullen, en geen tokens.

Bij de standaard integratie hoef je ook alleen gebruikersnaam en wachtwoord in te vullen hoor

Ik weet verder niet wat de verschillen zijn tussen de standaard en deze fork.

[BuysB]

Hier vanmorgen van 7.0.88 naar 7.6.177

[Pazo]

Panzer_V schreef op dinsdag 2 april 2024 @ 09:29:
[...]


Bij de standaard integratie hoef je ook alleen gebruikersnaam en wachtwoord in te vullen hoor

Ik weet verder niet wat de verschillen zijn tussen de standaard en deze fork.

Volgens mij kan je er nog meer info uittrekken dan bij de standaard integratie.
En ik dacht ook de productie uitzetten en netprofiel aanpassen (naar zero-export bijvoorbeeld), moet ik nog even verder uitzoeken, want dat is wel een feature dat mogelijk in de toekomst gebruikt gaat worden.

[ Voor 4% gewijzigd door Pazo op 02-04-2024 09:47 ]

[twandirks]

Ook hier is op 28 maart de update gepushed van mijn Envoy-S-Metered van versie 5.0.62 naar versie 7.0.88

Mogelijk gezien de volgende security melding: https://www.cisa.gov/news...advisories/icsa-23-171-01 de Envoy zelf nogmaals een update een update naar versie 7.6.177. Deze update stond klaar. De update verliep zonder problemen.

Hierna zijn de micro omvormers ge-update naar:
520-00082-r01-v04.30.23
540-00135-r01-v04.30.07

De update van de micro omvormer is ook goed verlopen maar heeft wel twee dagen geduurd voor 12 micro omvormers. Sommige micro omvormers hebben meerdere keren nodig gehad voordat de update succesvol was.

[Koekerwauz_NL]

Ik kan sinds 14 maart mijn micro's niet meer zien. Systeem zit op 7.6.168 en mijn vermoeden is dat deze 14 maart erop is gezet. Inmiddels hebben ze een nieuwe envoy gehangen maar helaas rapporteren de micro's nog steeds niet. Systeem wekt wel op maar kan niet per paneel kijken. in 7.6.168 zit schijnbaar ook een bug in de Zigbee dongle die wordt opgelost met een nieuwe firmware.
Mijn advies: firmware 7.6.168 overslaan.

Support van Enphase via mijn installateur laat ook te wensen over.
P.S. volgens mij ligt de Enphase server er compleet uit op dit moment.

[Panzer_V]

@Koekerwauz_NL , hier ook geen connectie met Enphase servers. Die liggen idd plat lijkt het. Morgen nieuwe dag 😉

[NewGuest]

De Installer Toolkit app van Enphase gaf bij mij een push bericht dat de server er uit lag. Alleen als ik de app open kan ik de melding niet meer vinden.

[RogerSch]

De Enphase servers liggen er wel vaak uit ...

[Panzer_V]

RogerSch schreef op dinsdag 2 april 2024 @ 17:58:
De Enphase servers liggen er wel vaak uit ...

Tsja. Liever dat hun servers er wat vaker uitliggen dan de panelen 😉

[Rouske]

twandirks schreef op dinsdag 2 april 2024 @ 09:56:
Ook hier is op 28 maart de update gepushed van mijn Envoy-S-Metered van versie 5.0.62 naar versie 7.0.88

Gezien de volgende security melding: https://www.cisa.gov/news...advisories/icsa-23-171-01 de Envoy zelf nogmaals een update een update naar versie 7.6.177. Deze update stond klaar. De update verliep zonder problemen.

Hierna zijn de micro omvormers ge-update naar:
520-00082-r01-v04.30.23
540-00135-r01-v04.30.07

De update van de micro omvormer is ook goed verlopen maar heeft wel twee dagen geduurd voor 12 micro omvormers. Sommige micro omvormers hebben meerdere keren nodig gehad voordat de update succesvol was.

Sinds vorige week (28/03) zit ik op:
D7.6.358 (499545)
Software Build Date: 24 Nov, 2023 7:18 AM

Wel vaag dat iedereen iets anders krijgt...
Non-metered Gateway en 3-fase IQ-relais.

[Hulliee]

Rouske schreef op dinsdag 2 april 2024 @ 18:52:
[...]

Sinds vorige week (28/03) zit ik op:
D7.6.358 (499545)
Software Build Date: 24 Nov, 2023 7:18 AM

Wel vaag dat iedereen iets anders krijgt...
Non-metered Gateway en 3-fase IQ-relais.

Ik zit op dezelfde firmware versie als jij: D7.6.358, metered, 1-fase

[twandirks]

Rouske schreef op dinsdag 2 april 2024 @ 18:52:
[...]

Sinds vorige week (28/03) zit ik op:
D7.6.358 (499545)
Software Build Date: 24 Nov, 2023 7:18 AM

Wel vaag dat iedereen iets anders krijgt...
Non-metered Gateway en 3-fase IQ-relais.

Ik heb meerdere posts gezien van mensen die het allemaal over een andere firmware versie hebben op dit moment.

Ik ben eens opzoek gegaan naar de release notes 7.6.177 maar kan deze niet vinden. Ik heb de meeste release notes gevonden op: https://enphase.com/nl-nl...n?search_api_language=All

Ik vind wel de release notes van 7.6.175. Maar 7.6.177 kom ik niet tegen.

Bij versie 7.6.358 zie ik staan:
Countries: Belgium, Denmark, and Sweden

Deze lijkt dus eigenlijk niet uitgegeven voor Nederland. Er staat ook bij: IQ8 Series als supported omvormer. Ik heb de IQ7+ mogelijk dat ik deze versie daarom mogelijk niet aangeboden heb gekregen. De hoogste versie die ik zie staan waarbij mijn systeem wel aan de voorwaarde voldoet is versie 7.6.336 ik heb geen idee waarom die dan niet op de Envoy is geüpload door Enphase.

[ Voor 15% gewijzigd door twandirks op 02-04-2024 20:14 ]

[JWT]

Hier ook 7.6.175. micro's nog op .28

Moet nog ergens een envoy standaard in de kast hebben liggen. Die zal vast niet updaten ,:)

[m.eddy]

Koekerwauz_NL schreef op dinsdag 2 april 2024 @ 16:23:
Ik kan sinds 14 maart mijn micro's niet meer zien. Systeem zit op 7.6.168 en mijn vermoeden is dat deze 14 maart erop is gezet. Inmiddels hebben ze een nieuwe envoy gehangen maar helaas rapporteren de micro's nog steeds niet. Systeem wekt wel op maar kan niet per paneel kijken. in 7.6.168 zit schijnbaar ook een bug in de Zigbee dongle die wordt opgelost met een nieuwe firmware.
Mijn advies: firmware 7.6.168 overslaan.

Support van Enphase via mijn installateur laat ook te wensen over.
P.S. volgens mij ligt de Enphase server er compleet uit op dit moment.

Zigbee dongle? Zag dat dat voor systemen met accu is. Draaien die op Zigbee protocol?

[Pazo]

m.eddy schreef op dinsdag 2 april 2024 @ 00:46:
[...]


Ai da’s waarschijnlijk stap 1 van 2. Binnen een paar dagen volgt wellicht de volgende upgrade naar D7.6.168.
Bij die stap ging het bij mij dus mis….

De verwachting is dus dat ik ook naar een (nog) hogere versie ga binnenkort, de vraag is alleen wanneer.
Ik lees hier dat het bij sommige binnen enkele dagen gebeurt, maar anderen nog steeds op 7.0.88 zitten.
Ik heb net upgrade-fleet.enphaseenergy.com geblokkeerd in Pi-hole. Ik vermoed, dat als de upgrade gaat komen, dat Enphase dan met enige regelmaat probeert te pushen. Door het domein te blokkeren hoop ik dat moment dus makkelijker terug te vinden, en dan Wireshark aan te zetten en de blokkade op te heffen, in de hoop dan meer info te verkrijgen. Dan zit ik er gerichter op dan dat ik nu Wireshark aan zet en tienduizenden / dagenlange entries krijg. Hopelijk gaat dat lukken.

[m.eddy]

Pazo schreef op dinsdag 2 april 2024 @ 21:26:
[...]


De verwachting is dus dat ik ook naar een (nog) hogere versie ga binnenkort, de vraag is alleen wanneer.
Ik lees hier dat het bij sommige binnen enkele dagen gebeurt, maar anderen nog steeds op 7.0.88 zitten.
Ik heb net upgrade-fleet.enphaseenergy.com geblokkeerd in Pi-hole. Ik vermoed, dat als de upgrade gaat komen, dat Enphase dan met enige regelmaat probeert te pushen. Door het domein te blokkeren hoop ik dat moment dus makkelijker terug te vinden, en dan Wireshark aan te zetten en de blokkade op te heffen, in de hoop dan meer info te verkrijgen. Dan zit ik er gerichter op dan dat ik nu Wireshark aan zet en tienduizenden / dagenlange entries krijg. Hopelijk gaat dat lukken.

Bij mij zat er een week tussen. Maar n=1. Succes met onderscheppen van de update procedure.

[Koekerwauz_NL]

m.eddy schreef op dinsdag 2 april 2024 @ 21:08:
[...]


Zigbee dongle? Zag dat dat voor systemen met accu is. Draaien die op Zigbee protocol?

https://wsolar.shop/nl/bl...e-in-zijn-micro-omvormers

[mike123]

Koekerwauz_NL schreef op dinsdag 2 april 2024 @ 21:57:
[...]


https://wsolar.shop/nl/bl...e-in-zijn-micro-omvormers

Vind dit toch wel een beetje raar.

"Zigbee-technologie maakt betrouwbare en efficiënte draadloze communicatie mogelijk tussen micro-omvormers en andere apparaten in het zonnestelsel, zoals energiemeters en slimme thermostaten. Dit maakt nauwkeurigere monitoring en controle van de productie en het gebruik van zonne-energie mogelijk, evenals de integratie van andere slimme apparaten in huis."

En dan vooral het zonnestelsel. Mooie vertaling denk ik.

Dit is een document van Enphase zelf voor de Zigbee range extender.
https://enphase.com/downl...range-extender-data-sheet

[twandirks]

JWT schreef op dinsdag 2 april 2024 @ 20:06:
Hier ook 7.6.175. micro's nog op .28

Moet nog ergens een envoy standaard in de kast hebben liggen. Die zal vast niet updaten ,:)

Er gaan ook nogal wat micro omvormer versies rond. De meeste zitten op .28, ikzelf nu op .30 maar kom ook al deze versie tegen:
520-00082-r01-v04.40.01
540-00141-r01-v04.40.03

En dan ook nog deze thread over .40 versie op Reddit: https://www.reddit.com/r/...ware_produces_20_or_more/

Het update beleid bij Enphase is mij nog niet helemaal duidelijk.

[JWT]

mike123 schreef op dinsdag 2 april 2024 @ 22:20:
[...]

Vind dit toch wel een beetje raar.

"Zigbee-technologie maakt betrouwbare en efficiënte draadloze communicatie mogelijk tussen micro-omvormers en andere apparaten in het zonnestelsel, zoals energiemeters en slimme thermostaten. Dit maakt nauwkeurigere monitoring en controle van de productie en het gebruik van zonne-energie mogelijk, evenals de integratie van andere slimme apparaten in huis."

En dan vooral het zonnestelsel.

Voor het geval we toch naar mars gaan .

Zou het kunnen dat het alleen voor de iq8 is?

[HermanGast]

JWT schreef op woensdag 3 april 2024 @ 07:47:
[...]


Voor het geval we toch naar mars gaan .

Zou het kunnen dat het alleen voor de iq8 is?

De IQ7 communiceert dmv modulatie over de 230VAC. Daarom is ook een fase koppeling nodig (bijv Q-relay) bij 3-fase opstelling.

[ari2asem]

hoe kom ik erachter of ik envoy s metered versie 2019 of versie 2022 heb?

envoy firmware is versie 7.6.175

[ Voor 19% gewijzigd door ari2asem op 03-04-2024 23:51 ]

[twandirks]

ari2asem schreef op woensdag 3 april 2024 @ 23:50:
hoe kom ik erachter of ik envoy s metered versie 2019 of versie 2022 heb?

envoy firmware is versie 7.6.175

Je kan aan het SKU nummer zien welke versie je hebt. Hierover is in een ander topic al ooit geschreven:

Eddie_ schreef op dinsdag 14 februari 2023 @ 21:21:
[...]


Als ik mij niet vergis is de wm uitvoering de oudere versie en de em uitvoering het model wat momenteel gebruikt wordt. Ik zie weinig verschillen in de documentatie (maar ik kan iets over het hoofd zien). Wel heeft de EM versie al de "nieuwe" naam gekregen en heet deze nu de IQ gateway (zoals alles nu richting de IQ benaming gaat).

env-s-em-230 Enphase IQ Gateway Metered 2

env-s-wm-230 Enphase Envoy-S Metered Multiphase

Heb je een levering vanaf 2022 kan het zijn dat je een env-s-em-230 hebt ontvangen.

[ Voor 3% gewijzigd door twandirks op 04-04-2024 09:28 ]

[Eddie_]

Oké ik red mij prima met Enphase zelf maar in combinatie met Homeassistant ben ik echt een noob. Probeer wel steeds meer onder de knie te krijgen en dat gaat langzaam maar zeker de goede kant op. Ik heb de integratie van briancmpbll werkend gekregen. Dit is lange tijd goed gegaan maar nu krijg ik de melding: Failed setup will retry.

Ik ben aan het zoeken gegaan maar heb de oplossing niet gevonden (of overheen gelezen). Wie kan mij helpen?

[breew]

Eddie_ schreef op donderdag 11 april 2024 @ 14:13:
Oké ik red mij prima met Enphase zelf maar in combinatie met Homeassistant ben ik echt een noob. Probeer wel steeds meer onder de knie te krijgen en dat gaat langzaam maar zeker de goede kant op. Ik heb de integratie van briancmpbll werkend gekregen. Dit is lange tijd goed gegaan maar nu krijg ik de melding: Failed setup will retry.

Ik ben aan het zoeken gegaan maar heb de oplossing niet gevonden (of overheen gelezen). Wie kan mij helpen?

"Failed setup will retry." klinkt als een probleem met de authenticatie.... maar ik heb zelf geen ervaring met de integratie van briancmpbll .
Ik ben geen held in Homeassistant, maar kreeg deze integratie:
https://github.com/vincen...t_enphase_envoy_installer
prima werkend (installer account vereist).

[Panzer_V]

Eddie_ schreef op donderdag 11 april 2024 @ 14:13:
Oké ik red mij prima met Enphase zelf maar in combinatie met Homeassistant ben ik echt een noob. Probeer wel steeds meer onder de knie te krijgen en dat gaat langzaam maar zeker de goede kant op. Ik heb de integratie van briancmpbll werkend gekregen. Dit is lange tijd goed gegaan maar nu krijg ik de melding: Failed setup will retry.

Ik ben aan het zoeken gegaan maar heb de oplossing niet gevonden (of overheen gelezen). Wie kan mij helpen?

Mijn advies: verwijder die integratie en stap over op de standaard HA integratie voor Enphase. Heb ik zelf ook gedaan toen die beschikbaar kwam. Geen seconde spijt van gehad.

[mike123]

Panzer_V schreef op donderdag 11 april 2024 @ 16:44:
[...]


Mijn advies: verwijder die integratie en stap over op de standaard HA integratie voor Enphase. Heb ik zelf ook gedaan toen die beschikbaar kwam. Geen seconde spijt van gehad.

Ik gebruik (nog) geen HA maar zie je daar wel het totaal verbruik per dag? Als je ct spoelen hebt aangesloten.
Ik gebruik Homey en voor de update zag ik ook mijn dagelijks gebruik in de app, nu niet meer.
Misschien dat ik nog een keer begin met HA.

[Pazo]

@mike123 ja dat kan, heeft wel wat voeten in de aarde:
Pazo in "[Enphase] Envoy / IQ Gateway lokaal uitlezen voor domotica"

Ik heb momenteel per paneel de totale dagwaarde boven staan en de actuele waarde onder.

[mike123]

Pazo schreef op donderdag 11 april 2024 @ 22:07:
@mike123 ja dat kan, heeft wel wat voeten in de aarde:
Pazo in "[Enphase] Envoy / IQ Gateway lokaal uitlezen voor domotica"

Ik heb momenteel per paneel de totale dagwaarde boven staan en de actuele waarde onder.

Dank je wel voor de link.
Ik heb jouw verhaal even doorgelezen maar zag niet staan waar het verbruik word weergegeven.
Als je ct spoelen gebruikt dan word je dagverbruik ook gemeten (berekend). Of het van de zonnepanelen of van het net komt maakt niet uit.

[Pazo]

mike123 schreef op donderdag 11 april 2024 @ 23:02:
[...]

Dank je wel voor de link.
Ik heb jouw verhaal even doorgelezen maar zag niet staan waar het verbruik word weergegeven.
Als je ct spoelen gebruikt dan word je dagverbruik ook gemeten (berekend). Of het van de zonnepanelen of van het net komt maakt niet uit.

Sorry, niet goed gelezen. je doelde op verbruik, ik dacht productie.
Ja je kunt met de metered met CT spoelen ook verbruiksdata inzien van het huis. Ligt een beetje aan welke integratie voor HA je gebruikt, maar sowieso je dagverbruik. In de standaard integratie zit dat ingebakken.

[ Voor 23% gewijzigd door Pazo op 11-04-2024 23:30 ]

[The Zep Man]

Pazo schreef op donderdag 11 april 2024 @ 23:27:
[...]
Sorry, niet goed gelezen. je doelde op verbruik, ik dacht productie.
Ja je kunt met de metered met CT spoelen ook verbruiksdata inzien van het huis. Ligt een beetje aan welke integratie voor HA je gebruikt, maar sowieso je dagverbruik. In de standaard integratie zit dat ingebakken.

Dat kan alleen als je CT-spoelen installeert op de fasen uit het net (consumptiezijde). Die zijn optioneel. CT-spoelen kunnen totaal niet geïnstalleerd zijn, of enkel op de productiezijde.

Als je in dit topic en het algemene Enphase-topic zoekt dan zie je reacties van mij over CT-spoelen die ik zelf maar moest kopen en installeren omdat zonnepaneelinstallateurs de kortste weg kiezen.

[ Voor 8% gewijzigd door The Zep Man op 12-04-2024 09:32 ]

[Pazo]

@The Zep Man @mike123 Extra info mbt CT spoelen, zie Enphase topic - IQ gateway.

[The Zep Man]

Pazo schreef op vrijdag 12 april 2024 @ 09:22:
@The Zep Man @mike123 Extra info mbt CT spoelen, zie Enphase topic - IQ gateway.

Bedankt, maar zoals genoemd heb ik de CT-meetspoelen bij mij al een tijd geleden geïnstalleerd. Voor mij is die informatie niet meer nuttig, maar ongetwijfeld wel voor anderen die hierover struikelen.

[mike123]

Pazo schreef op vrijdag 12 april 2024 @ 09:22:
@The Zep Man @mike123 Extra info mbt CT spoelen, zie Enphase topic - IQ gateway.

Ik heb mijn spoelen ook al een hele tijd aangesloten en werken prima.
Maar de nieuwe Homey app laat het dagelijks totaal verbruik niet meer zien in de app.
Daar is nu een veld voor gekomen die laat zien wat ik op het moment teruglever of wat ik gebruik uit het net.

[Me Albert]

@Lawrentz
Even een vraag iets buiten het thema maar niet geschoten is altijd mis.

Je script werkt goed met de api key en heb het nu werkend voor al mijn 15 panelen.
Ik gebruik ook Home Wizard kwh meters die je op ieder moment kunt uitlezen. (ipadres/api/v1/data)
Ik heb geprobeerd om daar ook de curl truc uit te voeren maar ben er nu achter dat het geen json string is die ik terug krijg.
De gegevens zien er zo uit:

{"wifi_ssid":"AM","wifi_strength":50,"total_power_import_kwh":11.424,"total_power_import_t1_kwh":11.424,"total_power_export_kwh":3148.831,"total_power_export_t1_kwh":3148.831,"active_power_w":-147.033,"active_power_l1_w":-147.033,"active_voltage_v":222.489,"active_current_a":0.69,"active_apparent_current_a":0.924,"active_reactive_current_a":0.614,"active_apparent_power_va":196.805,"active_reactive_power_var":-130.807,"active_power_factor":0.747,"active_frequency_hz":50}"
Lijkt wel op json maar de [ ] haakjes ontbreken. Hoe moet ik dan de total_power_export_kwh en active_power_w uit deze brei filteren?

[itsme]

Me Albert schreef op zondag 14 april 2024 @ 12:15:
@Lawrentz
Even een vraag iets buiten het thema maar niet geschoten is altijd mis.

Je script werkt goed met de api key en heb het nu werkend voor al mijn 15 panelen.
Ik gebruik ook Home Wizard kwh meters die je op ieder moment kunt uitlezen. (ipadres/api/v1/data)
Ik heb geprobeerd om daar ook de curl truc uit te voeren maar ben er nu achter dat het geen json string is die ik terug krijg.
De gegevens zien er zo uit:

{"wifi_ssid":"AM","wifi_strength":50,"total_power_import_kwh":11.424,"total_power_import_t1_kwh":11.424,"total_power_export_kwh":3148.831,"total_power_export_t1_kwh":3148.831,"active_power_w":-147.033,"active_power_l1_w":-147.033,"active_voltage_v":222.489,"active_current_a":0.69,"active_apparent_current_a":0.924,"active_reactive_current_a":0.614,"active_apparent_power_va":196.805,"active_reactive_power_var":-130.807,"active_power_factor":0.747,"active_frequency_hz":50}"
Lijkt wel op json maar de [ ] haakjes ontbreken. Hoe moet ik dan de total_power_export_kwh en active_power_w uit deze brei filteren?

Welke [ ] haakjes zoek je, een json heeft net { }.

[Me Albert]

@itsme
Bekeek het meervoudige file. Dat van alle panelen en dat begint met een [ en eindigt met een ]
Klopt een singel json file is zonder.
In de loggings zie ik json=nil en ik krijg geen waardes terug
Zal mijn scriptjes nog een keer bekijken en hier posten. wellicht dat jullie zien wat ik fout doe

[Lawrentz]

Me Albert schreef op zondag 14 april 2024 @ 12:15:
@Lawrentz
Even een vraag iets buiten het thema maar niet geschoten is altijd mis.

Je script werkt goed met de api key en heb het nu werkend voor al mijn 15 panelen.
Ik gebruik ook Home Wizard kwh meters die je op ieder moment kunt uitlezen. (ipadres/api/v1/data)
Ik heb geprobeerd om daar ook de curl truc uit te voeren maar ben er nu achter dat het geen json string is die ik terug krijg.
De gegevens zien er zo uit:

{"wifi_ssid":"AM","wifi_strength":50,"total_power_import_kwh":11.424,"total_power_import_t1_kwh":11.424,"total_power_export_kwh":3148.831,"total_power_export_t1_kwh":3148.831,"active_power_w":-147.033,"active_power_l1_w":-147.033,"active_voltage_v":222.489,"active_current_a":0.69,"active_apparent_current_a":0.924,"active_reactive_current_a":0.614,"active_apparent_power_va":196.805,"active_reactive_power_var":-130.807,"active_power_factor":0.747,"active_frequency_hz":50}"
Lijkt wel op json maar de [ ] haakjes ontbreken. Hoe moet ik dan de total_power_export_kwh en active_power_w uit deze brei filteren?

Dit is weldegelijk een json.
Wellicht komt het door een copy/paste-fout maar de " na de :50} hoort hier niet.

Die genummerde spekhaken heb je alleen nodig bij embedded objecten zonder naam.
Deze json heeft geen embedded objecten zonder naam waardoor de genummerde spekhaken niet nodig zijn.

Bij deze json kan je alle data rechtsreeks aanroepen en verwerken in Dz met bijvoorbeeld

code:

item .json .total_power_export_kwh
item .json .active_power_w

Omdat ik andere systemen zoals HA en Homey niet ken kan ik je daar niet mee helpen.

[Me Albert]

Ik krijg nog steeds geen data uit mijn aangepast programma.

code:

local curlStatement = 'curl -f -k -H '
local HomeWizard      = 'https://192.168.178.132/api/v1/data'
local curlCommand   = 'leeg' 

return {
    on = {
        timer = { 'every 1 minutes between 30 minutes before sunrise and 30 minutes after sunset'}
    },

    logging = {
        level  = domoticz.LOG_INFO,
        marker = '009 Get OpbrengstHuis'
    },

    execute = function (domoticz)

        curlCommand = curlStatement ..  '\'  '.. HomeWizard   --.. HomeWizardEndPoint
        domoticz.executeShellCommand ({
            command = curlCommand,
            callback = 'OpbrengstHuis', 
            timeout  = 20
        })
        domoticz.log (curlCommand)
        domoticz.log ('Triggering 028 Log OpbrengstHuis')

    end
}

Uit de log data blijkt nu dat er geen gegevens gelezen worden.

2024-04-16 20:25:22.634 Status: EventSystem: Script event triggered: /home/pi/domoticz/dzVents/runtime/dzVents.lua
2024-04-16 20:26:02.015 Status: dzVents: Info: 028 Log OpbrengstHuis: ------ Start internal script: Script #3: ShellCommandResponse: "OpbrengstHuis"
2024-04-16 20:26:02.015 Status: dzVents: Info: 028 Log OpbrengstHuis: Triggered by 001 Get OpbrengstHuis
2024-04-16 20:26:02.015 Status: dzVents: Info: 028 Log OpbrengstHuis: item.statusCode: 2
2024-04-16 20:26:02.015 Status: dzVents: Info: 028 Log OpbrengstHuis: item.json == nil
2024-04-16 20:26:02.016 Status: dzVents: Info: 028 Log OpbrengstHuis: ------ Finished Script #3

Wat doe ik fout?

code:

zonnepanelenHuisIdx       = 152 
local active_power_w

local total_power_export_kwh



return {
    on = {
        shellCommandResponses = {'OpbrengstHuis'} 
    },

    logging = {
        level  = domoticz.LOG_INFO,
        marker = '028 Log OpbrengstHuis'
    },

    execute = function (domoticz, item)
        domoticz.log ('Triggered by 001 Get OpbrengstHuis')

        if item.statusCode ~= 0 then domoticz.log ("item.statusCode: " .. item.statusCode) end 
        if item.json       ~= nil 
        then
            
-- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
            active_power_w           =                       item.json.active_power_w
            total_power_export_kwh   =                       item.json.total_power_export_kwh
            domoticz.log (item.json.active_power_w)
-- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
            domoticz.devices    (zonnepanelenHuisIdx)        .updateElectricity  (active_power_w)
--            domoticz.devices    (zonnepanelenHuisIdx)        .updateCustomSensor (wattsNow)

-- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
            domoticz.log        ("-- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- ")
            domoticz.log        ('Opbrengst Huis Nu........: ' .. item.json.active_power_w  .. ' Watt')
            domoticz.Log        ('opbrengst Huis kWh.......: ' .. total_power_export_kwh .. ' kWh ' )
-- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
        else
            domoticz.log ('item.json == nil')
        end
    end
}

[Lawrentz]

Me Albert schreef op dinsdag 16 april 2024 @ 20:31:
Ik krijg nog steeds geen data uit mijn aangepast programma.

code:

local curlStatement = 'curl -f -k -H '
local HomeWizard      = 'https://192.168.178.132/api/v1/data'
local curlCommand   = 'leeg' 

return {
    on = {
        timer = { 'every 1 minutes between 30 minutes before sunrise and 30 minutes after sunset'}
    },

    logging = {
        level  = domoticz.LOG_INFO,
        marker = '009 Get OpbrengstHuis'
    },

    execute = function (domoticz)

        curlCommand = curlStatement ..  '\'  '.. HomeWizard   --.. HomeWizardEndPoint
        domoticz.executeShellCommand ({
            command = curlCommand,
            callback = 'OpbrengstHuis', 
            timeout  = 20
        })
        domoticz.log (curlCommand)
        domoticz.log ('Triggering 028 Log OpbrengstHuis')

    end
}

Uit de log data blijkt nu dat er geen gegevens gelezen worden.

2024-04-16 20:25:22.634 Status: EventSystem: Script event triggered: /home/pi/domoticz/dzVents/runtime/dzVents.lua
2024-04-16 20:26:02.015 Status: dzVents: Info: 028 Log OpbrengstHuis: ------ Start internal script: Script #3: ShellCommandResponse: "OpbrengstHuis"
2024-04-16 20:26:02.015 Status: dzVents: Info: 028 Log OpbrengstHuis: Triggered by 001 Get OpbrengstHuis
2024-04-16 20:26:02.015 Status: dzVents: Info: 028 Log OpbrengstHuis: item.statusCode: 2
2024-04-16 20:26:02.015 Status: dzVents: Info: 028 Log OpbrengstHuis: item.json == nil
2024-04-16 20:26:02.016 Status: dzVents: Info: 028 Log OpbrengstHuis: ------ Finished Script #3

Wat doe ik fout?

code:

zonnepanelenHuisIdx       = 152 
local active_power_w

local total_power_export_kwh



return {
    on = {
        shellCommandResponses = {'OpbrengstHuis'} 
    },

    logging = {
        level  = domoticz.LOG_INFO,
        marker = '028 Log OpbrengstHuis'
    },

    execute = function (domoticz, item)
        domoticz.log ('Triggered by 001 Get OpbrengstHuis')

        if item.statusCode ~= 0 then domoticz.log ("item.statusCode: " .. item.statusCode) end 
        if item.json       ~= nil 
        then
            
-- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
            active_power_w           =                       item.json.active_power_w
            total_power_export_kwh   =                       item.json.total_power_export_kwh
            domoticz.log (item.json.active_power_w)
-- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
            domoticz.devices    (zonnepanelenHuisIdx)        .updateElectricity  (active_power_w)
--            domoticz.devices    (zonnepanelenHuisIdx)        .updateCustomSensor (wattsNow)

-- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
            domoticz.log        ("-- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- ")
            domoticz.log        ('Opbrengst Huis Nu........: ' .. item.json.active_power_w  .. ' Watt')
            domoticz.Log        ('opbrengst Huis kWh.......: ' .. total_power_export_kwh .. ' kWh ' )
-- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
        else
            domoticz.log ('item.json == nil')
        end
    end
}

Ik denk zo dat deze vraag meer Domoticz is gerelateerd en niet zozeer met dit topic te maken heeft.
Even snel een vraag beantwoorden lijkt mij niet zo'n groot probleem maar dit gaat net iets verder dan een snelle vraag.
Als je in GVR in "Domoticz - open source domotica systeem - deel 5" je vraag stelt dan pak ik het daar weer over (tenzij een andere Tweakert me voor is).

Ik denk overigens dat ik het antwoord al weet (ondanks dat ik geen Homewizard P1 meter heb maar een SmartGateways P1 meter met daardoor ook een iets andere API).

[ari2asem]

ik weet niet of mijn vraag hier thuis hoort of bij enphase topic.

mijn vraag gaat over CT-spoelen.
- 1). welke van deze spoelen heb ik nodig om verbruik en opwek in enphase-app te kunnen zien?

mijn envoy (of iq gateway is wm-230. dus model 2019).
-2). moet ik per se CT-spoelen van 2019 kopen of kan ook met 2022-versie?

-3). hoe worden deze spoelen aangesloten op 3 fase (heb ik 6 spoelen nodig) ? maakt het uit waar de kabels in meterkast aangesloten worden om verbruik en opwek te kunnen inzien?

-4) als je onderstaande foto kijkt, welke spoelen heb ik nodig voor verbruik en opwek inzage? ct-100-split of ct-100-split-row?
of heb ik 3 paren nodig (dus 3 split en 3 row)?

alvast bedankt voor reacties

[Pazo]

@ari2asem er zijn meerdere CT spoelen in omloop, het maakt niet uit welke je gebruikt, ze werken allemaal. De nieuwere zijn alleen kleiner, dat is wellicht handiger mbt beschikbare ruimte in je groepenkast.

Zie ook JMSL2022 in "Het grote Enphase topic"

Mbt aantal spoelen, zie ook IQ Gateway in het grote Enphase topic. Bij een 3 fase systeem met 3 fase meterkasten heb je er totaal 6 nodig. Je krijgt er 2 bij meegeleverd bij Metered. Dus nog 4 extra nodig / bijbestellen.

[ari2asem]

Pazo schreef op donderdag 18 april 2024 @ 15:50:


Mbt aantal spoelen, zie ook IQ Gateway in het grote Enphase topic. Bij een 3 fase systeem met 3 fase meterkasten heb je er totaal 6 nodig. Je krijgt er 2 bij meegeleverd bij Metered. Dus nog 4 extra nodig / bijbestellen.

eerste gedeelte van je antwoord is duidelijk.

maar 2de gedeelte nog niet helemaal.
ik weet dat ik 6 spoelen nodig heb (vanwege 3 fase meterkast, 3*40A, alles is 3 fase uitgevoerd)

maar 6 spoelen SPLIT? of 6 spoelen ROW?
of 3 split en 3 row?

[Pazo]

ari2asem schreef op donderdag 18 april 2024 @ 16:40:
maar 6 spoelen SPLIT? of 6 spoelen ROW?
of 3 split en 3 row?

Zover ik weet maakt het niets uit, maar dat was ook meer dan 3 jaar geleden, nog met die grote jongens.
In dat screenshotje van jou staat toch ook dat ze door elkaar gebruikt kunnen worden?

[ari2asem]

Pazo schreef op donderdag 18 april 2024 @ 17:08:
[...]


Zover ik weet maakt het niets uit, maar dat was ook meer dan 3 jaar geleden, nog met die grote jongens.
In dat screenshotje van jou staat toch ook dat ze door elkaar gebruikt kunnen worden?

https://support.enphase.com/s/feed/0D53m00008gtYVyCAM

maakt dus een beetje uit. want row = rest of world, dus split is voor USA.

split-row is dus voor mij.

bedankt