Aller au contenu

Messages recommandés

Posté(e) (modifié)

Il faudrait pouvoir communiquer avec la gateway envoy en local comme avec le firmware 5 mais cette fois en 7. 
et éviter le Cloud 

ici une expérience suivi de recherche pour finalement générer de manière auto le fameux jeton (JTW) pour l’authentification 

avec du code en py. 
mais ça reste du Cloud (je pense)

https://evilzenscientist.com/2022/05/access-to-the-local-enphase-envoy-api-through-code/

 

Rien à voir, mais, pourquoi sécuriser une gestion PV localement ?

enfin, avec ttes mes questions j’ai un peu pollué le sujet !! Il faudra créer un sujet « Envoy-Api » «  Envoy-FW » 

il n’y a pas foule sur le sujet chez jeedom, même si le plugin officiel annonce ne pas fonctionner avec le fw 7, « en attente d’évolution « 

chez HA, ça bouge doucement mais c’est du Cloud 

Modifié par flamalex
Posté(e)

Hum, d'après ce qu'il décrit, il s'agit de récupérer un jeton sur le site Web d'Enphase, qui pourra ensuite être utilisé en local sur la passerelle Envoy.

C'est un moindre mal car la communication avec l'API se fait en local, mais la génération du jeton est dépendante du Cloud... et comme le gars l'explique sur son blog, la méthode de récupération du jeton n'est pas documentée par Enphase, considérant que l'utilisateur doit faire la manip manuellement... ce qui est assez antagoniste avec l'usage un script en domotique qui se doit d'être 100 autonome. Du coup le gars propose une méthode de "scrapping" consistant à parcourir la page Web pour récupérer le jeton... ce qui fonctionnera tant que la structure de la page Web ne change pas.

 

@augur faire la mise à jour pour dépendre du cloud n'est pas ce que j'appelle à aller de l'avant, mais plutôt aller droit dans le mur....

 

Il est urgent d'attendre....  (pour mieux sauter ?)

Posté(e)
Il y a 2 heures, Nico a dit :

N empêche ils font tous chier avec leur protection ++ à chaque fois...

C'est nécessaire car les risque de sécurité sont de plus en plus importants, on voit tous les jours des sociétés de faire "pirater" (oh le vilain mot).

Mais ces risques de sécurité sont aussi la conséquence de mauvais choix d'architecture... le tout connecté au cloud, dépendant de serveurs centraux, implique des risques de sécurités considérables en cas d'attaque.

Et c'est là qu'on voit que ces problématiques de sécurité cachent le vrai problème, les mauvais choix d'architecture, la dépendance au cloud, qui sont dictés par d'uniques raisons de rentabilité financière...

 

Alors qu'une bonne vieille connexion locale en tout autonomie, c'est moins couteux, plus pérenne, ça poserait tout un tas de problèmes de sécurité en mois, bref à l'avantage du client... mais ça, ce n'est pas l'avis des investisseurs.

 

Je travaille dans une boite qui porte le mot "Cloud" dans son nom, alors on va dire que je connais un peu le problème de l'intérieur... c'est désespérant. Vraiment.

Posté(e)

Comme tu dis Lazer, entreprise.

Ici on parle d'un accès en lecture en local à une pauvre API de production solaire, même ouverte sur le net je m'en taperai le cocotier...

Posté(e)

Non ce n'est pas ça.

 

La politique économique de l'entreprise (Enphase dans le cas présent) c'est de ramener les utilisateurs (données et usages) vers le cloud.

Cette centralisation des informations induis des risques de sécurité, qu'il faut couvrir par des mécanismes complexes (token JWT dans le cas présent, on pourrait parler de Netatmo et OAuth 2.0). Si cette sécurisation n'est pas faite, un piratage des serveurs pourrait potentiellement toucher tous les clients. Leurs données, mais aussi par rebond l'accès à leur passerelle, leur réseau, et les usages qui peuvent en découler (les bien connues attaques DDOS).

 

Bien sûr, si on avait juste un accès local, nous on serait content.

Mais ça n'est pas l'objectif des entreprises, car développer et maintenir (par les mises à jours) des objets disséminés ça et là, c'est couteux... et ça ne rapporte rien.

Posté(e)

Pas seulement, c est aussi une course à la sécurisation, car chacun doit pouvoir se targuer d être le 1er dans ce domaine...

Posté(e)

Mouais alors là je ne suis pas d'accord, car c'est plutôt l'inverse qui se passe.

Ils sont tous ultra à la bourre en matière de sécurisation... et ils sont plutôt en mode pompier depuis quelques années.

Y'a une faille, une brèche, une technique, une méthode.. qui permet de pirater, alors vite* on applique une rustine.
Mais la sécurité ça coute cher, alors ils ne le font pas en amont.

 

* et encore "vite", c'est vite dis... le nombre de failles qui ne sont jamais corrigées, c'est assez incroyable. Et ça ouvre la porte à plein d'attaque DDOS justement (c'est l'usage le plus courant je pense)

Posté(e)

Mouais, bah en privé sur des applications de ce type, moi je veux bien croisé un jour qqun qui s'est fait pirater...

Posté(e)

Pour rester dans le thème, je me suis dit que j'allais faire un QuickApp vite fait pour signaler les alertes sur le réseau électrique via Ecowatt.

 

https://data.rte-france.com/catalog/-/api/consumption/Ecowatt/v4.0

 

Et.... il faut une authentification OAuth 2.0 :2:

 

Pour un service public, qui propose une information publique, qui n'a rien de confidentielle... là c'est n'importe quoi...

Posté(e)

Réponse, ce jour, enphase

 

Bonjour Alex,

Merci d'avoir contacté Enphase Energy. Veuillez nous excuser pour le retard de réponse. Nous rencontrons un nombre élevé de demandes de clients et nous ne sommes donc pas en mesure de vous joindre aussi rapidement que nous le voulions vraiment.


J'ai confirmé avec mon équipe de niveau supérieur et vérifié une fois le micrologiciel mis à jour, nous ne pourrons pas rétrograder le micrologiciel.


Si vous avez des questions supplémentaires, veuillez nous écrire ou contacter notre support technique au (877) 797-4743.
Posté(e) (modifié)

Et pourtant en mars, un internaute partage son expérience 

« Update - 7.x.x firmware is still a hot mess - most API URLs fail with 504 errors. In desperation I contacted Enphase Support via telephone and requested they downgrade my Envoy to version 5.x.x ... after placing me on hold for a few minutes the operator confirmed she could do this and went ahead and did so. I also requested that i remain on 5.x.x until I specifically requested an upgrade - again she confirmed my Envoy will remain at 5.x.x. My script is now running again perfectly. »

 

https://github.com/vk2him/Enphase-Envoy-mqtt-json/issues/5#issuecomment-1081229342

Modifié par flamalex
Posté(e)

Nous comprenons que certains utilisateurs veulent que leurs systèmes énergétiques ne soient connectés que localement et qu'ils renoncent à notre processus d'authentification des jetons. Cependant, notre solution d'authentification de jetons est actuellement applicable à tous les envoyés connectés localement, et nous main tenons cette décision qui, selon nous, offre un niveau de sécurité accru pour ces systèmes, où l'accès non autorisé est en grande partie entre les mains du propriétaire du système. Pour être clair, nous ne sommes pas passés à l'authentification basée sur des jetons pour empêcher les utilisateurs d'obtenir leurs propres données ou d'en tirer profit d'une manière ou d'une autre (ce que nous ne faisons pas).

Pour clarifier un malentendu concernant cette question, les jetons pour les propriétaires de systèmes sont valables pendant 6 mois et présentent donc des inconvénients et un risque extrêmement faibles qu'un jeton expire pendant une panne prolongée. Si vous recevez un jeton plus court (1 heure ou 12 heures), il est probable que vous vous connectez en tant que "installateur" et que vous devrez utiliser un compte d'éclairage "propriétaire du système" à la place. Le service à la clientèle peut vous aider.

Posté(e) (modifié)

bon, je vais ouvrir un autre sujet

j'ai passé beaucoup de temps pcq je voyais que ça n'avancait pas depuis plus d'un an sur cette version 7

je me suis collé au python, j'ai reussi sur visualstudio, je genere un token avec mes identifiants en automatique puis j'accede au json de l'envoy

