Gevonden, zou vanaf versie v3.14.29 moeten werken
Bedankt voor de snelle actie!
Ik negeer export kwh als het kleiner dan 1kwh is.
Je socket zit op 0.822 kwh dus sla ik het over.
Gaat al een stuk beter nu op misschien een klein dingetje na;
Om 00.15 vannacht werden de batterijen op standby gezet. Ik denk omdat de prijzen in de ochtend en avond erop hoog zijn en de zonopbengst laag dus tot zover kan dat wel kloppen. Echter was de soc 85% (iets van 9 kWh) dus het lijkt mij iets te vroeg. Ik heb de batterijen geforceerd naar zero gedurende de nacht en de policy om 07:00 weer ingeschakeld met een soc van 50%. Lijkt er nu op dat er voldoende geladen kan worden voordat de dure avonduren beginnen, zoniet was het besluit tot standby afgelopen nacht wel correct en ik eigenwijs. Het blijft moeilijk met zoveel variabelen…
Leuk om te horen, wat je nog zou kunnen proberen is min/max respecteren naar nee.
Dan is er iets meer flexibiliteit in tarieven (opportunistic).
De variatie van veel zon op een dag, naar vandaag alleen maar bewolking maakt het lastig tunen nu. Bovendien zijn de tarieven nu structureel “te” hoog merk ik. Waar we ruim een maand geleden nog 0.20 hadden in de nacht zitten we nu soms op 0.30-0.35.
Sinds een aantal dagen heb ik een error op de home wizard energy socket:Apparaat is niet beschikbaar. Ik kan hem wel met de Homewizard app bedienen. API staat aan. Ik kan hem ook niet als een nieuw device toevoegen.
Iemand een idee?
Dan kan je homey niet bij je stekker komen via wifi.
Gok dat je fetch / timeouts hebt in je debug tab.
Wellicht access point even herstarten? Meer tips in eerste post in dit topic.
Homey → Apps → Homewizard app → Settings/instellingen →
1 Like
Bedankt Jeroen, dat was de juiste hint. Ik had al eens de stekker uitgetrokken en weer ingestoken, ermee geschakeld. Nu in mijn DECO even geblokkeerd en weer gedeblokkeerd en toen werkte hij weer. Raar maar waar.
1 Like
Straks in test versie (moet nog wachten op laatste stable push).
Battery policy nu grafiekjes als “webcam” image
Vandaag + morgen + dashboard widget (nog mee bezig)
1 Like
Absoluut geen kritiek maar uitsluitend feedback;
Prijs in de ochtend is mega hoog dus zero_disharge_only zodat de dure pv opwek naar het net gaat en het verbruik uit de batterij komt is een logische.
Maar zodra de pv even wegvalt wordt er gekozen voor standby met als gevolg dat ondanks de hoge prijs het verbruik uit het net komt terwijl de soc nog ruim toereikend is…
Is dat zo bedoeld of een oorzaak van rekenen met zoveel variabelen?
Nee inderdaad fout, had deze ook gevonden. Ik zit met een batterij die leeg had moeten zijn maar steeds uitstel omdat er later een duurdere prijs gezien was.
Om 5:45 en iets eerder waren goed genoeg om te ontladen.
Ik stuur straks verbeterde versie. En kritiek is ok, ben blij dat je de code probeert met je 4 batterijen tov mijn 1. Andere parameters maar uiteindelijk wel zelfde doel.
Versie v3.14.31 is nu in test. (edit)
- webcam image fix voor volgende dag prijzen
- overige changes in changelog → [APP][Pro] Homewizard 🧙♂️ - #2 by Jeroen_Tebbens
staat erop, gaan we weer verder met testen…
1 Like
Hoi Jeroen,
Na een update van m’n wifi naar een goed iot netwerk werken alle homewizard devices in de homewizard eigen app. De accu’s ook zonder issue’s in Homey. Alleen de P1 meter weigert connectie te maken. Ik heb eerst geprobeerd het IP adres te wijzigen in de Homey app. Dat lukte niet. Kreeg het nieuwe op adres niet opgeslagen.
Dus dacht dat verwijderen en opnieuw toevoegen een goed idee zou zijn. Daar ben ik nu van terug gekomen. Ik krijg de P1 meter niet meer gekoppeld.
Ik kom tot het scherm autoriseren, hoevaak ik ook op het knopje van de p1 druk (kort, of lang) ik kom niet voorbij dat scherm.
Enig idee hoe nu verder?
jacques
Hallo @Jacques_Eding , vervelend dat het nu niet meer werkt.
Ik gok/denk dat dit komt doordat mDNS niet goed gaat in je IoT netwerk. Zit je homey ook in dat zelfde wifi netwerk?
Verder welk merk wifi heb je nu Unifi/Ubiquiti? Er staan wat tips in eerste post van dit topic of in de engelse over broadcast omzetten naar unicast (technisch) maar dit breekt bijvoorbeeld de functionaliteit die nodig is.
Daarnaast kan je de manier van Homewizard via de cloud (hun app) niet vergelijken met de manier zoals ik dat lokaal doe. Homey praat rechstreeks met je Homewizard devices. En je dus je Homewizard deze verplaatst hebt lijkt mij dat nu waarschijnlijk dat je Homey in een gewoon wifi netwerk zit en bijvoorbeeld door beveiliging niet meer bij je IoT netwerk mag.
Lastige puzzel maar wel de kern van je probleem eeeeh uitdaging. 
1 Like
Hoi Jeroen,
Wat ben je steeds snel met je antwoord 
Ik zie de homewizard devices netjes in de discoverytool staan, met het goede IP adres. Ik krijg als ik een tweede keer probeer een error pop-up met de melding “ request to https: X.X.X.x/ap/user failed, reason:connect: ETimedout.
Als ik vanaf m’n eigen systeem die url opvraag krijg ik een pagina met: Nothing matches the given URI.
Ik dacht dat de accu’s geen issue hadden, in homey maar zie nu dat hun status ook niet meer is geupdate. Ze geven alleen niet aan dat ze niet meer gekoppeld zijn.
Ik heb filtering tussen verschillende netwerken uitstaan. Multicast filtering, blokker en multicast to unicast staan op alle netwerken uit, en zowel homey als de AP’s herstart.
Homey is gekoppeld aan hetzelfde Wifi netwerk (en met een ethernetdongle ook aan hetzelfde IP netwerk). Het kan niet zo zijn dat een groter netmask dan de gebruikelijke /24 een issue is toch?
Dit geeft de discovery tool, ik zit met m’n mac ook op wifi, wel andere SSID.
p1meter-123816._homewizard._tcp.local.
p1meter-123816.local:443
192.X.X.X:443
XXXX::XXXX:XXXX:XXXX:XXXX%en0:443
IPV6:443
api_version = 2.2.0
id = appliance/p1dongle/5c2faf123816
product_name = P1 Meter
product_type = HWE-P1
serial = 5c2faf123816
Heb je toevallig AP client isolatie aanstaan in je IoT netwerk? Soort van Guest wifi netwerk instellingen dat Wifi apparaten niet met elkaar mogen “praten”.
Aangezien je van wifi veranderd ben zou het kunnen zijn dat dit vinkje in je wifi instellingen van je IoT netwerk aanstaat?
Ik heb dit in mijn Unifi IoT ingesteld als in vinkjes uitgezet:
1 Like
Client isolation was ook mijn eerste gedacht, maar het is dan wel raar dat ik vanaf m’n mac op de discovery tool wel de devices zie, en de api wel bereikbaar is vanaf m’n Mac. En toch ook dat homey de P1 ook ziet maar pas bij autorisation stopt?
Mijn Instellingen:
mDNS (Multicast DNS) staat los van Client Isolation. Het is een broadcast protocol (Apple’s bonjour) exact dezelfde techniek. Er wordt puur door de Homewizard devices op je wifi geschreeuwd “ik ben aanwezig en dit zijn mijn ip en pad gegevens”. Maar…Client Isolation…er zit een muur tussen je hoort het wel maar je ziet ze niet.
Maar goed je screenshot laat zien dat het uit staat dus die vlieger gaat nu niet op. Heb je in je Unifi Insights gekeken of er iets geblokt wordt? Je zegt dat Homey ook op IoT netwerk zit? Zelfde AP of ander? Misschien IOT (VLAN) probleem niet goed overal mee gegeven?
In plaats van https te proberen kan je ook even de APIv1 manier testen.
Hier zit geen token check op dit werkt altijd (mits local api aanstaat in de Homewizard Energy app devices)
http://x.x.x.x/api/v1/data
1 Like
Ik heb inderdaad ook bji insights gekeken, er wordt niets geblokkeerd. Heb nu met m’n twee AP in gemeshde configuratie en in niet gemeshde config getest. Beide AP’s geven dezelfde (3) netwerken.
Het lijkt trouwens wel een homey issue, ook m’n bridge en homey energy dongle zijn uitgevallen, en koppelen van de bridge gaat goed, tot na koppelen een een wifinetwerk en ophalen updates. Ik kan ook niet bij de lokale web interface van de homey. SSH werkt nog wel.
De P1 geeft met z’n api V1 gewoon data, vanaf m’n mac. Met SSH vanaf de homey krijg ik via Curl ook de API V1 gegevens uit de P1.
In homey de P1 met de V1 api installeren werkt dan weer niet.
Ik snap nu werkelijk niet meer waar ik het nu nog moet zoeken..
