@nijel prosim te, je moznost v tom proteus api pouzit tuzticku a zmenit plan, pripadne upravit predpokladane spotreby/vyroby? hodilo by se mi to pri planovani nabijeni elektroauta v noci na nejnizsi cenu…
tak už mám také implementováno - trošku jsem se zadrhl na této zdánlivě nenápadné poznámce: ”V Proteovi musí být nastavené přihlašování heslem”. Netušíc, že na portál Protea se dá prokliknout z moje.deltagreen.cz (s heslem z “moje”), ale samostatné “přímé?” přihlášení heslem do Protea má přísnější podmínky pro heslo (chyběl mi speciální symbol) - a proto mám nyní hesla na DG rovnou dvě (@deltagreendeltagreen- je to nutné?)
=====
Co ale hlavně: ať nevynalézám kolo - byl by někdo ze zdejších expertů ochoten podělit se s příkladem toho, co a jak v HA navěsil na tuto neoficiální integraci?
A) konkrétně mám Solax měnič i Solax EVC - tam by se nějaké řízené zapnutí či naopak vypnutí hodilo, 11kW je super zátěž.
B) dále mám na chytré zásuvce pověšený bojler - ten aktuálně nějak vytěžuji podle sensoru sensor.solax_api_available_pv_power s přídatnými podmínkami sensor.solax_modbus_power_control - ale je to takové kostrbaté
C) a našlo by se ještě pár tepelných spotřebičů (podlahové topení), které by mohly reagovat na flexibilitu vlastně podobně jako EVC.
@David Když už se po změně měření zjevně tahle integrace začíná používat pro flexibilitu, vadilo by načítání dat častěji? Moje motivace doteď nebyla tím něco řídit, tak mi 30 sekund připadalo jako rozumný kompromis, ale pro spínání zařízení v rámci flexibility to už je možná málo.
Obecně nechci tím přetěžovat servery a netuším co použité API volání způsobují na druhé straně, web většinu změn asi tahá přes WebSocket, který se mi nechtělo zkoumat. Tak mi případně dejte vědět jestli nemám něco upravit .
A je spravne se chytat na sensor.proteus_prikaz_flexibility? Protoze ikdyz to je 30 sekund, tak to neodpovida casum, ktere jsou v rozhrani proteus. Zacatek je tak nejak v pohode, ale konec je skoro o dve minuty pozdeji.
Nevím, jestli to je správné, ale jiný způsob zatím není . Já pořád doufám v oficiální a dokumentované API.
Každopádně se občas stav nepodaří načíst kvůli chybě v SSL spojení, párkrát jsem to viděl i v prohlížeči. Jakákoliv chyba měla být vidět v logu a pokud to je něco jiného, můžu se na to zkusit podívat.
2026-01-01 17:15:23.134 ERROR (MainThread) [custom_components.proteus_api.proteus_api] Error fetching data
File „/config/custom_components/proteus_api/proteus_api.py“, line 123, in get_data
File „/config/custom_components/proteus_api/sensor.py“, line 76, in native_value
Nicmene i tak to by to asi melo vratit NONE driv nez 17:15 kdyz to podle proteuse bylo jen do 17:14
Tak budeme doufat, ze bude nejake API v blizke budoucnosti. Ja bych si dovedl predstavit, ze se budu ptat rovnou toho delta linku, ktery to prece musi mit nejak nactene taky a tim padem nebudu zatezovat zadny server.
Do 17:14 reálně znamená 17:14:59 (nebo něco podobného), takže nejbližší aktualizace by byla v těch 17:15:23.
Ale teď mě napadlo, že když vím čas konce flexibility, tak stav se může změnit podle toho a ne až se načte přes API. Zkusím dodělat do dalšího release.
PS: Verze 0.1.6 skončí flexibilitu podle naplánovaného času, takže to ve většině případů bude fungovat dobře i se stávajícím intervalem načítání.
API pro flexibilitu mame v backlogu. Bude signalizovat, jaky command prave bezi, ale je potreba pocitat s tim, ze command muze byt kdykoliv ukoncen driv nez v planovany cas (deje se to vzacne, ale stat se to muze).
Predtim je jeste ale nutne udelat upravy na frontendu na generovani tokenu.
EDIT: jinak z toho frontendu bych se nebal to queryovat kazdych 10s