et ça fonctionne

de ce fait j'ai envoyé mes travaux, en MP, à CDDU33 (developpeur sur jeedom) pour qu'il developpe le plugin public sur jeedom pour envoy fw7

 

aujourd'hui je teste via un script json sur jeedom pour ensuite recuperer sur fibaro

 

voici l'avancée 

dans visual studio code j’ai testé mon tokentest.py
c’est good ca fonctionne apres avoir installé les dependances

pip install pyjwt
pip install html.parser
pip install html5lib
pip install bs4
pip install asyncio
pip install logging
pip install json

le code du py

#!/usr/bin/env python3
import asyncio
import logging
import re
import time
import jwt
import json


from html.parser import HTMLParser
from json.decoder import JSONDecodeError
try: 
    from BeautifulSoup import BeautifulSoup
except ImportError:
    from bs4 import BeautifulSoup
#from envoy_utils.envoy_utils import EnvoyUtils

import httpx

class MyHTMLParser(HTMLParser):
    def handle_starttag(self, tag, attrs):
        print("Encountered a start tag:", tag)

    def handle_endtag(self, tag):
        print("Encountered an end tag :", tag)

    def handle_data(self, data):
        print("Encountered some data  :", data)

SITE_ID = "30987672"
SERIAL_NUMBER = "12223456956"

ENDPOINT_URL_PRODUCTION_JSON = "http://{}/production.json"
ENDPOINT_URL_PRODUCTION_V1 = "http://{}/api/v1/production"
ENDPOINT_URL_PRODUCTION_INVERTERS = "http://{}/api/v1/production/inverters"
ENDPOINT_URL_PRODUCTION = "http://{}/production"
LOGIN_URL = "https://entrez.enphaseenergy.com/login"
TOKEN_URL = "https://entrez.enphaseenergy.com/entrez_tokens"
LOCAL_URL = "https://192.168.1.25/"

payload_login = {'username': 'mon@gmail.com', 'password': 'alexmdp'}
payload_token = {'Site': SITE_ID, "serialNum": SERIAL_NUMBER}

headers = {'Content-Type': 'application/json'}


client = httpx.Client(verify=False)
token = ""
try:
    r = client.post(LOGIN_URL, data=payload_login)
    print(r.status_code)
    #print(r.text)
    r = client.post(TOKEN_URL, data=payload_token)
    print(r.status_code)
    #print(r.text)
    parsed_html = BeautifulSoup(r.text, "lxml")
    token = parsed_html.body.find('textarea').text
    print(token)
    decode = jwt.decode(token, options={"verify_signature": False}, algorithms="ES256")
    print(decode["exp"])
    
    header = {"Authorization": "Bearer " + token}
    r = client.get(LOCAL_URL + "auth/check_jwt", headers=header)
    print(r.text)

    r = client.get(LOCAL_URL + "api/v1/production", headers=header)
    print(r.text)
json.dump(r.json(), open("/var/www/html/plugins/script/data/jsonenvoy.txt", "w+"))
finally:
    client.close()

j’ai bien le json qui ressort dans la console du deboguage de visual studio

voici le retour de la console

2022.14.0\pythonFiles\lib\python\debugpy\adapter/../..\debugpy\launcher' '61381' '--' 'c:\Users\flamalex\Desktop\tokentest.py' 
200
200
eyJraWQiOiI3ZDEwMDA1ZC03ODk5LTRkMGQtYmNiNC0yNDRmOThlZGciOiJFUzI1NiJ9.eyJhdWQiOiIxMiaWF0IjoxNjY0NTMyODM4LCJqdGkiOiIwNTVkZGI1OS1lNTkxLTQ4YTYtODcxMC02NGIzNzFkN2EwMmIiLCJ1c2VybmFtZSI6ImZsYW1hbGV4MUBnbWFpbC5jb20ifQ.7Fyq-Bctu2_5Hd_CxcAamBp31N3ImwEqf2fmCBQRDNnPiIxbgpNBdvjp2XqDHHGVZeNBX-vs1SDRydQ
1664776038
<!DOCTYPE html><h2>Valid token.</h2>

