Nuova API sito GME #42
Comments
Ciao, non l'avevo notato... certo che sono riusciti a fare uno pure peggio del precedente....
Almeno questo sì è migliorato.
Molto bene, di là (sul vecchio) non c'ero riuscito.
Da browser c'ho messo un bel po' a ritrovare il link (QUESTO) da dove scaricare lo ZIP. Per fortuna non hanno cambiato il formato interno.
Ho visto, purtroppo io non sono del mestiere 😉 ma più un hobbista, quindi mi sono arrangiato un po' con Google per risolvere il problema (no IA). I match case ad esempio li avevo evitati perché mi sembravano meno leggibili... 😮 però effettivamente mi pare che la tua versione vada molto bene. Il chaining degli operatori ( Vabbè, sono qui per imparare!
Intendi il discorso che facevo sotto del calcolo del totale della bolletta (sperando che nel frattempo non ci cambino il PUN)?
Certamente, grazie! |
|
Ciao @virtualdj , Per quanto riguarda le API si avevo provato anche io con la tua repo in locale ma era troppo complicato usare bs4, per quanto hobbista hai escogitato un metodo non banale per emulare quel download! 👌 Ad ogni modo si i match li ho usati con parsimonia perche' comunque prediligo la leggibilita' del codice alla pura performance, ma dove si puo 😁 Per il futuro intendevo sia l'integrazione della bolletta, che ho "simulato" anche io con helper & Co. e vorrei aiutare a integrare, e sia per quanto riguarda la questione delle zonali, che sul sito nuovo sembra oltretutto essere gia' disponibile, anche se non ho capito assolutamente nulla di come funzioni 😂 Comunque ho testato il fork e sembra funzionare, magari proviamo a farlo girare un paio di giorni, magari anche su qualche altra istanza giusto per sicurezza, ho fatto altre due modifiche che ora committo e per ora lo sto facendo girare su docker e ha recuperato zip e settato tutto correttamente. |
|
Comunque giusto per provare ho buttato su sulla seconda istanza Docker il tuo fork e c'è qualcosa che non va sul calcolo delle fasce. Dal log vedo questo: Come vedi sbaglia a calcolare la prossima fascia (la mette nel passato) e questo causa un loop continuo che blocca tutto. |
|
Si avevo notato 😂 Mi era fatto prendere la mano con quei comparison e ne ho messo uno che non poteva ritornare vero nemmeno se pregavo 🤣 In teoria ho fixato tutto, quando poi hai tempo puoi provare ad aggiornarlo da hacs :) |
|
Scusate se mi intrometto ma vorrei seguire la discussione perché avendomi fatto scoprire che il sito è cambiato ho paura che prima o poi dovrò rimettere mano al codice per scaricare i prezzi zonali, che avevo realizzato con il componente multiscrape, e in questa discussione vedo la possibilità di trarre spunti utili. Se posso dare il mio piccolo contributo (ne so mooooolto meno di voi), se utile e non indiscreto, credo che l'endpoint per accedere ai prezzi zonali in XML sia il seguente Ovviamente usato così nudo e crudo non funziona, restituisce un errore, ma non se se è una problematica di referrer come menzionato sopra, o di cookie (tramite l'accettazione delle condizioni di uso nella videata che ora è un pop-up). Pagina web con i prezzi zonali: |
Domanda, visto che non me ne intendo invece di prezzi zonali... ma questi non sono dentro nel file XML che scarica già l'integrazione come ZIP (uno XML per ogni giorno)? Ogni ora dell'XML ha questi dati: <Prezzi>
<Data>20240509</Data>
<Mercato>MGP</Mercato>
<Ora>1</Ora>
<PUN>94,320000</PUN>
<NAT>94,320000</NAT>
<CALA>94,320000</CALA>
<CNOR>94,320000</CNOR>
<CSUD>94,320000</CSUD>
<NORD>94,320000</NORD>
<SARD>94,320000</SARD>
<SICI>94,320000</SICI>
<SUD>94,320000</SUD>
<AUST>94,320000</AUST>
<COAC>94,320000</COAC>
<COUP>94,320000</COUP>
<CORS>94,320000</CORS>
<FRAN>94,320000</FRAN>
<GREC>94,320000</GREC>
<SLOV>94,320000</SLOV>
<SVIZ>94,320000</SVIZ>
<BSP>94,320000</BSP>
<MALT>94,320000</MALT>
<XAUS>94,320000</XAUS>
<XFRA>94,320000</XFRA>
<MONT>94,320000</MONT>
<XGRE>94,320000</XGRE>
</Prezzi>E noi di questi prendiamo solo il |
Ho testato la API e non funziona nemmeno con il referrer, pero' penso che potrebbe essere un API interna del sito, quell'item mi sembra una route di react. dove l'hai trovata? 😂 In compenso il pulsante che scarica l'excel con i dati sembra essere un endpoint pubblico, regolando la granularita' penso che si possano ottenere dati di un mese o piu', per l'estrazione dei dati probabilmente un excel e' anche meglio di un XML👌 |
Sono loro, allora il file zippato contiene già tutto. |
Con Firefox, analizzando la pagina, con l'inspector, nella sezione "rete" mostra le chiamate che vengono effettuate.
Ho sempre cercato di non dover scaricare file in locale, ma probabilmente l'approccio è diverso/la necessità è differente quando si sviluppa un component per homeassistant. Mannaggia a loro che nel vecchio sito hanno il pulsante per ottenere l'XML direttamente e qui invece è stato tolto :| |
sisi ma ho provato da powershell con referrer e mi restituisce errore di auth, per quello penso sia interna, sicuramente non e' pubblica 😂 l'excel in realta' si potrebbe caricare in memoria direttamente quindi non sarebbe comunque un problema :) |
Ma è già così, in memoria, mica fa un file... |
sisi lo so, era in risposta al commento di @g1za 😂
|
|
@moddroid94 Ah ok, il potrebbe mi ha tratto in inganno... |
|
Da qualche tempo riscontro un problema sul download dei dati: |
@Tagliax Semplicemente, il sito fa abbastanza schifo e quindi capita che non risponda... Ma niente paura, se leggi bene i log vedrai che c'è il meccanismo di retry che raramente fallisce completamente. Prova a leggere sotto quella riga, se non ci sono altri warning significa che il successivo tentativo è andato a buon fine. Quindi prendi il log per quello che è, un warning, che non pregiudica affatto il funzionamento dell'integrazione. Certo, si potrebbe silenziare, ma non credo abbia senso: io preferisco sapere se e quando il download fallisce. |
|
Ciao @virtualdj si ho notato i retry, ma anche quello di 1 ora sembra andare KO, ho preso il primo log. |
|
@Tagliax Nella norma per loro! Io direi che qualcosa lo dovrebbero pure sistemare 😄 Come puoi leggere ha fallito il primo tentativo, quello dopo 1 minuto, quello dopo 10 minuti, quello dopo 60 minuti e quello dopo 120 minuti e dall'1 di notte siamo andati a finire alle 04:11! Però alla fine, alla sesta volta, ce l'ha fatta 😄 Vedi @moddroid94 che il sistema di retry fatto così aveva il suo perché? 🤣 |
|
@virtualdj Io sospetto che loro in quel lasso di tempo eseguono operazioni di backup notturno, altrimenti non si spiegano questi down… 😅 |
|
Ciao @virtualdj Avevi visto questa? https://gme.mercatoelettrico.org/it-it/Home/FTP |
Mi pareva di averla notata, sì, quando si parlava del nuovo sito. Tecnicamente l'FTP c'era già prima, solo che non credo offra molti vantaggi... prima di tutto, tocca fare tutta quella trafila con "carte bollate" 😄 e poi mi pare molto più semplice pescare i dati giornalieri direttamente dall'endpoint HTTP, posto di aver spuntato le caselle di esonero responsabilità. |
L’ho segnalato perché ho l’impressione che poi tutto sarà sul nuovo sito e spegneranno il vecchio. |
È già stato fatto nella PR #45 solo che non l'ho ancora unita perché stavo aspettando che l'autore sistemasse le rifiniture al codice. È disponibile in "alfa" nella pre-release 0.9.1 (sì, antecedente all'ultima proprio perché bisognava sistemare il codice). Purtroppo in questo momento non ho il tempo sufficiente per dedicarmi a questo progetto, ma fintanto che funziona teniamo duro. Appena possibile sistemerò tutto, ma mi serve tempo e calma. |
Allora perfetto! :) ottimo così! |
forse si potrebbe impostare un selettore all'interno dell'integrazione in modo che l'utente scelga il prezzo zonale orario della zona di mercato elettrico in cui è connesso l'impianto fotovoltaico :) e quindi lo script lo vada a leggere dall'xml già scaricato ed impostare nel sensore del "prezzo zonale orario". Io fino ad oggi l'ho fatto con multiscrape ma ormai il sito è andato e non ho tempo (e forse non saprei nemmeno come :( ) di rifare tutto con il sito che in ogni caso andrà avanti fino a dicembre 2024 :(, il lavoro nell'integrazione invece è già fatto o quasi :), il problema maggiore è che avremmo da n. 0 a 23 prezzi orari (n. 24 prezzi in totale) e non più uno come nel caso del PUN quindi dovrebbero essere inviati al sensore con il tempo giusto per aggiornare lo stato ogni ora (io facevo così con un trigger), HA non permette di creare stati "futuri" quindi il sensore del prezzo zonale orario per le successive 24 ore credo sia impossibile da fare dato che i prezzi del "giorno dopo" vengono pubblicati intorno alle 14 del giorno precedente. il prezzo zonale sarebbe utile da indicare in plancia energia per il rendimento del fotovoltaico e per avere un'idea del prezzo dell'energia immessa durante il giorno (io facevo anche una tabella con le 24 ore con un valore per ogni sensore del "giorno dopo" per sopperire all'impossibilità di avere un sensore con "stati futuri :) mentre per il prezzo zonale del giorno corrente non ci sarebbero problemi. |
|
@MicheleMercuri per un fix veloce valido fino al 31/12 basta che aggiorni le resources del multiscrape come indicato qui Se il prezzo zonale non verrà implementato nella nuova versione del componente (alla fine non ho capito se sta venendo valutata come possibilità) un'opzione è usare il portale ENTSO-E e appoggiarsi alle loro API (bisogna richiedere accesso), a meno di non studiare come fare scraping dal novo sito GME (oppure farsi una fork di questo progetto e riadattarla per i prezzi zonali). |
|
Ok grazie, proverò ad aggiornare. Ho provato a fare uno scarpe sul nuovo sito del gme ma non è possibile selezionare le zone di mercato elettrico, non è nemmeno possibile effettuare il download del file xml (sarebbe la cosa migliore) con tutti i dati perché mi rifiuta la connessione (ho provato velocemente con uno script in ha ma nisba) ho provato anche con uno script in una pagina HTML e nemmeno così ne vuole sapere, credo sia un problema di autorizzazione che non credo sia facile superare. |
Non era nei miei piani perché principalmente non lo uso e non so come funziona. Supponiamo ad esempio che io imposti l'ora di download alle 16. Se oggi è il 3/10, alle 16 scarico l'XML e poi tengo in memoria i prezzi delle 24 ore relative al giorno 4/10 (cioè il successivo). Il 4/10, ogni ora, aggiorno il valore di un sensore (es. "Prezzo zonale") con quello tenuto in memoria nel precedente download per quell'ora. È questo quello che state chiedendo? |
Il prezzo zonale orario è il prezzo con cui viene remunerata l'energia immessa in rete (da un impianto fotovoltaico), per chi ha un contratto RID (ritiro dedicato) con il GSE. L'energia immessa in rete ogni ora (-10% di perdite di rete) viene moltiplicata per il prezzo zonale orario = prezzo al quale verrà pagata l'energia immessa (- tassazione Irpef). |
|
Premetto che conosco la tua posizione, che hai espresso anche in passato e che non posso chiedere nulla oltre a quanto stai già facendo (utilissimo e comodissimo peraltro). Sono conscio dell'impegno che lo sviluppo comporta, quindi accetto tutto quello che verrà prodotto. :) Detto ciò... Il prezzo zonale è alla base del calcolo della remunerazione su base oraria dell'energia prodotta dagli impianti fotovoltaici privati ed immessa in rete. In realtà per il Ritiro Dedicato (RID - per lo scambio sul posto SSP è differente e più complicato con prezzi definiti dall'autorità) ci sono dei conti e formule dietro da fare che nemmeno ricordo più ma restiamo sul facile senza scendere in dettagli. Il valore è differente per area geografica, da cui "prezzi zonali". Sicuramente il caso d'uso più semplice è inserire questo dato nella dashboard di homeassistant per farsi calcolare o stimare il valore monetario dell'energia venduta. Io personalmente utilizzo un addon (EMHASS) che in base a consumi previsti, costo di acquisto dell'energia, prezzo di vendita (prezzo zonale) e previsione di produzione fotovoltaica ottimizza la gestione energetica dell'abitazione permettendoti di comandare acquisto/vendita da/alla rete, carica/scarica batterie, accensione/spegnimento di carichi variabili. Il tutto per massimizzando una funzione di autoconsumo o profitto. Per questo add-on io utilizzo i prezzi zonali di oggi e di domani (appena resi disponibili, di solito fra le 14 e le 15, altrimenti continuo ad usare quelli di oggi), in quanto faccio fare l'elaborazione su 24h rolling. Spero di essere stato esauriente e sufficientemente chiaro, altrimenti chiedimi pure. |
Quindi sarebbe opportuno esporre direttamente
Cioè intendi dire che se non sono disponibili domani userai i prezzi di oggi?
Intanto mi basta capire il concetto, poi appena potrò lo implementerò. |
Se posso io direi che sarebbe più opportuno recuperare il dato grezzo e poi lasciare all'utente la responsabilità di utilizzarlo nel modo corretto o come più preferisce.
EDIT: no intendo che io ho bisogno di 24h di dati (fra dati reali e previsioni/dati futuri). I dati di domani saranno sicuramente disponibili ma solo dopo le 14-15 di oggi. Fino ad allora, avendo comunque sempre bisogno di 24h di dati (uso una finestra di 24h rolling), utilizzo i prezzi zonali (ma anche i PUN a dirla tutta) di oggi in quanto ne sono una buona approssimazione (anche l'unica). Nel mio caso l'impatto è limitato dal fatto che l'elaborazione è in là nel tempo, oltre il cambio di data. Quindi quando sarò effettivamente al punto di aver bisogno di una elaborazione precisa con dati reali (un'elaborazione a breve termine) oramai i dati effettivi per la giornata saranno già stati resi disponibili (saranno oramai già trascorse le 14-15). |
il prezzo zonale orario pubblicato dal GME dalle 14:00 del giorno corrente in poi lo utilizzo dalla mezzanotte del giorno successivo moltiplicandolo per l'energia immessa nell'ora di riferimento calcolata con utility meter orario di HA, mai accaduto che non venisse pubblicato :). perchè il GME pubblica con un giorno di anticipo il prezzo dell'energia oraria, quindi devo per forza usare il giorno successivo quella pubblicata alle 14:00 del giorno corrente (spero di essere riuscito a spiegarmi :) ) ho ricontrollato i calcoli fatti dal GSE per il RID (in RID ci sono gli impianti al 110% e gli impianti oltre i 20 kW e da non sottovalutare le comunità energetiche perché incompatibili con lo scambio sul posto-SSP) la formula per il calcolo del prezzo di vendita è la seguente: energia * coeff_perd * prz_ora con le perdite vengono sommate e non tolte (ho sbagliato a scrivere perchè mi sono confuso con il prezzo di acquisto dell'energia :)) ecco gli screen a prova della correttezza dei calcoli che ti ho illustrato e dei corrispettivi pagati per l'energia immessa dal mio impianto: questo lo screen da sito GME dell'ora 14 e 15 zona immissione calabria del prezzo zonale orario: questo è il foglio di calcolo che scarico dal sito del GSE con i dettagli delle cifre che avrò dal GSE, l'ora 14 e 15 corrispondono alle 13 e alle 14 perchè il sito del GME nella tabella inizia dall'ora 1 a contare le ore dalla mezzanotte :) questo è l'importo che mi verrà pagato per agosto 2024 (ho optato per la liquidazione mensile senza il minimo garantito, perchè tanto è 0,04€/kWh e mi verrebbe pagato dopo quasi 6 mesi dalla fine dell'anno di riferimento, e perché immetto poco in quanto ho una Tesla e riesco a consumare gran parte degli 8.000 kWh prodotti :) e questo è la prova sommando le celle del calcolo dell'energia immessa sul foglio di excel con il dettaglio orario: spero si capisca tutto :) |
|
Interessante, sono riuscito a fare questa cosa dopo mesi di studio (l'ostacolo principale è stato il cookie...). file coockie.txt: e questo lo yaml: By(t)e |
|
@g1za nello script bash uso la variabile "DATE" come inizio e fine per i dati. DATE è in formato AAAAMMGG e dopo le 13 ( mi pare) sono disponibili anche i dati del giorno dopo. By(t)e |
|
Se volete iniziare a testarla, ho pubblicato la v1.0.0 come pre-release qui. In HACS è sufficiente attivare la spunta Show beta versions per vederla comparire nell'elenco. Non contiene ancora nessuna nuova funzionalità (a parte il download ad un minuto specifico anziché lo scoccare dell'ora), ma sarà la base di partenza per le prossime e soprattutto usa i dati dal nuovo sito GME. Intanto la metto in funzione nel mio sistema HA di test per una settimana, per vedere se ci sono problemi, per poi renderla ufficiale per tutti. |
|
Perfetto, grazie, lo metto sul mio server pure io ;). |
|
Anche io, con modalità debug abilitata; volevo mettere su un HA di test ma poi non avrei avuto la possibilità di verificarne bene il funzionamento :) |
|
Nuova pre-release (mannaggia a me che non ho capito come usare i tag beta nelle versioni 🤦♂️) per correggere un errore che mi era sfuggito nel calcolo... dopo il primo giorno sbaglia la media perché non cancella i dati precedenti. |
|
Non me ne ero accorto; a parte questo non ho notato cose strane. Mi sembra cambi le fasce correttamente. |
|
Bene, questa mi pare a posto 🤞 quindi rilascio in maniera definitiva quella che sarà la "stabile" v1.0.1. |
|
@g1za @MicheleMercuri Spero sia di vostro gradimento (e, soprattutto, corretto)! |
|
Ma grazie! |
|
@virtualdj un primo feedback che ti lascio è che sarebbe utile avere la stessa risoluzione del sensore PUN e zonale anche per i valori all’interno degli attributi, se possibile. Ho verificato e (a parte gli arrotondamenti, vedi commento sopra) per ogni ora di oggi corrispondono sia PUN che prezzi zonali (testato su Nord). Poi cercherò di verificare il comportamento dopo le 15, per vedere come vengono caricati i valori di domani. Anche il valore del sensore ora corrente PUN e zonale corrisponde a quello del GME (con stessa risoluzione in questo caso). Non ho pensato di salvarmi i prezzi delle fasce per confrontarli con quelli mostrati nella nuova versione ma immagino tu non abbia toccato questa parte di codice. |
|
Come non detto, si vede che è solo una questione di arrotondamento dell'interfaccia; nel pannello sviluppatore i valori negli attributi hanno lo stesso arrotondamento usato nel sensore orario: state_class: measurement |
Sì, infatti, come ti sei accorto è solo un arrotondamento dell'interfaccia che non credo si possa modificare.
Ottimo!
Teoricamente già ora dovresti avere quelli di domani già scaricati, perché quando cambi zona forza il download.
Bene!
No, nessuna modifica in quella parte. |
Quelli di domani (18 dicembre) non ci sono ancora, credo bisognerà aspettare dopo le 15 di oggi (17 dicembre). Questi i valori del PUN: state_class: measurement |
|
Ho verificato anche che i valori correnti di PUN e prezzo zonale si aggiornano correttamente allo scattare dell'ora, coerentemente con i valori orari negli attributi. Al momento non mi vengono in mente ulteriori controlli da fare, a parte quello delle 15. Ottimo lavoro. Grande! |
Sì ho sbagliato io credendo che il post fosse di "ieri" invece era già passata la mezzanotte 😁 |
|
Anche i dati di domani sono stati caricati e corrispondono al quelli sul sito GME. |
@g1za so che non è il post più opportuno ma potresti darmi indicazioni per come produrre il csv dei prezzi e come fornirlo a EMHASS. Non ho mai provato EMHASS ma penso che combinato con l'ultima versione sui prezzi zonali di questa add-on possa essere molto utile. |
Ciao, ho notato che e' online il nuovo sito di GME.
Il nuovo sito utilizza un endpoint API per scaricare il file zip, e ho pensato che si potesse semplificare la parte di download dal sito in quanto particolarmente convoluta.
Dopo un po' di tinkering sono riuscito a emulare una request che ci consente di scaricare lo zip senza fare scraping di valori sul sito con BeautifulSoup.
L'endpoint sembra essere di libero accesso, ovvero l'unico parametro che sembra essere importante per la request e' il referrer, che dev'essere la pagina di download del sito GME dov'e' situato il pulsante.
La request con la quale sono riuscito a scaricare lo zip e' la seguente:
Su Powershell
Quando la richiesta viene effettuata dal browser, vi e' un campo aggiuntivo:
requestverificationtoken.Ma anche omettendo il token l'API sembra funzionare da terminale o codice.
Con python basta impostare gli headers di una request con i seguenti valori e puntare all'url con i parametri giusti.
Endpoint:
"https://gme.mercatoelettrico.org/DesktopModules/GmeDownload/API/ExcelDownload/downloadzipfile?DataInizio=20240507&DataFine=20240507&Date=20240506&Mercato=MGP&Settore=Prezzi&FiltroDate=InizioFine"headers:
Non so se e' un problema di auth da parte loro o se e' inteso per essere pubblico, ad ogni modo anche dovessimo recuperare il token dai cookie/response dovrebbe essere decisamente piu' comodo.
PS. Ho forkato la repo e sto facendo un po' di clean up / spostamento di classi nei rispettivi moduli cosi' da seguire meglio le linee guida per le integrazioni di HA e rendere il codice un po' piu' leggibile, e possibilmente rendere piu' semplice l'adattamento ad un cambiamento come quello descritto qua #38
Se vuoi intanto dare un occhiata puoi trovarla tra le mie repo, non appena avro' testato le modifiche faccio una draft per una PR cosi da poter vedere insieme i cambiamenti.
The text was updated successfully, but these errors were encountered: