Misschien nog een verdwaalde static in je client list dhcp? Of DHCP leases die niet vernieuwd zijn?
Check even je netwerk scope met client name of de ip adres statics de netmask nog /24
Aangezien je mac adres hetzelfde blijft gaat je AP client reservering vrolijk verder met de oude informatie……
Na je aanpassing van je netmask wellicht even alle oude reserveringen resetten.
Nu was m’n netwerk al vier jaar een /23. Daar zat geen verandering in. Nu naar een /24 omgezet. Inderdaad alle reserveringen omgezet, en in een tweetal (niet gerelateerde) device de handmatige IP adressering weer goed gezet.
nu even wachten tot alles weer tot rust is gekomen, had dit eigenlijk moeten voorbereiden door een zeer korte leasetijd te maken, en pas na aflopen oude leasetijd+nieuwe leasetijd de ip adressen te veranderen. Maar dit werkt ook. (uiteindelijk).
Tussen het snoepen van paaseitjes door een indicatie proberen te maken wat er “verdient” kan worden aan het inzetten van de batterij tijdens dure uren. Het is niet actief terugleveren maar eigenlijk de batterij inzetten (ontladen) tijdens een duur uur welke je anders zou betalen met energie van het net.
Grijs stippelijn is je eigen gemiddelde huisverbruik van die dag (maandag, dinsdag etc verschillen)
Groen = meeste profijt
Oranje = matig
Grijs = minimaal
Geen idee waarom, maar nu alle devices in een /24 netwerk ipv een /23 netwerk staan kon ik eindelijk weer de P1 koppelen, en werkt de Homey Bridge en de Homey energiedongle ook weer.
Lijkt dus echt een issue in de laatste release van Homey.
Positief is dat ik nu wel mooie ubitique Wifi accesspoints heb 
Ja mooi spul, ben er ook erg blij mee.
Nieuwbouw woning alleen niet leuk met beton en staal.
Had je trouwens geen overlap met je /24 en /23 ?
Versie v3.15.1 (nu test / beta)
Battery Policy — Belangrijkste wijzigingen (v3.15.1)
n × 800 W; nu overal gecorrigeerd (policy, explainability, _getBatteryState()).max_consumption_w / max_production_w alleen nog als het veld echt bestaat; ontbrekende velden worden niet meer als 0 geïnterpreteerd.getDailyProfile(dayOfWeek) geeft 96 voorspelde wattage‑slots terug.computeExpectedProfit() berekent winst voor 1–4 batterijen zonder de live planning te wijzigen.
_runBackwardDP() is nu volledig puur en herbruikbaar._schedule bevat nu ook projectedProfit voor uitbreidingsanalyse.Nee, had een hele nette /23. Die ik dus nu gehalveerd heb naar een/24.
Rekenen met IP netwerken, daar kan je me nog steeds s’nachts voor wakker maken 
.
Helemaal goed, bij een ISP gewerkt was ook dagelijkse kost. 
Batterij Policy werkt steeds beter nu, vannacht nog een vreemde melding over 1792w PV opwek om 05.19 uur. Opzich maakt de beslissing om van Zero_discarge_only naar Zero te gaan op dat tijdstip effectief geen verschil maar toen was het nog donker dus is opwek onwaarschijnlijk.
Die had ik ook, open-meteo kwam met een foute PV schatting terwijl zon nog onder was. Inmiddels aangepast dit te negeren. Zal straks weer update pushen.
Wordt de sluipverbruik data op een gegeven moment ook weer gewist? Ik zie in het overzicht data van willekeurige data terug tot januari, niet van alle dagen. En daarom vraag ik me af hoe de opslag van deze data wordt gemanaged.
30dagen met data en dan kan de tijd iets langer zijn van de 30 dagen maar gaat om 30x datapunten die gebruikt worden om een gemiddelde te bepalen.
Ok. Duidelijk.
In engelse termen “sliding window” van 30 meetpunten, als er nu weer afgelopen nacht een geldig meetpunt komt zal de oudste ergens in januari bij jou worden verwijderd. Met 30 samples is er een redelijk gemiddelde wat het “sluipverbruik”. Focus is ook gedurende de nacht dat meeste (uitzonderingen worden uitgesloten) apparatuur uit om “ruis” tegen te houden.
Versie v3.15.2 naar test gezet.
Ik denk ook dat die verkeerde waarde van PV samenvalt doordat er geen verbinding mogelijk is/was met open-meteo (werkzaamheden / onderhoud?). Aangezien ik ook data vooruit ophaal en in cache zet.
Versie v3.15.3 nu live.
Even een vraag, vandaag kwam een update van de Homewizard app. (iPhone) Dit in voorbereiding van de Homewizard laadstrategie. Kan je eens deze functie vrij is gegeven ook de Homewizard laadstrategie instellen via de Homey app?
Sorry ik volg je niet.
Homewizard komt binnenkort met hun eigen laadstrategie functie. Zie:
Kan je dan als deze functie beschikbaar is. Via Homey de batterij op één van de drie strategieën zetten? Optie drie en één gebruiken wij nu natuurlijk al, maar de slim laden functie ga ik zeker ook even testen. Als dit heel goed blijkt te werken kan ik mij zo voorstellen dat de batterij hier de meeste tijd op zal draaien. Maar ook dat er situaties zijn dat mijn eigen logica het beter kan bepalen.
Of gaat het zo werken dat de batterij standaard op NOM of Slim laden staat totdat je via de API een opdracht geeft en daarop blijft staan tot dat je de batterij weer op zero mode zet. Heb je daar zicht op?
Hoi Johan,
Geen idee wat en hoe er kan en mag. API documentatie is nog niet bijgewerkt dus voor mij gissen. Ik verwacht wel een mode “slimladen” waarmee ik kan zien via de P1 dat deze mode actief is. Maar of ik die kan veranderen naar zero of iets anders en weer terug naar “slimladen” weet ik niet.
Binnen de optie “Local API” heb ik zelf nu ook een “battery policy” device gebouwd die rekening houdt met zon, tarieven, huisverbruik, vooruitkijken.
Er zit een leer proces in voor huisverbruik, zonverwachting / straling in relatie tot je omvormer (bijsturen verwachtte kWh vs werkelijke opbrengst die dag).
Het enige wat ik niet kan wat Homewizard schrijft is net congestie in de wijk.
