@M_a_r_c_o modulatie heb ik in Tado enkel op radiatorventiel niveau in mijn systeem. Want de hoofdthermostaat is aangesloten op de cv-ketel via aan/uit relais wegens het ontbreken van OpenTherm. Gelukkig moduleert de ketel intern nog wel op basis van een eigen weersafhankelijke sturing.
Bedoel je soms dat het mogelijk moet zijn om de ventielen ook uitsluitend als aan/uit (niet-modulerend) te sturen zonder dat 25° trucje toe te passen? Want dat zou ook wel handig zijn voor mij. Ik heb er helaas zo niet meteen iets over teruggevonden.
heb een measure capability gemaakt die altijd de tijd in minuten aangeeft tot volgende verandering, dan krijg je de standaard changed/kleiner/groter dan kaarten. in de changed kaart zit dan de resterende tijd tag, die je kunt opslaan in een eigen var om te gebruiken.
Dit geld voor alle modi, timer, manual, scheduled. Dus in de logic moet je nog even kijken of de mode niet volgt smart schedule is…
Je krijgt 9999 als waarde indien mode is tot gebruiker hem beëindigd.
Hi Martin, dank voor alle tijd en moeite die je steekt in deze app! Helaas lukt het mij niet om 'm goed aan de praat te krijgen. Nu op 5.2.5 (maar al vanaf 5.2.2, en ook 5.0.13) loop ik volgens mij tegen steeds hetzelfde probleem aan. Ik vermoed dat het iets te maken heeft met authenticatie. Soms, wanneer ik opnieuw inlog en/of de app restart, werkt het setten van de presenceLock goed. De presenceLock is de reden dat ik de app wil gebruiken, om deze waarde te zetten zodra er niemand meer thuis is (en weer andersom zodra er wel iemand thuis komt).
Volgens mij zijn dit relevante log entries:
x 2024-01-09T08:43:10.273Z UnCaught exception: TypeError: Cannot read properties of undefined (reading 'heatingCircuits')
x uncaughtException:
TypeError: Cannot read properties of undefined (reading 'heatingCircuits')
at /app/drivers/tadoHome/device.js:80:41
at Timeout._onTimeout (/node_modules/@athombv/homey-apps-sdk-v3/lib/Homey.js:219:7)
at listOnTimeout (node:internal/timers:569:17)
at process.processTimers (node:internal/timers:512:7)
En:
x 2024-01-09T08:36:22.084Z [tadoHome] presenceLock Client request error: connect ENETUNREACH 2600:9000:2090:ca00:17:7ce2:d400:93a1:443
x 2024-01-09T08:36:22.081Z [tadoHome] userGeoLocation Cannot read properties of null (reading 'token')
x 2024-01-09T08:36:17.712Z * pollZoneStates() getZoneStates Client request error: connect ENETUNREACH 2600:9000:2090:4200:17:7ce2:d400:93a1:443
x 2024-01-09T08:36:17.696Z getZones() Client request error: connect ENETUNREACH 2600:9000:2090:ca00:17:7ce2:d400:93a1:443
x 2024-01-09T08:36:02.704Z * pollZoneStates() getZoneStates Client request error: connect ENETUNREACH 2600:9000:2090:6600:17:7ce2:d400:93a1:443
x 2024-01-09T08:36:02.694Z getZones() Client request error: connect ENETUNREACH 2600:9000:2090:e600:17:7ce2:d400:93a1:443
Ik heb een diagnostics report gemaakt: 94c68318-f01b-4b29-9bc8-4a6f9d1a24e3
Is er iets wat ik over het hoofd zie en nog moet configureren?
Voor wie het zou interesseren, mijn aangepaste flow waarmee ik de radiatorventielen regel als puur on/off. Nu rekeninghoudend met manuele tijdsperioden. Opmerkingen of verbeteringen altijd welkom.
@Martin_Verbeek
Vanmorgen 5.2.5 geinstalleerd op de Homey 2023.
Wat zou ik verkeerd kunnen doen als ik de “als” kaart van een TadoHuis " Warmte capaciteit wordt groter dan #warmtecapaciteit% " niet kan vinden?
Of werkt deze kaart alleen per zone, daar vind ik hem wel.
De thermostaat in de woonkamer is niet van Tado maar van Plugwise.
Die eerste error wordt in de volgende update voorkomen.
Ik zie dat de tweede netwerk unreachable geeft op IPv6 adressen, heb je p.o. een IPv6 only omgeving???
Voor zover ik weet heb ik geen IPv6 only omgeving, hoewel ik een Unifi Dream Machine heb, is mijn netwerk/omgeving verder vrij basic out of the box. Geen custom configuratie of iets.
Als kaart Tijd tot volgende wijziging is veranderd veranderd toch continue? Geeft dat geen risico dat de flow wordt gedisabled omdat deze te vaak wordt uitgevoerd en reset je niet continue de timer?
Ow ja je hebt gelijk! Ik ging ervan uit dat deze enkel getriggered wordt bij een manuele gebruikershandeling. Dank voor dit te melden! Back to the drawing board…
Mmm lastiger dan ik dacht… Stel in Tado: ik verander enkel de slider van de tijdsduur en raak verder niks aan. Dan wil ik in Homey de timer updaten. Maar wel op een manier dat dit maar eenmaal getriggerd wordt ipv de constante loop “bug” die er nu in mijn schema inzit
Als handmatig de temperatuur via de Tado app of via de fysieke knop wordt aangepast, blijft naar Homey “Slim schedule” actief.
Terwijl de Tado app “Tot het volgende tijdblok” actief te zien is.
Als via Homey de temperatuur handmatig wordt aangepast wordt wél “Tot het volgende tijdblok” actief.
@Martin_Verbeek is het vanuit dev/api standpunt mogelijk om de kaart “tijd tot de volgende wijziging” enkel te laten triggeren wanneer de gebruiker de tijdsperiode effectief verandert in Tado? Want zoals M_a_r_c_o al opmerkte gaat die nu continu af.