{
  "wattHoursToday": 6275,
  "wattHoursSevenDays": 20939,
  "wattHoursLifetime": 27614,
  "wattsNow": 649
}

donc ça avance

 

et merci à github, le sujet ci dessous m'a bien orienté 

https://github.com/dlmcpaul/EnphaseCollector/issues/22

 

 

sur jeedom ça donne ça

c'est good :) 

image.thumb.png.9d9b60b735374899051cd8677322bd34.png

 

 

image.thumb.png.5ecc7493dc664c62fb208baf9fb1d61e.png

 

image.png.b9fe1579f42e9c37e0a31f947d677132.png

 

Modifié par flamalex
  • Like 1
Posté(e)

Sur HC3 avec le firmware Envoy v5 ça donne ça :

 

image.png.beb285f8878026bf1b960cb07173f319.png

 

Il faudra quand même que je me penche sur cette histoire de token en v7 quand même....

 

Posté(e) (modifié)

@Nico  @Lazer  Merci 

 

oui @Lazer

en attendant, solution alternative, je vais aller chercher les valeurs sur jeedom pour injecter dans HC3

je sais comment faire sur HC2, mais sur HC3, je n'ai pas pu encore me pencher deçu 

 

mais c'est l'objectif

 

Modifié par flamalex
Posté(e) (modifié)

avec mon python tokentest.PY je genere l'acces en auto et produit un json 

admettons que je n'utilise pas le plugin script jeedom pour sortir les valeurs du json

est ce possible avec la HC3 d'aller les chercher sur le RPI jeedom et les afficher directement sur la HC3

le but etant d'eviter une usine à gaz

Modifié par flamalex
Posté(e)

Tu peux le faire dans les 2 sens :

- un QA actif qui va chercher (par polling à intervalle régulier) les infos sur Jeedom

- un QA passif qui est mis à jour (par push) depuis Jeedom

 

Au choix... selon tes compétences en programmation.

Posté(e)

Après moi je préfère au final les valeurs avec mes compteurs à part, car la partie Envoy avec le PowerReducer raconte un peu nimp, seule la production est juste.

Posté(e) (modifié)

Vu que je n'ai toujours pas pu passer de câble entre le garage et la maison, la passerelle Envoy n'a pas la mesure de consommation de maison... du coup le problème ne se pose pas.

D'ailleurs on constate sur la capture d'écran de mon QuickApp que seule la production photovoltaïque apparait, la consommation n'est pas présente.

 

La consommation, je la mesure avec l'EcoDevice RT2.

 

Alors justement, il est temps de faire un premier bilan après 6 mois de production photovoltaïque.

Le graph suivant permet de comparer la production théorique (simulée avec PVGIS) et la production réelle, ainsi que l'autoconsommation estimée versus réelle :

 

large.45614575_Suivi_production_et_autoconsommation_simul_vs_rel_septembre_2022.png.5b974727d7cc7c9aad0b7b31f821780e.png

 

On peut ignorer mars car j'ai branché les panneaux en fin de mois, ce n'est pas représentatif.

 

Si on compare les courbes bleue et grise, à quelques différences près (mois plus ou moins ensoleillé), ça se suit bien.

En ce qui concerne l'autoconsommation réelle (en jaune), c'était pas terrible en avril, car il manquait le routeur PV pour le chauffe-eau, et je n'avais pas encore optimisé mes scénarios domotiques (déclenchement des gros consommateurs quand le soleil est présent)

Depuis ça va beaucoup mieux, et particulièrement en juillet/aout, avec les multiples canicules à répétition, la climatisation a bien tourné.

Les 2 voitures ont été rechargées quasiment gratuitement jusqu'à mi-septembre, et ça c'est super cool. Mais depuis 15 jours, la météo commence à être mauvaise pour disposer de suffisamment de soleil pour recharger les voitures, donc ça tire en partie sur le réseau.

 

Taux d'autoconsommation global sur les 6 mois : 69 %.

Il va augmenter avec l'hiver et les optimisations de mon installation.

 

Bref, ça se présente bien, pas de mauvaise surprise :)

EDIT : et je viens de dépasser les 500€ de gains/économies :D
Déjà 8% de l'installation amortie en 6 mois.

 

Modifié par Lazer
×
×
  • Créer...