Domoticz - open source domotica systeem - deel 5

[Rolandtwilt]

Knielen schreef op woensdag 8 februari 2023 @ 08:25:
[...]


Op de Domoticz wiki staat een hele lijst met compatibel camera's

https://www.domoticz.com/wiki/Hardware#IP-networkcameras

een netwerk camera of ipcam is toch iets anders dan een videodeurbel, of ben ik gewoon blont?

[Rolandtwilt]

wimmme schreef op woensdag 8 februari 2023 @ 12:11:
[...]


Je moet gewoon voldoende info meegeven bij je vraag, dat helpt
Hangt ervan af wat je al hebt qua hardware. Heb iets als een RFLink of RFXCom ? Dan kan bijna elke draadloze deurbel al voldoende zijn. Of iets als dit aan je bestaande deurbel hangen.
Als je (nog) geen 433 in huis hebt, kan je via een Shelly Uni ook rechtstreeks koppelen met Domoticz over Wifi (als je Wifi ok is aan je deurbel). En voor de rest zijn er nog oplossingen via Zigbee, ZWave, ...

Hoi,
ik heb een RFLink 433 en de 868, en Zigbee, werk ook met Tasmota maar ben ik geen fan van. Met Shelly heb ik geen ervaring. ik dacht zelf aan de video deurbel van de Action bijvoorbeeld de LSCVideo Doorbell + Chime, of een Ring? Het belangrijkste is dat er in ons woonhuis op iedere verdieping een bel word geïnstalleerd. Hebben we nu ook van het merk klik aan klik uit en dus een melding op de iphone als je niet thuis bent. Ik hoop dat ik het een beetje duidelijk heb uitgelegd, kom soms wat verstrooid over.
Alvast bedankt voor het mee denken!

[MikeOO]

Rolandtwilt schreef op woensdag 8 februari 2023 @ 19:08:
[...]


een netwerk camera of ipcam is toch iets anders dan een videodeurbel, of ben ik gewoon blont?

Op zich niet. Ze kunnen allebei hetzelfde. Een videodeurbel is alleen compact en hang je op naast je voordeur.
Paar draadjes aansluiten of 1 op een batterij en klaar.

Een losse camera hang je meestal wat hoger op bij je deur in zodat je meer van boven beeld krijgt en bij sommige camera's is hierdoor de kijkhoek een stuk groter. Aansluiten is wat meer werk omdat je een netwerkkabel en/of voeding naar de camera moet maken. PoE camera's zijn dan weer handiger omdat de voeding dan via de netwerkkabel verloopt en je dus maar 1 kabel hoeft aan te leggen. Maar je heb dan wel een PoE camera en PoE kastje of switch nodig. Klinkt ingewikkeld maar is het niet

Nadeel is wel dat je hierdoor niet altijd de persoon duidelijk kunt zien qua gezicht omdat je van bovenaf filmt.
Daarbij heb je dan een losse deurbelknop nodig die werkt als een trigger voor de camera.

De meeste camera's kunnen prima een snapshot maken en zodra iemand aanbelt start je in Domoticz en script die een snapshot maakt en deze verstuurd naar je mobiel via bv Telegram.

Zelf heb ik bv 1 camera boven de voordeur en 1 in de nok van het huis. Als er aangebeld wordt krijg ik dus 2 foto's via Telegram. Zo kan ik zien wie er bij de voordeur staat maar krijg ik ook een breed overzicht van de voorkant van het huis.

Voordeel van een losse camera is weer dat het beeld vele malen beter/scherper kan zijn. Je bepaald tenslotte zelf welke kwaliteit camera je koopt. Welke dat moet zijn, gewoon reviews lezen en beelden bekijken. Er is voor elke camera op youtube wel filmpjes met de kwaliteit van het beeld.

En hoe dit moet ik Domoticz is al vaak besproken dus eenvoudig terug te vinden.

Belangrijk is welke type of soort camera je ook neemt. Check vooraf op internet hoe het beeld is als het donker is. Elke camera geeft overdag prima beeld. Maar als het donker is vallen vele door de mand en heb je er weing aan.

En hou er rekening mee dat na het aanbellen er altijd vertraging is tussen moment van aanbellen en de melding via een app van een paar seconden.

[wimmme]

Ik heb zelf nog geen video deurbel. Wel een security-camera én deurbel die gelinkt is met Domoticz via 433 zender. Ik krijg een notification via autoremote op m'n telefoon met snapshot als er iemand aanbelt, en als ik daar op klik opent die de videostream. Kan wel niet praten zo.
Ben er wel één aan het overwegen, ik denk daarbij aan de Foscam VD1

Hier ook wat meer uitleg

[Antonio di]

wimmme schreef op vrijdag 10 februari 2023 @ 12:25:
Ik heb zelf nog geen video deurbel. Wel een security-camera én deurbel die gelinkt is met Domoticz via 433 zender. Ik krijg een notification via autoremote op m'n telefoon met snapshot als er iemand aanbelt, en als ik daar op klik opent die de videostream. Kan wel niet praten zo.
Ben er wel één aan het overwegen, ik denk daarbij aan de Foscam VD1

Hier ook wat meer uitleg

Er is ook op Tweakers een Forum over "slimme deurbellen zonder abonnement".
Het is even door lezen , zie :
Slimme deurbel/camera met lokale opslag EN zonder abonnement

[Copitano]

En als je dan denkt dat je klaar bent, dan komt het na een paar dagen gewoon weer terug.

Ben wel wat verder op onderzoek gegaan. Wat ik al eens eerder gezien had in grafana is dat op enig moment in de nacht (na de piek van de backup) het geheugen gebruik onverklaarbaar ineens omhoog schiet. Meestal rond een uur of 5 s'nachts. Verder aanvankelijk geen aandacht aan geschonken omdat alles gewoon netjes door liep.

Maar nu is die piek teruggeschoven naar ca. 01:30 dicht bij de backup. Als ik dan in de CLI 'top' intik zie ik dat influxdb een enorm geheugengebruik heeft tot wel 70% en dan héél langzaam terugloopt.

Afgelopen nacht heb ik om 03:00 een extra backup geforceerd met een crontab -e job. En bingo, influx ligt er weer uit (ergens tussen 03:00 en 07:00).

Wel bijzonder:
Na het verwijderen van de map /var/lib/influxdb/wal en opnieuw opstarten van influxdb blijkt dat influx dan kennelijk de laatste gemaakte backup weet te vinden. Want de data tot 03:00 wordt netjes hersteld.

Het enige zinnige wat ik hierover met Google kan vinden is het weggooien van de map /var/lib/influxdb/wal met toch elke keer wel een paar uur dataverlies omdat het tot nu toe steeds midden in de nacht gebeurt Bovendien blijkt het een tijdelijke oplossing omdat het nu inmiddels drie nachten op rij raak is . Heel irritant voor het monitoren van de WP in de nacht.

Iemand hier ook ervaring mee en/of suggesties wat hier aan de hand kan zijn en hoe op te structureel op te lossen?

[rvk]

Copitano schreef op vrijdag 10 februari 2023 @ 16:38:
Wel bijzonder:
Na het verwijderen van de map /var/lib/influxdb/wal en opnieuw opstarten van influxdb blijkt dat influx dan kennelijk de laatste gemaakte backup weet te vinden. Want de data tot 03:00 wordt netjes hersteld.

Dat is niet een backup maar de gewone data.

De wal directory bevat de "write ahead log". Dat is data die nog niet naar de data directory geschreven is (en wordt ook in het geheugen gehouden). Als je die dus weggooit dan hou je nog wel je data uit de data direcotry. https://community.influxd...with-files-tsm-db-wal/787

Hoeveel data heb je overigens? Heb je retentie policies?

Ik wilde vorig weekend een raspbery pi 2 installeren als P1 en solar monitor.
Na een 2 dagen moest ik een restart doen en influxdb raakte daar helemaal van over de flos. Bij het opstarten moet alle data ingelezen worden, dat duurde bij dat ding zo lang dat ik elk keer "InfluxDB API unavailable after xx attempts" kreeg. Toen heb ik er maar voor gekozen om te loggen naar een RPI4.

When influxdb starts up it has to read in all its data files, so if you have a lot of historical data points this can take a long period of time. This startup process can also use a lot of memory relative to the steady state running memory usage.

Copitano schreef op maandag 30 januari 2023 @ 16:55:
[...]
[Afbeelding]
Zo te zien mis ik een API?

Dat ligt dus waarschijnlijk aan het feit dat InfluxDB nog aan het starten is en het service deel het process opnieuw start als InfluxDB niet binnen 5 of 10 seconden reageert (en aangezien dat starten langer duurt wordt InfluxDB elke keer eruit geknikkerd en weer gestart).

[Opperhoof]

Ik heb een P1 meter aangesloten op domoticz via LAN. Werkt prima. Alleen als ik > 6000 watt op een fase gebruik krijg ik deze error:

2023-02-10 18:02:03.735 Error: P1 smart meter orangepi: Power usage to high/low! Usage: 6774 Watt. Max Usage configured: 6000. (NodeID: 0x0000, ChildID: 0x0001, SID: Usage L1)


Bij domoticz --> setup --> settings --> meters/counters --> "max power" heb ik 32.000 watt ingevuld.

Toch blijft de error komen. De meting >6000 wordt ook niet geregistreerd. Ik heb een paar triggers ingesteld op vermogens > 5750. Die worden nu vaak niet getriggerd, omdat ik bijv. 5000 watt verbruik, de waterkoker aanzet en op 7000 watt zit. Deze meting wordt niet geregistreerd en de triggers dus niet geactiveerd.

Hoe los ik dit op?

[rvk]

Opperhoof schreef op vrijdag 10 februari 2023 @ 18:07:
Bij domoticz --> setup --> settings --> meters/counters --> "max power" heb ik 32.000 watt ingevuld.

Misschien nitpicking maar heb je 32.000 ingegeven of 32000 ??

https://www.domoticz.com/forum/viewtopic.php?t=34650

[Opperhoof]

rvk schreef op vrijdag 10 februari 2023 @ 19:04:
[...]

Misschien nitpicking maar heb je 32.000 ingegeven of 32000 ??

https://www.domoticz.com/forum/viewtopic.php?t=34650

32000

[Copitano]

rvk schreef op vrijdag 10 februari 2023 @ 18:05:
[...]

Dat is niet een backup maar de gewone data.

De wal directory bevat de "write ahead log". Dat is data die nog niet naar de data directory geschreven is (en wordt ook in het geheugen gehouden). Als je die dus weggooit dan hou je nog wel je data uit de data direcotry. https://community.influxd...with-files-tsm-db-wal/787

Ja die had ik ook gevonden. Alleen het Engels is net iets te technisch voor mij om het nog te begrijpen. Inmiddels is de boel er weer uit geknald. Na hetzelfde trucje met verwijderen van de 'wal' data nu terug naar de laatste backup van vanmorgen 11:00 uur. De backup daarvoor is gedraait om 03:00 uur afgelopen nacht. Dat is dan wel weer bijzonder dat het in beide gevallen (en ook hiervoor) precies overeenkomt met de data die dan nog zichtbaar is. Er lijkt dus toch een soort koppeling met de laatste backup, al begrijp ik nog niet hoe dan. Een half uur geleden heb ik nog gekeken en toen was er nog geen enkele aanwijzing dat de boel er weer uit zou vliegen. Nu dus toch weer bijna een hele dag data pleite

Hoeveel data heb je overigens? Heb je retentie policies?

Geen idee. Een jaar of 5 heel veel sensoren. 5 verschillende dashboards. Hoe kom ik daar achter?
Geen retentie policies. Heb dat ooit wel doorgelezen, maar begrijp er niet zoveel van. De charme van Influxdb was "installeren en gaan met die banaan". Tot nu dan.

Ik wilde vorig weekend een raspbery pi 2 installeren als P1 en solar monitor.
Na een 2 dagen moest ik een restart doen en influxdb raakte daar helemaal van over de flos. Bij het opstarten moet alle data ingelezen worden, dat duurde bij dat ding zo lang dat ik elk keer "InfluxDB API unavailable after xx attempts" kreeg. Toen heb ik er maar voor gekozen om te loggen naar een RPI4.

Dat ligt dus waarschijnlijk aan het feit dat InfluxDB nog aan het starten is en het service deel het process opnieuw start als InfluxDB niet binnen 5 of 10 seconden reageert (en aangezien dat starten langer duurt wordt InfluxDB elke keer eruit geknikkerd en weer gestart).

Dat duurt hier dan uren...............
Dat werkt dus niet.
Moet ik nu dus de handoek in de ring gooien en 5 jaar data als verloren beschouwen ?

[rvk]

Copitano schreef op zaterdag 11 februari 2023 @ 00:35:
[...]
Ja die had ik ook gevonden. Alleen het Engels is net iets te technisch voor mij om het nog te begrijpen. Inmiddels is de boel er weer uit geknald.

Ik weet ook nog niet precies wanneer de wal (een soort buffer dus) nu echt naar data geschreven wordt. Het kan natuurlijk zijn dat daar behoorlijk wat geheugen voor nodig is en dat dat nu net het probleem punt is.

Dan zouden we eens moeten kijken wanneer dat gebeurd (dat de wal gegevens naar data gaat).

Misschien is dit wat beter te optimaliseren.
(Of bv de wal direct naar data laten gaan/uitschakelen als dat mogelijk is en hopen dat dat dan minder geheugen verbruikt)

Als je 5 jaar data met elke 15 seconden readings hebt, dan is dat wel een behoorlijke database. Retentie zou ervoor zorgen dat oude data automatisch verwijderd wordt (dat moet je dan wel combineren met een continuous query die die data consolideert naar bv readings per kwartier).

Copitano schreef op zaterdag 11 februari 2023 @ 00:35:
Moet ik nu dus de handoek in de ring gooien en 5 jaar data als verloren beschouwen ?

Uiteraard valt alle data wel te exporteren naar een ander soort database als dat nodig zou zijn. Maar ik was wel gecharmeerd van het "time series" idee van influxdb (hoewel ik nog maar moeilijk kan wennen aan flux, wat je wel nodig hebt als je per maand wil groeperen).

Ik zal morgen nog eens zoeken naar geheugen en influxdb. Deze had ik al gevonden https://docs.influxdata.com/platform/troubleshoot/oom-loops/

[Copitano]

rvk schreef op zaterdag 11 februari 2023 @ 01:58:
[...]

Ik weet ook nog niet precies wanneer de wal (een soort buffer dus) nu echt naar data geschreven wordt. Het kan natuurlijk zijn dat daar behoorlijk wat geheugen voor nodig is en dat dat nu net het probleem punt is.

Om die reden heb ik in oktober vorig jaar de swapsize van de Pi vergroot van 100 (default) naar 1064. Dat leek aanvankelijk te helpen. In ieder geval op de pieken bij het schrijven van de backup naar een USB-stick.

Dan zouden we eens moeten kijken wanneer dat gebeurd (dat de wal gegevens naar data gaat).

Gezien de gaten die nu ontstaan in de data en de toename van geheugengebruik vooraf aan de crash denk ik dat de 'wal' niet aan schrijven toe komt.

Misschien is dit wat beter te optimaliseren.

(Of bv de wal direct naar data laten gaan/uitschakelen als dat mogelijk is en hopen dat dat dan minder geheugen verbruikt)

Zou mooi zijn als je dat kan beïnvloeden. Alleen mijn kennis daarover schiet (nog) tekort.

Als je 5 jaar data met elke 15 seconden readings hebt, dan is dat wel een behoorlijke database. Retentie zou ervoor zorgen dat oude data automatisch verwijderd wordt (dat moet je dan wel combineren met een continuous query die die data consolideert naar bv readings per kwartier).

Op deze Pi zijn de readings elke minuut. Het aantal sensors is in de loop van de tijd wel flink gegroeit tot nu >200

[...]

Uiteraard valt alle data wel te exporteren naar een ander soort database als dat nodig zou zijn. Maar ik was wel gecharmeerd van het "time series" idee van influxdb (hoewel ik nog maar moeilijk kan wennen aan flux, wat je wel nodig hebt als je per maand wil groeperen).

Ik zal morgen nog eens zoeken naar geheugen en influxdb. Deze had ik al gevonden https://docs.influxdata.com/platform/troubleshoot/oom-loops/

Dat zal ik ook eens doorlezen. Alles (buster, domoticz, influxdb, grafana, mosqitto, monit etc. ) draait hier op een eMMC module van 64GB. Daarvan is nog 40GB beschikbaar. Ruimte genoeg dus

[rvk]

Opperhoof schreef op vrijdag 10 februari 2023 @ 21:52:
[...]
32000

Dat zou ook te makkelijk geweest zijn

Ik lees in ieder geval dat het een redelijk hardnekkige instelling is.
Een iemand heeft een sudo halt - > Power Off - > Power On moeten doen om de instelling door te voeren.

[rvk]

Copitano schreef op zaterdag 11 februari 2023 @ 10:19:
[...]
Dat zal ik ook eens doorlezen. Alles (buster, domoticz, influxdb, grafana, mosqitto, monit etc. ) draait hier op een eMMC module van 64GB. Daarvan is nog 40GB beschikbaar. Ruimte genoeg dus

Het gaat om het feit dat de wal (buffer) gegevens ook in het geheugen gehouden worden. En je interne geheugen zal niet zo groot zijn (op een PI 1, 2, 4 of 8GB).

Je kunt met dit commando zien hoe groot je data is (hoewel dat nog niets zegt over het benodigde geheugen)
sudo du -hd1 /var/lib/influxdb

Hier ook wat uitleg hoe het werkt.
https://docs.influxdata.c...internals/storage-engine/

Nu was ik in de source wel WALEnabled tegen gekomen dus wellicht is er een mogelijkheid om de wal uit te schakelen (hoewel nog niet gevonden). Maar daarna moet je dan wel de cache tijd voor de memory storage korter zetten want anders ben je bij een crash nog steeds veel gegevens kwijt.

Dus.
Data wordt eerst naar geheugen gezet en een kopie daarvan in de wal.
Op een bepaald moment worden die gegevens overgezet naar data (wat cpu tijd kost)
Bij een crash is het geheugen leeg maar daarom wordt bij een restart van influxd de wal gelezen en samengevoegd met data. En dat duurt erg lang.

En als dat niet lukt haal jij de wal weg en blijf je met gegevens van het laatste schrijven van wal->data.

Ik zal eens kijken wat mijn geheugen op de PI doet.

[klump4u]

@Copitano , stel jezelf eens de vraag wat je met al die data moet?
Wat is er nu echt 'belangrijk' om te bewaren.

[Copitano]

rvk schreef op zaterdag 11 februari 2023 @ 10:55:
[...]

Het gaat om het feit dat de wal (buffer) gegevens ook in het geheugen gehouden worden. En je interne geheugen zal niet zo groot zijn (op een PI 1, 2, 4 of 8GB).

In mijn geval Pi3B+ met volgens mij 1GB geheugen.

Je kunt met dit commando zien hoe groot je data is (hoewel dat nog niets zegt over het benodigde geheugen)
sudo du -hd1 /var/lib/influxdb

code:

pi@raspberrypi:~ $ sudo du -hd1 /var/lib/influxdb
34M /var/lib/influxdb/wal
1,2G    /var/lib/influxdb/data
12K /var/lib/influxdb/meta
1,2G    /var/lib/influxdb

Hier ook wat uitleg hoe het werkt.
https://docs.influxdata.c...internals/storage-engine/

Nu was ik in de source wel WALEnabled tegen gekomen dus wellicht is er een mogelijkheid om de wal uit te schakelen (hoewel nog niet gevonden). Maar daarna moet je dan wel de cache tijd voor de memory storage korter zetten want anders ben je bij een crash nog steeds veel gegevens kwijt.

Dat zou een mooie oplossing zijn.

Dus.
Data wordt eerst naar geheugen gezet en een kopie daarvan in de wal.
Op een bepaald moment worden die gegevens overgezet naar data (wat cpu tijd kost)
Bij een crash is het geheugen leeg maar daarom wordt bij een restart van influxd de wal gelezen en samengevoegd met data. En dat duurt erg lang.

Heldere uitleg. Alleen dat opnieuw starten lukt dan niet. Na verloop van enige tijd krijg ik dan een foutmelding

En als dat niet lukt haal jij de wal weg en blijf je met gegevens van het laatste schrijven van wal->data.

Ik had de backup bewust uitgezet voor de afgelopen nacht. Influx is er toch weer uitgegaan. In ieder geval na 03:00, want de data werd hersteld tot 03:00 vannacht en dat kan dus niet van de backup komen zoals je eerder al schreef. Conclusie er is in ieder geval om 03:00 een keer geschreven naar data.

Ik zal eens kijken wat mijn geheugen op de PI doet.

[rvk]

klump4u schreef op zaterdag 11 februari 2023 @ 11:23:
@Copitano , stel jezelf eens de vraag wat je met al die data moet?
Wat is er nu echt 'belangrijk' om te bewaren.

Zeker de history van tellers zonder grafiek zijn meestal niet echt nodig.
Daar zijn de retentie policies voor.

En als je wel wat voor grafieken wilt bewaren (ouder dan bv 3 dagen) dan kun je met een continuous query de data overzetten naar een andere measurement per uur. Dat us voor een grafiek over meerdere dagen meestal wel voldoende.

Copitano schreef op zaterdag 11 februari 2023 @ 11:28:
[...]
Heldere uitleg. Alleen dat opnieuw starten lukt dan niet. Na verloop van enige tijd krijg ik dan een foutmelding

De foutmelding komt omdat influxd (de daemon) de wal nog niet ingelezen en verwerkt heeft bij het opstarten. Hoe lang heb je dat de tijd gegeven?

Copitano schreef op zaterdag 11 februari 2023 @ 11:28:
Conclusie er is in ieder geval om 03:00 een keer geschreven naar data.

Inderdaad. En dat zou je dus vaker willen forceren.
Ergens moet je dus aangeven dat je maar weinig geheugen hebt en influx wat eerder moet gaan verwerken.

Overigens is 1GB inderdaad niet veel.
Ik draai hier op RPI4 4GB. (En heb er ook nog een van 8GB staan)
(Helaas zijn ze nog niet te verkrijgen op dit moment)

[rvk]

Ik heb net ook even sudo service influxdb restart gedaan.
Ik kreeg in de log ook tot 30 keer toe de unavailable.
Duurde redelijk lang (2 minuten). Maar met minder geheugen misschien veel langer.

Met tail -n1000 /var/log/daemon.log kun je zien wanneer influx weer beschikbaar is.
Je ziet allerlei regels met "open shard" e.d.
Dat is het process van verwerking van die wal.
Uiteindelijk zie je "InfluxDB started" en dan is ie klaar.
(Kun je ook zien met sudo service influxdb status)

[Copitano]

rvk schreef op zaterdag 11 februari 2023 @ 11:40:
[...]

Zeker de history van tellers zonder grafiek zijn meestal niet echt nodig.
Daar zijn de retentie policies voor.

Bedoel je daar deze mee?

De meeste daarvan zitten dan weer wel ook in grafieken

En als je wel wat voor grafieken wilt bewaren (ouder dan bv 3 dagen) dan kun je met een continuous query de data overzetten naar een andere measurement per uur. Dat us voor een grafiek over meerdere dagen meestal wel voldoende.

Ehhhh, continuous query??? overzetten??? doe je dat dan in grafana waar je data ophaalt? of aan de voorkant waar je de data vanuit domoticz pushed naar influxdb?
Sorry, ik ben daar niet zo in thuis

[...]

De foutmelding komt omdat influxd (de daemon) de wal nog niet ingelezen en verwerkt heeft bij het opstarten. Hoe lang heb je dat de tijd gegeven?


[...]

Van het opstart commando in de CLI tot de foutmelding verschijnt. Bij de volgende crash zal ik de tijd eens opnemen. Of bedoel je gewoon eens een half uurtje niets doen na de foutmelding en kijken wat er gebeurd?

Inderdaad. En dat zou je dus vaker willen forceren.
Ergens moet je dus aangeven dat je maar weinig geheugen hebt en influx wat eerder moet gaan verwerken.

Dat zou voor mij op dit moment denk ik de voorkeur hebben. Maar inderdaad lastig te vinden hoe je dat dan moet instelllen.

Overigens is 1GB inderdaad niet veel.
Ik draai hier op RPI4 4GB. (En heb er ook nog een van 8GB staan)
(Helaas zijn ze nog niet te verkrijgen op dit moment)

Als ze er al zijn kosten ze op dit moment > € 200. Toen ik beide Pi's kocht was dat <€ 50 en dan ook nog incl. voeding, SD kaartje enzo. Jammer hoor. Het is zo'n leuk speelgoed

[Copitano]

rvk schreef op zaterdag 11 februari 2023 @ 11:48:
Ik heb net ook even sudo service influxdb restart gedaan.
Ik kreeg in de log ook tot 30 keer toe de unavailable.
Duurde redelijk lang (2 minuten). Maar met minder geheugen misschien veel langer.

Met tail -n1000 /var/log/daemon.log kun je zien wanneer influx weer beschikbaar is.
Je ziet allerlei regels met "open shard" e.d.
Dat is het process van verwerking van die wal.
Uiteindelijk zie je "InfluxDB started" en dan is ie klaar.
(Kun je ook zien met sudo service influxdb status)

Ik ga dat bij de volgende crash eens proberen. Die laatste 'sudo service influxdb status heb ik inderdaad al eerder gebruikt . Die eerste nog niet. Was inderdaad al wel opzoek geweest naar log's

[rvk]

Copitano schreef op zaterdag 11 februari 2023 @ 12:03:
[...]
De meeste daarvan zitten dan weer wel ook in grafieken

De vraag is of jij de tijdsduur wel eens op meer dan 2 weken zet en dan de grafiek bekijkt?
Bekijk jij dus wel eens data van 2 weken geleden (en is het dan van belang dat je dat op de minuut nauwkeurig ziet)?

[Copitano]

rvk schreef op zaterdag 11 februari 2023 @ 12:11:
[...]

De vraag is of jij de tijdsduur wel eens op meer dan 2 weken zet en dan de grafiek bekijkt?
Bekijk jij dus wel eens data van 2 weken geleden (en is het dan van belang dat je dat op de minuut nauwkeurig ziet)?

Dat komt zeker wel voor om gegevens met elkaar te vergelijken. maar is lang niet voor alle gegevens noodzakelijk. Ik meet bijvoorbeeld de aanvoer en retour van alle convectoren in huis. Dat heb ik gebruikt om de boel waterzijdig zo goed mogelijk in te regelen, maar is nu niet meer echt relevant. Wat ik er nog mee doe is zo nu en dan checken of de Tr en delta T onderling nog een beetje met elkaar spoort.

[rvk]

Copitano schreef op zaterdag 11 februari 2023 @ 12:07:
[...]
Ik ga dat bij de volgende crash eens proberen. Die laatste 'sudo service influxdb status heb ik inderdaad al eerder gebruikt . Die eerste nog niet. Was inderdaad al wel opzoek geweest naar log's

Ik ben eigenlijk meer geïnteresseerd in de reden waarom influxdb schijnt te crashen.

Dat die bij het opstarten die wal naar data moet overpompen duurt dan gewoon even, maar hij zou sowieso niet mogen crashen.

Dan zou de inhoud van /var/log/daemon.log rond en voor het moment van crashen interessant kunnen zijn.
(dus dan niet de laatste 1000 regels maar de regels rond de crash)

Hier zie ik een config met wat gegevens over sync en memory van influx.
https://community.influxd...ing-out-of-memory/24463/3
Ik zeg niet dat die instellingen gelijk goed zijn maar wel het onderzoeken waard.
Vooral de wal-fsync-delay en cache-max-memory-size.
(en dat topic geeft ook een mogelijke reden van een crash, "during compaction". Compaction is een redelijk complex process dat over alle data gaat, wal en data en nog meer)

Dit is ook een interessant artikel:
https://thenewstack.io/ho...th-the-time-series-index/
Daarin staat dat je in plaats van inmem (in geheugen) ook kunt werken met tsi1 (TSI files on disk).
Dan zou je in één keer van een groot geheugen probleem af zijn (als dat de reden was).
(Staat ook hier uitgelegd https://docs.influxdata.c...administration/upgrading/)

[Copitano]

rvk schreef op zaterdag 11 februari 2023 @ 13:45:
[...]

Ik ben eigenlijk meer geïnteresseerd in de reden waarom influxdb schijnt te crashen.

Dat die bij het opstarten die wal naar data moet overpompen duurt dan gewoon even, maar hij zou sowieso niet mogen crashen.

Dan zou de inhoud van /var/log/daemon.log rond en voor het moment van crashen interessant kunnen zijn.
(dus dan niet de laatste 1000 regels maar de regels rond de crash)

Hier zie ik een config met wat gegevens over sync en memory van influx.
https://community.influxd...ing-out-of-memory/24463/3
Ik zeg niet dat die instellingen gelijk goed zijn maar wel het onderzoeken waard.
Vooral de wal-fsync-delay en cache-max-memory-size.
(en dat topic geeft ook een mogelijke reden van een crash, "during compaction". Compaction is een redelijk complex process dat over alle data gaat, wal en data en nog meer)

Dit is ook een interessant artikel:
https://thenewstack.io/ho...th-the-time-series-index/
Daarin staat dat je in plaats van inmem (in geheugen) ook kunt werken met tsi1 (TSI files on disk).
Dan zou je in één keer van een groot geheugen probleem af zijn (als dat de reden was).
(Staat ook hier uitgelegd https://docs.influxdata.c...administration/upgrading/)

Nou, voorlopig even wat huiswerk te doen dus. Voor mij is ook de reden van de crash en vooral de oplossing belangrijk. Voor dit moment draait influx gewoon, maar ik durf een wedje aan dat het er vandaag nog weer een keer uit gaat.

[Copitano]

@rvk Is er een manier om heel snel door deamon.log omlaag te scrollen (in nano). Er zitten 1.668.862 regels in (per 1/100 seconden). Als ik ^W gebruik om te zoeken sluit het venster in plaats van de zoekbalk te openen
Gevonden: eerst ctrlW en dan CtrlT en dan naar regel 1000000

[Voor 12% gewijzigd door Copitano op 11-02-2023 14:54]

[rvk]

Copitano schreef op zaterdag 11 februari 2023 @ 14:47:
@rvk Is er een manier om heel snel door deamon.log omlaag te scrollen (in nano). Er zitten 1.668.862 regels in (per 1/100 seconden). Als ik ^W gebruik om te zoeken sluit het venster in plaats van de zoekbalk te openen

Nano zal ook behoorlijk over de flos gaan met 1.668.862 regels
Ik gebruik meestal tail e.v. in combinatie met less

code:

# laatste 1000 regels via less
tail /var/log/daemon.log | less

code:

# laatste 1000 regels via less maar dan de regels niet gewrapped
tail /var/log/daemon.log | less -S

Je kunt er dan met page up en down doorscrollen.

PS. De volgende keer dat je influxdb plat gaat kun je proberen de daemon (influxd) te starten op console ipv via een service. Gewoon influxd uitvoeren in een console. Je krijgt dan allerlei open file en open shard regels. Het is dan even de vraag hoelang het duurt voordat je de "Listening for signals" krijgt. Daarna kun je op een andere console met "netstat -tulpn | grep 8086" zien dat influxd gestart is. Met Ctrl+C kun je influxd weer stoppen. Als je daarna de service start, zul je minimaal die periode moeten wachten totdat de service dus weer echt loopt. Je wilt zo weinig mogelijk de wal weggooien want dan raak je gegevens kwijt. Ik heb nog geen manier gevonden om die wal handmatig te pushen naar data na een crash.

(Bijna tijd voor een eigen topic... deze posts zijn volgens mij redelijk off-topic voor dit forum-gedeelte want influxdb/grafana hebben weinig met domoticz te maken, dacht ik )

[Copitano]

rvk schreef op zaterdag 11 februari 2023 @ 15:32:
[...]

(Bijna tijd voor een eigen topic... deze posts zijn volgens mij redelijk off-topic voor dit forum-gedeelte want influxdb/grafana hebben weinig met domoticz te maken, dacht ik )

Ben nog even aan het graven in deamon.log. Zal straks inderdaad maar even een eigen topic starten

[Copitano]

rvk schreef op zaterdag 11 februari 2023 @ 15:32:
[...]

Nano zal ook behoorlijk over de flos gaan met 1.668.862 regels
Ik gebruik meestal tail e.v. in combinatie met less

code:

# laatste 1000 regels via less
tail /var/log/daemon.log | less

code:

# laatste 1000 regels via less maar dan de regels niet gewrapped
tail /var/log/daemon.log | less -S

Je kunt er dan met page up en down doorscrollen.

PS. De volgende keer dat je influxdb plat gaat kun je proberen de daemon (influxd) te starten op console ipv via een service. Gewoon influxd uitvoeren in een console. Je krijgt dan allerlei open file en open shard regels. Het is dan even de vraag hoelang het duurt voordat je de "Listening for signals" krijgt. Daarna kun je op een andere console met "netstat -tulpn | grep 8086" zien dat influxd gestart is. Met Ctrl+C kun je influxd weer stoppen. Als je daarna de service start, zul je minimaal die periode moeten wachten totdat de service dus weer echt loopt. Je wilt zo weinig mogelijk de wal weggooien want dan raak je gegevens kwijt. Ik heb nog geen manier gevonden om die wal handmatig te pushen naar data na een crash.

(Bijna tijd voor een eigen topic... deze posts zijn volgens mij redelijk off-topic voor dit forum-gedeelte want influxdb/grafana hebben weinig met domoticz te maken, dacht ik )

Discussier verhuisd naar eigen topic Daar staat ook een stuk uit de deamon.log
Net even beiden met tail geprobeerd. Maar krijg maar 10 regels. Of komt daar alleen iets als het fout gaat?

[Rolandtwilt]

MikeOO schreef op donderdag 9 februari 2023 @ 07:32:
[...]

Bedankt dat je de tijd heb genomen om me dit uit te leggen!
Ik zie nog een voordeel van een videodeurbel; je kan communiceren met de persoon die aanbelt.
Ik ga nog eens kijken op het forum voor videodeurbellen en dan opzoek naar 1 die te integreren is in Domoticz. Tips zijn welkom en nogmaals dank!


Op zich niet. Ze kunnen allebei hetzelfde. Een videodeurbel is alleen compact en hang je op naast je voordeur.
Paar draadjes aansluiten of 1 op een batterij en klaar.

Een losse camera hang je meestal wat hoger op bij je deur in zodat je meer van boven beeld krijgt en bij sommige camera's is hierdoor de kijkhoek een stuk groter. Aansluiten is wat meer werk omdat je een netwerkkabel en/of voeding naar de camera moet maken. PoE camera's zijn dan weer handiger omdat de voeding dan via de netwerkkabel verloopt en je dus maar 1 kabel hoeft aan te leggen. Maar je heb dan wel een PoE camera en PoE kastje of switch nodig. Klinkt ingewikkeld maar is het niet

Nadeel is wel dat je hierdoor niet altijd de persoon duidelijk kunt zien qua gezicht omdat je van bovenaf filmt.
Daarbij heb je dan een losse deurbelknop nodig die werkt als een trigger voor de camera.

De meeste camera's kunnen prima een snapshot maken en zodra iemand aanbelt start je in Domoticz en script die een snapshot maakt en deze verstuurd naar je mobiel via bv Telegram.

Zelf heb ik bv 1 camera boven de voordeur en 1 in de nok van het huis. Als er aangebeld wordt krijg ik dus 2 foto's via Telegram. Zo kan ik zien wie er bij de voordeur staat maar krijg ik ook een breed overzicht van de voorkant van het huis.

Voordeel van een losse camera is weer dat het beeld vele malen beter/scherper kan zijn. Je bepaald tenslotte zelf welke kwaliteit camera je koopt. Welke dat moet zijn, gewoon reviews lezen en beelden bekijken. Er is voor elke camera op youtube wel filmpjes met de kwaliteit van het beeld.

En hoe dit moet ik Domoticz is al vaak besproken dus eenvoudig terug te vinden.

Belangrijk is welke type of soort camera je ook neemt. Check vooraf op internet hoe het beeld is als het donker is. Elke camera geeft overdag prima beeld. Maar als het donker is vallen vele door de mand en heb je er weing aan.

En hou er rekening mee dat na het aanbellen er altijd vertraging is tussen moment van aanbellen en de melding via een app van een paar seconden.

[henkNL]

Sinds 2016 tevreden Domoticz gebruiker.
Ik draai momenteel 2020.2, die is dus al zo'n 3 jaar oud. (uptime 343 dagen, en hij wordt niet gespaard maar flink gebruikt)

Tijd om weer eens te updaten.

Inmiddels heb ik een Pi 4 met docker en portainer draaien.
Hierop draait o.a. de laatste Domoticz stable, MQTT en Zigbee2MQTT.

Dat werkt allemaal prima, maar ik wil nog mijn eigen lua (en bash en dzVents) scripts in Domoticz via Docker laten werken.

Ik heb de containermap '/opt/domoticz/userdata' doorgezet naar '/home/pi/docker/domoticz-2022.2/config'

Nu is mij niet duidelijk waar de scripts nou in moeten komen.

Of moet ik nog andere koppelingen maken?

[M.v.Veelen]

Hi,

ik heb al een poosje een Sonoff Zigbee dongle liggen om m'n 2 Xiaomi gateways te vervangen maar heb nog niet echt een handige stap-voor-stap tutorial gevonden waarmee het foutloos uitgevoerd kan worden. Wat moet er worden geïnstalleerd, waar moet ik rekening mee houden, enz.?

Heeft iemand dit onlangs gedaan of een linkje naar een pagina waarop e.e.a. beschreven staat? Ik heb de laatste Beta draaien op m'n RPi 3B+ en zou vandaag weleens willen kijken of het me gaat lukken.

[Voor 8% gewijzigd door M.v.Veelen op 12-02-2023 10:17]

[wimmme]

henkNL schreef op zaterdag 11 februari 2023 @ 21:54:
Sinds 2016 tevreden Domoticz gebruiker.
Ik draai momenteel 2020.2, die is dus al zo'n 3 jaar oud. (uptime 343 dagen, en hij wordt niet gespaard maar flink gebruikt)

Tijd om weer eens te updaten.

Inmiddels heb ik een Pi 4 met docker en portainer draaien.
Hierop draait o.a. de laatste Domoticz stable, MQTT en Zigbee2MQTT.

Dat werkt allemaal prima, maar ik wil nog mijn eigen lua (en bash en dzVents) scripts in Domoticz via Docker laten werken.

Ik heb de containermap '/opt/domoticz/userdata' doorgezet naar '/home/pi/docker/domoticz-2022.2/config'

Nu is mij niet duidelijk waar de scripts nou in moeten komen.

Of moet ik nog andere koppelingen maken?

Onder die config folder een submap scripts, en daaronder dan lua, dzvents, python, ...

[henkNL]

wimmme schreef op zondag 12 februari 2023 @ 20:27:
[...]


Onder die config folder een submap scripts, en daaronder dan lua, dzvents, python, ...
[Afbeelding]

Tnx!
Het werkt, zo simpel kan t zijn

[MikeOO]

M.v.Veelen schreef op zondag 12 februari 2023 @ 10:08:
Hi,

ik heb al een poosje een Sonoff Zigbee dongle liggen om m'n 2 Xiaomi gateways te vervangen maar heb nog niet echt een handige stap-voor-stap tutorial gevonden waarmee het foutloos uitgevoerd kan worden. Wat moet er worden geïnstalleerd, waar moet ik rekening mee houden, enz.?

Heeft iemand dit onlangs gedaan of een linkje naar een pagina waarop e.e.a. beschreven staat? Ik heb de laatste Beta draaien op m'n RPi 3B+ en zou vandaag weleens willen kijken of het me gaat lukken.

Hou er rekening mee dat de Zigbee-E versie met de standaard firmware niet lekker werkt met de Xiaomi ronde schakelaars. Zelf net overgestapt van Domoticz naar Home Assistant maar firmware is hetzelfde dus probleem ook lijkt mij. Nu is er vorige week een nieuwe firmware uitgekomen dus mogelijk is het probleem opgelost.

Aanmelden gaat prima maar na een puur uit verliezen ze de verbinding en werken ze niet meer. Overige Xiaomi zoals deurcontacten / rookmelder / bewegingssensoren werken er wel goed ermee.

Draai de stick nu met alternatieve firmware ncp-uart-sw_655_115200.gbl & nvm3_initfile.gbl en die werkt perfect.

note 1: Dit is alleen als je de E versie hebt. Deze niet gaan flashen op de P versie!! De P versie werkt prima met de originele firmware maar signaal komt minder ver dan de E versie.
note 2: versie ncp-uart-sw_679_115200.gbl werkt ook niet goed.
note 3: Flashen van de E versie: YouTube: Sonoff ZBDongle E upgrade firmware / Обновление прошивки

Maar zou beginnen met de laatste originele firmware en deze even een dag testen met als je hebt een round switch. Als hij blijft werken dan is het probleem nu opgelost.
Nadeel is namelijk dat je na een flash alle Zigbee hardware opnieuw in parining mode moet zetten om ze opnieuw te koppelen. En als je er veel heb (gebruiker er zelf nu 23) is dat een hoop werk elke keer.
Dus vooraf met een paar testen scheelt dan een hoop frustratie

Helaas geen ervaring met het installeren binnen Domoticz. Voor mij een van de reden waarom ik ben overgestapt naar HA omdat er veel meer info te vinden is en het allemaal makkelijk te installeren is binnen HA.

[M.v.Veelen]

Oei, dankjewel. Ik zal op een vrije middag dan eens gaan testen met een rond schakelaar die ik nog heb liggen. Gebruik ze ook als schakelaars naast m'n bed en zelfs als deurbelknop. Dan ook maar kijken of ik kan uitvogelen welke versie ik überhaupt heb.

[MikeOO]

M.v.Veelen schreef op maandag 13 februari 2023 @ 18:35:
Oei, dankjewel. Ik zal op een vrije middag dan eens gaan testen met een rond schakelaar die ik nog heb liggen. Gebruik ze ook als schakelaars naast m'n bed en zelfs als deurbelknop. Dan ook maar kijken of ik kan uitvogelen welke versie ik überhaupt heb.

Staat op het doosje aan de achterkant vermeld en anders kun je het aan de lengte achterhalen

P versie: 87mm lang
E Versie: 75mm lang

[M.v.Veelen]

Het staat zelfs op de Sonoff dongle zelf, ik heb de E-versie.

[JaapB]

Vanmorgen dan maar de update uitgevoerd (2022.1 naar 2023.1) na een backup te hebben gedraaid uiteraard. Geen problemen met de nieuwe installatie of zelfs maar met de cache van de browser.
Alleen nu kom ik er door een timer achter dat de rolluikmotoren nu andersom werken. Daar waar ze die open zouden sturen gaan ze nu dicht.
Best bizar aangezien dit al 6 jaar goed heeft gewerkt.

[Voor 2% gewijzigd door JaapB op 16-02-2023 13:34. Reden: versienummers invoegen]

[Vollervo]

JaapB schreef op donderdag 16 februari 2023 @ 12:10:
Vanmorgen dan maar de update uitgevoerd (2022.1 naar 2023.1)
de rolluikmotoren nu andersom werken. Daar waar ze die open zouden sturen gaan ze nu dicht.
Best bizar aangezien dit al 6 jaar goed heeft gewerkt.

Zijn die schakelaars van het type 'Blinds'? Volgens mij is dat in de tusenliggende release aangepast. Maar je kan ze omkeren bij de eigenschappen van de schakelaar als het goed is.

[JaapB]

Vollervo schreef op donderdag 16 februari 2023 @ 16:02:
[...]


Zijn die schakelaars van het type 'Blinds'? Volgens mij is dat in de tusenliggende release aangepast. Maar je kan ze omkeren bij de eigenschappen van de schakelaar als het goed is.

Lekker is dat, ga vanavond wel even aan de puzzel voor de 13 rolluiken die ik heb. En dan maar zien hoe het werkt met de scripts die ze aansturen ook.

Puzzeltjes zijn leuk maar soms?

[janne_nl]

Tsja, release notes lezen je, ook van tussenliggende releases. Zoals gezegd, aangepast in 2022.2. Genoeg over terug te vinden op het forum ook.

[kevi-n1]

Vandaag een bijzondere verassing. Ik gebruik Domoticz in Docker en heb de image vastgezet op 2022.2. Nu blijkt de image van 2022.2 recentelijk aangepast te zijn waardoor je 2023.1 krijgt. Alles lijkt nog te werken maar toch bijzonder...

[JaapB]

janne_nl schreef op donderdag 16 februari 2023 @ 16:49:
Tsja, release notes lezen je, ook van tussenliggende releases. Zoals gezegd, aangepast in 2022.2. Genoeg over terug te vinden op het forum ook.

Maar het blijft toch vreemd dat een functie na zoveel jaar omgekeerd wordt aan wat hij was.
En helaas niet zoveel over terug te vinden want ik had er al naar gezocht.

[niki_lauda]

JaapB schreef op donderdag 16 februari 2023 @ 22:32:
[...]

Maar het blijft toch vreemd dat een functie na zoveel jaar omgekeerd wordt aan wat hij was.
En helaas niet zoveel over terug te vinden want ik had er al naar gezocht.

https://www.domoticz.com/wiki/Blinds

Maar dat is een eeuwige discussie wanneer is de brug open.

[Voor 8% gewijzigd door niki_lauda op 17-02-2023 07:12]

[JaapB]

niki_lauda schreef op vrijdag 17 februari 2023 @ 07:09:
[...]

https://www.domoticz.com/wiki/Blinds

Maar dat is een eeuwige discussie wanneer is de brug open.

Dat van die brug is toch een ander verhaal hoor, dit is meer dat je normaal de sleutel rechtsom draait om de deur op slot te doen en je het nu linksom doet.
Heb de boel ondertussen voor de rolluiken omgekeerd maar nu blijkt de status die wordt weergegeven niet te kloppen. Rolluik is open maar status geeft aan dat hij dicht is. En het aanpassen van de status door die ook om te keren in de opties die heeft helaas geen effect.
Voor nu op de timers werkt het, maar hoe dit straks gaat met de scripts voor zonnig weer dat kan ik nog even niet voorspellen.
In het voorbeeld is Somfy 2 echt open maar geeft aan dat hij dicht is.

[Vollervo]

Dan lijkt me dat je de reverse optie niet moet gebruiken. Misschien ging het verkeerd omdat ze nu een andere status hebben (Open/Closed) en dat was volgens mij On/Off iig in de aansturing is dat gewijzigd.

[JaapB]

Vollervo schreef op vrijdag 17 februari 2023 @ 13:37:
Dan lijkt me dat je de reverse optie niet moet gebruiken. Misschien ging het verkeerd omdat ze nu een andere status hebben (Open/Closed) en dat was volgens mij On/Off iig in de aansturing is dat gewijzigd.

Met of zonder de reverse option blijven de melding voor de status identiek. De aktie is dus vanaf 2022.2 omgekeerd maar de weergave van de status niet. Dat houdt helaas ook in voor de scripts dat daar het opvragen van de status voor een aktie nu niet meer correct werkt.
Voorbeeld:
Als rolluik 1 open is en binnentemperatuur komt boven grenswaarde en buitentemperatuur komt boven grenswaarde en de hoeveelheid zonlicht komt boven de grenswaarde dan rolluik dichtsturen.

Dit gaat helaas niet werken als de status van het rolluik omgekeerd is aan de werkelijkheid.

[Neo--]

Ik mis nu wel de zonsopkomst en zonsondergang tijd op het dashboard tabblad
Na de update: download: Domoticz 2023.1

[klump4u]

Neo-- schreef op vrijdag 17 februari 2023 @ 16:05:
Ik mis nu wel de zonsopkomst en zonsondergang tijd op het dashboard tabblad
Na de update: download: Domoticz 2023.1

Staat er toch gewoon op, naast de tijd.

[Neo--]

klump4u schreef op vrijdag 17 februari 2023 @ 16:08:
[...]

Staat er toch gewoon op, naast de tijd.

Hmm, als ik intern binnen m'n netwerk kijk, dan wel.
Niet als ik van buitenaf het netwerk kijk.
Ik zal vast iets missen haha

Extern:


Intern:

[Voor 54% gewijzigd door Neo-- op 17-02-2023 16:33]

[klump4u]

Neo-- schreef op vrijdag 17 februari 2023 @ 16:29:
[...]


Hmm, als ik intern binnen m'n netwerk kijk, dan wel.
Niet als ik van buitenaf het netwerk kijk.
Ik zal vast iets missen haha

Extern:
[Afbeelding]

Intern:
[Afbeelding]

Cache opruimen, werkte bij mij ook, kijk maar eens bij extern of alle tabbladen werken.

[Neo--]

klump4u schreef op vrijdag 17 februari 2023 @ 17:45:
[...]

Cache opruimen, werkte bij mij ook, kijk maar eens bij extern of alle tabbladen werken.

Reeds gedaan (moest sowieso na update, want toen werkte dus niet alle tabbladen) Na het opruimen van cache wel weer, alleen dus geen opkomst en ondergangs tijden

EDIT: Schijnbaar half werk gedaan, nu opnieuw en met succes

[Voor 9% gewijzigd door Neo-- op 17-02-2023 18:10]

[vanenkelen]

Kan iemand eens meekijken naar mijn Dashticz dashboard? Ik ben bijna tevreden, op één puntje na.

Ik zou graag de buienradar ook binnen een block laten zien, dus met die grijze rand eromheen zoals ook bij de google maps weergave. Of als dat niet lukt andersom, dan de google maps weerkgave ook zonder grijze rand. Maar ik krijg het niet voor elkaar, iemand een tip?

Zie hieronder hoe het er nu uitziet en de stukken code in de config.js die ik gebruik.

code:

blocks['buien'] = {
  frameurl: 'https://gadgets.buienradar.nl/gadget/zoommap/?lat=51.67667&lng=4.79306&overname=2&zoom=8&naam=made&size=3&voor=1',
  scrollbars: false,
  width:12,
  aspectratio: 0.66
}
var maps = {}
maps.location = { 
  height: 300, 
  width: 12, 
  latitude: 52.0356824, 
  longitude: 4.718503, 
  zoom: 9
}
columns[6] = {
  blocks : ['blocktitle_14', 'buien', maps.location],
  width: 4
}

[de Peer]

vanenkelen schreef op zaterdag 18 februari 2023 @ 15:42:
Kan iemand eens meekijken naar mijn Dashticz dashboard? Ik ben bijna tevreden, op één puntje na.

Ik zou graag de buienradar ook binnen een block laten zien, dus met die grijze rand eromheen zoals ook bij de google maps weergave. Of als dat niet lukt andersom, dan de google maps weerkgave ook zonder grijze rand. Maar ik krijg het niet voor elkaar, iemand een tip?

Zie hieronder hoe het er nu uitziet en de stukken code in de config.js die ik gebruik.

[Afbeelding]

code:

blocks['buien'] = {
  frameurl: 'https://gadgets.buienradar.nl/gadget/zoommap/?lat=51.67667&lng=4.79306&overname=2&zoom=8&naam=made&size=3&voor=1',
  scrollbars: false,
  width:12,
  aspectratio: 0.66
}
var maps = {}
maps.location = { 
  height: 300, 
  width: 12, 
  latitude: 52.0356824, 
  longitude: 4.718503, 
  zoom: 9
}
columns[6] = {
  blocks : ['blocktitle_14', 'buien', maps.location],
  width: 4
}

is het niet zo dat hij wel in een block zit, maar dat de buienradar module zelf te groot is?
Heb je de width (van blocks['buien'] ) al eens naar een lagere waarde gezet om dat te controleren?

[vanenkelen]

de Peer schreef op zaterdag 18 februari 2023 @ 15:46:
[...]
is het niet zo dat hij wel in een block zit, maar dat de buienradar module zelf te groot is?
Heb je de width (van blocks['buien'] ) al eens naar een lagere waarde gezet om dat te controleren?

Als ik de width naar 11 zet, dan wordt het hele block kleiner (en ontstaan er ook geen randen). Bevestigt dat wat jij stelt?

[de Peer]

vanenkelen schreef op zaterdag 18 februari 2023 @ 15:49:
[...]


Als ik de width naar 11 zet, dan wordt het hele block kleiner (en ontstaan er ook geen randen). Bevestigt dat wat jij stelt?

[Afbeelding]

hmm oke nee ik hoopte dat je nu een stuk van het grijze block zou zien, maar dat is niet het geval helaas.

[vanenkelen]

de Peer schreef op zaterdag 18 februari 2023 @ 15:55:
[...]

hmm oke nee ik hoopte dat je nu een stuk van het grijze block zou zien, maar dat is niet het geval helaas.

Je kan in de code ook aangeven dat je een kleinere buienradar wil zien, maar dan gebeurt het volgende:


Dus dan blijft hij nog strak linksboven uitgelijnd in het block en wordt de horizontale ruimte opgevuld met wit. Naar beneden toe ontstaat dan wel de gewenste grijze rand...

[de Peer]

vanenkelen schreef op zaterdag 18 februari 2023 @ 15:56:
[...]

Je kan in de code ook aangeven dat je een kleinere buienradar wil zien, maar dan gebeurt het volgende:
[Afbeelding]

Dus dan blijft hij nog strak linksboven uitgelijnd in het block en wordt de horizontale ruimte opgevuld met wit. Naar beneden toe ontstaat dan wel de gewenste grijze rand...

Ja. ik denk dat er weinig aan te doen is..

[vanenkelen]

de Peer schreef op zaterdag 18 februari 2023 @ 16:00:
[...]

Ja. ik denk dat er weinig aan te doen is..

Dank voor het meedenken! Hopen dat iemand anders nog een tip heeft.

[Vollervo]

Iemand hier ervaring met de Heiman HS1SA-Z smokedetector? Ik heb hem toegevoegd in Zwave2mqtt en dat lijkt goed gegaan te zijn. Wat ik probeer te configureren is dat als het alarm afgaat, dat een paar lampen aangaan. Volgens mij zou ik daarvoor de lampen moeten toevoegen in de Basic set groep, maar helaas geen actie als ik de test knop gebruik. Tips?

[asing]

Sinds gisteravond liggen hier panelen op het dak. Ik wilde even spieken naar de opbrengst en Domoticz heeft een P1 meter. Dus daar even gekeken.....



Dit is wel een beetje bizar

[rens-br]

Vollervo schreef op maandag 20 februari 2023 @ 17:11:
Iemand hier ervaring met de Heiman HS1SA-Z smokedetector? Ik heb hem toegevoegd in Zwave2mqtt en dat lijkt goed gegaan te zijn. Wat ik probeer te configureren is dat als het alarm afgaat, dat een paar lampen aangaan. Volgens mij zou ik daarvoor de lampen moeten toevoegen in de Basic set groep, maar helaas geen actie als ik de test knop gebruik. Tips?

Ik heb die ook, maar dan via conbee stick.

Ik heb niet het idee dat ze in een groep gooien automatisch ervoor zorgt dat lampen gaan branden.

Je zal waarschijnlijk met een script aan de slag moeten die het alarm afvangt. Ik heb een script gemaakt die een notificatie verstuurd, zie hieronder:

code:

--*------------------------------------------------------------------------------------*--
--Creator: Rens
--Date: 11-07-2022
--Last update: 
--Changelog:
--Source: -
--Description: Send notificaton when there is fire
--*------------------------------------------------------------------------------------*--

--Declarations
local FireHalNum        = 602 -- Fire Hal
local FireOverloopNum   = 603 -- Fire Overloop
local FireZolderNum     = 604 -- Fire Zolder

return {
    on = {
        devices = {
            FireHalNum,      
            FireOverloopNum,
            FireZolderNum
        }
    },
    execute = function(domoticz, device)
        --Declarations
        local FireHal       = domoticz.devices(FireHalNum) -- Fire Hal
        local FireOverloop  = domoticz.devices(FireOverloopNum) -- Fire Overloop
        local FireZolder    = domoticz.devices(FireZolderNum) -- Fire Zolder
        
        --Function
        if (FireHal.active) then -- Brand hal
            domoticz.notify('Alarm','Brand in de hal',domoticz.PRIORITY_HIGH)
        elseif (FireOverloop.active) then -- Brand overloop
            domoticz.notify('Alarm','Brand op de overloop',domoticz.PRIORITY_HIGH)
        elseif (FireZolder.active) then -- Brand Zolder
            domoticz.notify('Alarm','Brand op zolder',domoticz.PRIORITY_HIGH)
        end
    end
}

[Voor 41% gewijzigd door rens-br op 20-02-2023 22:35]

[rens-br]

asing schreef op maandag 20 februari 2023 @ 18:10:
Sinds gisteravond liggen hier panelen op het dak. Ik wilde even spieken naar de opbrengst en Domoticz heeft een P1 meter. Dus daar even gekeken.....

[Afbeelding]

Dit is wel een beetje bizar

Hoeveel 1000 panelen heb je op je dak liggen?

[asing]

rens-br schreef op maandag 20 februari 2023 @ 18:12:
[...]


Hoeveel 1000 panelen heb je op je dak liggen?

In totaal 8 met 405Wp per stuk.

De meter zelf geeft ook niks geks aan, die staat vanwege alle bewolking nog op 00000 kWh. Ik denk dat ik een beter beeld ga krijgen als de zon zich een keer laat zien.

[Voor 29% gewijzigd door asing op 20-02-2023 18:31]

[klump4u]

asing schreef op maandag 20 februari 2023 @ 18:10:
Sinds gisteravond liggen hier panelen op het dak. Ik wilde even spieken naar de opbrengst en Domoticz heeft een P1 meter. Dus daar even gekeken.....

[Afbeelding]

Dit is wel een beetje bizar

Dagje wachten en die telling verwijderen.

[de Peer]

Vollervo schreef op maandag 20 februari 2023 @ 17:11:
Iemand hier ervaring met de Heiman HS1SA-Z smokedetector? Ik heb hem toegevoegd in Zwave2mqtt en dat lijkt goed gegaan te zijn. Wat ik probeer te configureren is dat als het alarm afgaat, dat een paar lampen aangaan. Volgens mij zou ik daarvoor de lampen moeten toevoegen in de Basic set groep, maar helaas geen actie als ik de test knop gebruik. Tips?

Ik heb hem ook. Werkt prima. Gewoon in domoticz scriptje maken.

[bello2011]

Omdat mijn watermeter een foute waarde had doorgegeven heb ik met DB Browser (SQLite) een waarde aangepast in "domoticz.db". Deze aanpassing heb ik gemaakt in de tabel meter_calendar. Na opnieuw opstarten is deze waarde correct overgenomen in Domoticz. Echter... In alle grafieken van de laatste 24 uur is nu "No data to display". Dus niet alleen van het apparaat welk ik heb aangepast maar van allemaal. In de grafieken van de laatste week, enz worden de waarden wel zichtbaar.
Wat heb ik fout gedaan en hoe kan ik dit herstellen?

O,ja... ik had een backup terug gezet maar daarmee kan ik niet meer inloggen.

[Voor 7% gewijzigd door bello2011 op 20-02-2023 20:02]

[asing]

Ik denk dat ik het heb. Hij schijnt op tilt te slaan als er een hele kleine waarde wordt doorgegeven. Dit weekend verwacht ik dat het weer klopt.

[klump4u]

bello2011 schreef op maandag 20 februari 2023 @ 20:01:
Omdat mijn watermeter een foute waarde had doorgegeven heb ik met DB Browser (SQLite) een waarde aangepast in "domoticz.db". Deze aanpassing heb ik gemaakt in de tabel meter_calendar. Na opnieuw opstarten is deze waarde correct overgenomen in Domoticz. Echter... In alle grafieken van de laatste 24 uur is nu "No data to display". Dus niet alleen van het apparaat welk ik heb aangepast maar van allemaal. In de grafieken van de laatste week, enz worden de waarden wel zichtbaar.
Wat heb ik fout gedaan en hoe kan ik dit herstellen?

O,ja... ik had een backup terug gezet maar daarmee kan ik niet meer inloggen.

Dan toch iets verkeerd aangepast, heb je niet eerst een backup van de database gemaakt?

[Knielen]

bello2011 schreef op maandag 20 februari 2023 @ 20:01:
Omdat mijn watermeter een foute waarde had doorgegeven heb ik met DB Browser (SQLite) een waarde aangepast in "domoticz.db". Deze aanpassing heb ik gemaakt in de tabel meter_calendar. Na opnieuw opstarten is deze waarde correct overgenomen in Domoticz. Echter... In alle grafieken van de laatste 24 uur is nu "No data to display". Dus niet alleen van het apparaat welk ik heb aangepast maar van allemaal. In de grafieken van de laatste week, enz worden de waarden wel zichtbaar.
Wat heb ik fout gedaan en hoe kan ik dit herstellen?

O,ja... ik had een backup terug gezet maar daarmee kan ik niet meer inloggen.

Browser cache al een keer leeggemaakt?

[bello2011]

Knielen schreef op maandag 20 februari 2023 @ 21:13:
[...]


Browser cache al een keer leeggemaakt?

Zeker maar dit heeft geen effect.

[bello2011]

klump4u schreef op maandag 20 februari 2023 @ 20:57:
[...]

Dan toch iets verkeerd aangepast, heb je niet eerst een backup van de database gemaakt?

Jawel maar als ik deze terugzet dan herkend Domoticz mijn inlognaam/wachtwoord niet meer.

[Knielen]

bello2011 schreef op maandag 20 februari 2023 @ 21:17:
[...]


Zeker maar dit heeft geen effect.

Misschien dat je wat hebt aan dit topic:

https://www.domoticz.com/forum/viewtopic.php?t=38962

[bello2011]

Knielen schreef op maandag 20 februari 2023 @ 21:35:
[...]


Misschien dat je wat hebt aan dit topic:

https://www.domoticz.com/forum/viewtopic.php?t=38962

Ik heb een dump gemaakt van mijn huidige database en het dumpbestand geladen in een nieuwe database en dit werkt!!

https://www.domoticz.com/...opic.php?p=202520#p202520

Bedankt!!

[JaapB]

Helaas na een week puzzelen en proberen blijven de problemen met de RTS rolluikmotoren als gevolg van de omgekeerde functionaliteit. Vraag hierover op het Domoticz forum levert helaas ook geen antwoord op.

Is er een mogelijkheid om terug te grijpen op versie 2022.1 zodat de rolluiken weer werken zoals ze ruim 6 jaar daarvoor prima hebben gewerkt in zowel de timers als de scripts, waarbij de scripts gewoon onlogisch zouden moeten worden omdat de status omgekeerd blijft wat ik ook probeer.

Situatie was zo dat stand van de rolluik wordt gecheckt samen met de hoeveelheid licht, binnentemperatuur en buitentemperatuur en als blijkt dat het luik open is, de lichthoeveelheid boven een bepaalde grens is in combinatie met een binnentemperatuur en buitentemperatuur boven een bepaalde grens dat dan het luik wordt dichtgestuurd.

Nu echter is bij een open luik de status in Domoticz dat hij dicht is en gaat het schript dus niets uitvoeren.

En het is ook onlogisch om script aan te passen zodat hij kijkt of het luik dicht aangeeft om hem dan dicht te sturen.

[Knielen]

JaapB schreef op zaterdag 25 februari 2023 @ 10:55:
Helaas na een week puzzelen en proberen blijven de problemen met de RTS rolluikmotoren als gevolg van de omgekeerde functionaliteit. Vraag hierover op het Domoticz forum levert helaas ook geen antwoord op.

Is er een mogelijkheid om terug te grijpen op versie 2022.1 zodat de rolluiken weer werken zoals ze ruim 6 jaar daarvoor prima hebben gewerkt in zowel de timers als de scripts, waarbij de scripts gewoon onlogisch zouden moeten worden omdat de status omgekeerd blijft wat ik ook probeer.

Situatie was zo dat stand van de rolluik wordt gecheckt samen met de hoeveelheid licht, binnentemperatuur en buitentemperatuur en als blijkt dat het luik open is, de lichthoeveelheid boven een bepaalde grens is in combinatie met een binnentemperatuur en buitentemperatuur boven een bepaalde grens dat dan het luik wordt dichtgestuurd.

Nu echter is bij een open luik de status in Domoticz dat hij dicht is en gaat het schript dus niets uitvoeren.

En het is ook onlogisch om script aan te passen zodat hij kijkt of het luik dicht aangeeft om hem dan dicht te sturen.

Ik snap je bezwaar om het script aan te passen niet, als het daarna weer werkt dan maakt het toch niet uit wat voor naam het beestje heeft?

[JaapB]

Knielen schreef op zaterdag 25 februari 2023 @ 13:05:
[...]


Ik snap je bezwaar om het script aan te passen niet, als het daarna weer werkt dan maakt het toch niet uit wat voor naam het beestje heeft?

Het zit in de logica die niet meer klopt, ik kijk nu naar buiten en het rolluik is open. Op het dashboard staat hij als dicht, en als ik dan op dat dichte luik klik gaat hij dicht en de status naar open. Andersom zal hij bij dichte stand, wat dus open op het dashboard is, bij het klikken op openen wel opengaan maar de status geeft aan dat hij dicht is.

Het lijkt er dus op dat met het omkeren van de functie open en dicht niet de status is meeveranderd, en is ook niet in te stellen bij het aanpassen.

En het risico van aanpassen van het script naar de onlogische versie is dat bij een volgende update het ineens wel is mee veranderd en het weer aangepast moet worden.

Vandaar dat ik dan liever terugstap op de vorige versie omdat het in de afgelopen ruim 6 jaar nooit gefaald heeft en ik die omgekeerde werking van de blinds ook niet logisch vind en daar ook niets over terug kan vinden wat de reden was.

[MikeyMan]

@Andrehj Was het jou nog gelukt om de devices te replacen na de overstap naar zwave-js?

[Andrehj]

MikeyMan schreef op zaterdag 25 februari 2023 @ 15:29:
@Andrehj Was het jou nog gelukt om de devices te replacen na de overstap naar zwave-js?

Nope. Ik heb ze nieuw aangemaakt. Was bij mij ook niet zo erg, ik gebruik ze toch niet in scripts en het waren er maar een stuk of 5.

[Dylantje2]

asing schreef op maandag 20 februari 2023 @ 18:20:
[...]


In totaal 8 met 405Wp per stuk.

De meter zelf geeft ook niks geks aan, die staat vanwege alle bewolking nog op 00000 kWh. Ik denk dat ik een beter beeld ga krijgen als de zon zich een keer laat zien.

Is een dingetje in Domoticz.
Al lang. helaas.
Soms bij een update of je shelly update oid plots pikes...
Ticket aanmaken, op github, mss nui een oplossing ervoor

[asing]

Dylantje2 schreef op zaterdag 25 februari 2023 @ 20:10:
[...]


Is een dingetje in Domoticz.
Al lang. helaas.
Soms bij een update of je shelly update oid plots pikes...
Ticket aanmaken, op github, mss nui een oplossing ervoor

Het loste zichzelf op toen de zon ging schijnen. Dan kloppen de getallen wel. Ook in de grafieken is het normaal.

[niki_lauda]

JaapB schreef op zaterdag 25 februari 2023 @ 10:55:
Helaas na een week puzzelen en proberen blijven de problemen met de RTS rolluikmotoren als gevolg van de omgekeerde functionaliteit. Vraag hierover op het Domoticz forum levert helaas ook geen antwoord op.

Is er een mogelijkheid om terug te grijpen op versie 2022.1 zodat de rolluiken weer werken zoals ze ruim 6 jaar daarvoor prima hebben gewerkt in zowel de timers als de scripts, waarbij de scripts gewoon onlogisch zouden moeten worden omdat de status omgekeerd blijft wat ik ook probeer.

Situatie was zo dat stand van de rolluik wordt gecheckt samen met de hoeveelheid licht, binnentemperatuur en buitentemperatuur en als blijkt dat het luik open is, de lichthoeveelheid boven een bepaalde grens is in combinatie met een binnentemperatuur en buitentemperatuur boven een bepaalde grens dat dan het luik wordt dichtgestuurd.

Nu echter is bij een open luik de status in Domoticz dat hij dicht is en gaat het schript dus niets uitvoeren.

En het is ook onlogisch om script aan te passen zodat hij kijkt of het luik dicht aangeeft om hem dan dicht te sturen.

Je kunt bij de rollluiken de status inverteren

[JaapB]

niki_lauda schreef op zaterdag 25 februari 2023 @ 20:36:
[...]

Je kunt bij de rollluiken de status inverteren

Inderdaad en dat heb ik gedaan maar dat had geen effect.
Verder uiteraard cache gewist, domoticz meermalen opnieuw opgestart, de raspberry meermalen opnieuw opgestart, domoticz via privévenster geopend, zelfs geopend vanaf een schoon geïnstalleerde PC maar in alle gevallen zonder effect. De verkeerde status blijft weergegeven worden, zowel voor het script als voor de blinds-schakelaars op het dashboard.

Dus ergens is die omkering van de functie niet compleet uitgevoerd in domoticz en weet ik dat ik bij versie 2022.1 nog een goed en logisch werkend systeem had. Jammer dat ze die functie om hebben gekeerd.

Net nog even gekeken maar ik gebruik domoticz al sinds 2014 en sinds mei 2015 de aansturing van de RTS rolluikmotoren.

[Voor 7% gewijzigd door JaapB op 25-02-2023 23:09]

[imdos]

JaapB schreef op zaterdag 25 februari 2023 @ 23:06:
[...]

Inderdaad en dat heb ik gedaan maar dat had geen effect.
Verder uiteraard cache gewist, domoticz meermalen opnieuw opgestart, de raspberry meermalen opnieuw opgestart, domoticz via privévenster geopend, zelfs geopend vanaf een schoon geïnstalleerde PC maar in alle gevallen zonder effect. <knip>

Even iets anders. Kun je niet via de originele afstandsbedieding de status veranderen zonder dat domoticz online is. Dan klopt het toch weer?

[JaapB]

imdos schreef op maandag 27 februari 2023 @ 10:41:
[...]

Even iets anders. Kun je niet via de originele afstandsbedieding de status veranderen zonder dat domoticz online is. Dan klopt het toch weer?

Dat is een optie waarbij dan de werking van de afstandsbediening omgekeerd wordt, niet echt logisch dat er dan 13 draadloze muurschakelaars omgekeerd werken.
Dan zou ik daarna de schakelaars 180° moeten draaien om daar weer logica voor te hebben. Echter dan zit ik nog met de 16 kanaals zender die dan omgekeerde bediening heeft.
En dat alles omdat de functie binnen Domoticz is aangepast maar niet over de hele linie door de verkeerde status.

[M.v.Veelen]

Ik draai alweer een paar weekjes Domoticz op m'n RPi op een nieuwe USB drive en het enige dat ik niet voor elkaar krijg, is om Domoticz via de webinterface te updaten. Voorheen ging dat altijd prima, maar nu moet ik dmv SSH naar de RPi en ./updatebeta invoeren.

Via de GUI telt domoticz naar 100(%), maar er komt dan een melding dat het downloaden van de update is mislukt en dat ik m'n internetverbinding moet nakijken. Dat is kul natuurlijk, maar het lukt dus niet meer om via de GUI te updaten. Wat zou de oorzaak kunnen zijn?

[Dylantje2]

M.v.Veelen schreef op dinsdag 28 februari 2023 @ 20:40:
Ik draai alweer een paar weekjes Domoticz op m'n RPi op een nieuwe USB drive en het enige dat ik niet voor elkaar krijg, is om Domoticz via de webinterface te updaten. Voorheen ging dat altijd prima, maar nu moet ik dmv SSH naar de RPi en ./updatebeta invoeren.

Via de GUI telt domoticz naar 100(%), maar er komt dan een melding dat het downloaden van de update is mislukt en dat ik m'n internetverbinding moet nakijken. Dat is kul natuurlijk, maar het lukt dus niet meer om via de GUI te updaten. Wat zou de oorzaak kunnen zijn?

cookies...

Doe het eens in een incognito venster
Of wat gebeurd er wel of niet als je update via de webui?

[M.v.Veelen]

Cookies verwijderen of update in incognito venster draaien helpt niet.

Bij het starten van de update telt Domoticz tot 100% (duurt lang, ongeveer 100 seconden) en staat er dit:

Update Available... Downloading Update !...

Bij de 100% aangekomen verschijnt:

Error while downloading Update,
check your internet connection or try again later !...

En moet ik via de CLI alsnog updaten. Dat gaat a) veel sneller en b) werkt wel.

[JohnS]

Ik ben bezig met het testen van Domoticz in docker te draaien. NU heb ik een python script van @remco_k voor het uitlezen van de GoodWe inverter. Alleen krijg ik de volgende error als de plugin wordt gestart :

2023-03-03 08:00:24.737 Error: GoodWe Inverter: (GoodWe_ModbusUDP) failed to load 'plugin.py', Python Path used was '/opt/domoticz/userdata/plugins/domoticz-goodwe-modbusudp-plugin/:/usr/lib/python39.zip:/usr/lib/python3.9:/usr/lib/python3.9/lib-dynload:/usr/local/lib/python3.9/dist-packages:/usr/lib/python3/dist-packages:/usr/lib/python3.9/dist-packages'.

Ik heb mijn domoticz docker container als volgt gestart :

sudo docker run --restart always -d -p 8080:8080 -p 8443:443 --name domoticz -v /home/pi/dockerdata/domoticz/data:/opt/domoticz/userdata -e TZ=Europe/Amsterdam domoticz/domoticz

Wat doe ik fout?

[Voor 0% gewijzigd door JohnS op 03-03-2023 09:25. Reden: Opmaak]

[remco_k]

Install requirements doorgelopen?
Vooral:

code:

sudo pip3 install -r requirements.txt

En dat in die docker container uiteraard.

[Voor 27% gewijzigd door remco_k op 03-03-2023 20:21]

[remco_k]

Ps. Ik heb zojuist een fix, verbeteringen en wat aanpassingen die al even op de plank lagen gemerged naar master, versie 0.0.4.
Wellicht kan je die meteen even updaten bij jouw.

[Voor 9% gewijzigd door remco_k op 03-03-2023 23:57]

[SniperGuy]

Ik heb een probleem dat mn Domoticz op m'n Rpi (volgens mij sinds de laatste update) steeds maar aan poort 443 wil binden, ondanks dat in zowel /etc/init.d/domoticz.sh als /home/pi/domoticz/domoticz.sh ALLEEN DAEMON_ARGS="$DAEMON_ARGS -www 8081"
Ergens lijkt het alsof toch -sslwww 443 ergens doorgegeven wordt. Ik ik kijk naar de service dan staat daar echt alleen 8081:

code:

● domoticz.service - LSB: Home Automation System
     Loaded: loaded (/etc/init.d/domoticz.sh; generated)
     Active: active (running) since Sat 2023-03-04 16:39:54 CET; 28s ago
       Docs: man:systemd-sysv-generator(8)
    Process: 1886 ExecStart=/etc/init.d/domoticz.sh start (code=exited, status=0/SUCCESS)
      Tasks: 22 (limit: 4915)
        CPU: 3.311s
     CGroup: /system.slice/domoticz.service
             └─1894 /home/pi/domoticz/domoticz -daemon -www 8081

Mar 04 16:39:54 pihole systemd[1]: Starting LSB: Home Automation System...

Kijk ik in de loggin in de HTTP gui dan zie ik beide poorten:

code:

2023-03-04 16:39:54.943 Status: WebServer(HTTP) started on address: 0.0.0.0 with port 8081
2023-03-04 16:39:54.954 Status: WebServer(SSL) started on address: 0.0.0.0 with port 443

Stop ik de service dan luisteren zowel poort 443 als 8081 niet meer.

Een netstat laat zien dat het domoticz is die naar 443 luisterd:

code:

tcp        0      0 0.0.0.0:443             0.0.0.0:*               LISTEN      792/domoticz

In htop zie ik wel een proces WebServer_443 /home/pi/domoticz/domoticz -daemon -www 8081 én WebServer_8081 /home/pi/domoticz/domoticz -daemon -www 8081

[Voor 11% gewijzigd door SniperGuy op 04-03-2023 17:02]

[MikeyMan]

Ik heb afgelopen zaterdag een paar extra zonnepanelen in werking gesteld. Wil nu de totaalopbrengst optellen in domoticz. Ben aan het prutsen geweest met dit script:

code:

return
{
    on =
    {
        timer = {
            'every minute'       
                  }
    },

    logging =
    {
        level = domoticz.LOG_DEBUG,
        marker = 'Totaal Zonnepanelen',
    },

    execute = function(domoticz, device, item)

        local SolarEdge = domoticz.devices(9).counterToday
        local Goodwe = domoticz.devices(632).counterToday
        local Total = SolarEdge + Goodwe

        domoticz.log('Totaalopbrengst Zonnepanelen counterToday: ' .. Total)

--        domoticz.devices(648).updateEnergy(Total)
        domoticz.devices(649).updateElectricity(Total)
    end
}

Maar het lijkt nog niet helemaal te werken zo.


Er wordt wel iets weggeschreven, maar niet goed.

Heb de wiki bekeken, maar kom er nog niet helemaal uit waar het mis gaat.
Het commando updateElectricity(power, energy): Function. Supports command options. lijkt zowel power als energy te kunnen ontvangen. Maar ik heb maar 1 waarde die ik opgeteld wil hebben.

Wat zou ik nog kunnen proberen?

[Heinemancp]

MikeyMan schreef op maandag 6 maart 2023 @ 09:30:
Ik heb afgelopen zaterdag een paar extra zonnepanelen in werking gesteld. Wil nu de totaalopbrengst optellen in domoticz. Ben aan het prutsen geweest met dit script:

code:

return
{
    on =
    {
        timer = {
            'every minute'       
                  }
    },

    logging =
    {
        level = domoticz.LOG_DEBUG,
        marker = 'Totaal Zonnepanelen',
    },

    execute = function(domoticz, device, item)

        local SolarEdge = domoticz.devices(9).counterToday
        local Goodwe = domoticz.devices(632).counterToday
        local Total = SolarEdge + Goodwe

        domoticz.log('Totaalopbrengst Zonnepanelen counterToday: ' .. Total)

--        domoticz.devices(648).updateEnergy(Total)
        domoticz.devices(649).updateElectricity(Total)
    end
}

Maar het lijkt nog niet helemaal te werken zo.
[Afbeelding]

Er wordt wel iets weggeschreven, maar niet goed.

Heb de wiki bekeken, maar kom er nog niet helemaal uit waar het mis gaat.
Het commando updateElectricity(power, energy): Function. Supports command options. lijkt zowel power als energy te kunnen ontvangen. Maar ik heb maar 1 waarde die ik opgeteld wil hebben.

Wat zou ik nog kunnen proberen?

Klopt toch? Je pakt de counterToday (0.5kWh en 0.1kWh) en die tel je bij elkaar op en schrijf je weg = 0.6
Dus je zou het actualPower (of zo iets - moet je even kijken) moeten gebruiken voor het totale actuele vermogen, zodat de counterToday totaal ook oploopt.

als je de power niet wilt, kan je denk ik
domoticz.devices(649).updateElectricity(0,Total) gebruiken. dan update hij de counterToday denk ik.

daarnaast zou ik dit niet elke minuut doen maar op wijziging van een van de twee omvormer-inputs. Dan is het altijd actueel. dus aanroepen niet per minute maar on Change of Goodwe of SE

[Voor 5% gewijzigd door Heinemancp op 06-03-2023 09:39]

[MikeyMan]

Heinemancp schreef op maandag 6 maart 2023 @ 09:37:
[...]


Klopt toch? Je pakt de counterToday (0.5kWh en 0.1kWh) en die tel je bij elkaar op en schrijf je weg = 0.6
Dus je zou het actualPower (of zo iets - moet je even kijken) moeten gebruiken voor het totale actuele vermogen, zodat de counterToday totaal ook oploopt.

als je de power niet wilt, kan je denk ik
domoticz.devices(649).updateElectricity(0,Total) gebruiken. dan update hij de counterToday denk ik.

daarnaast zou ik dit niet elke minuut doen maar op wijziging van een van de twee omvormer-inputs. Dan is het altijd actueel. dus aanroepen niet per minute maar on Change of Goodwe of SE

Ah, check, ik snap wat je bedoelt. Die energy devices vanuit Goodwe/Solaredge hebben ook meedere waardes.

Dit lijkt te werken.
Nu nog ff kijken hoe we on change fixen :-)

edit; zo eens proberen:

code:

return
{
    on =
    {
--        timer = {
--          'every minute'       
--                }
        devices =   {
            '9',
            '632'
                    }
    },

    logging =
    {
        level = domoticz.LOG_DEBUG,
        marker = 'Totaal Zonnepanelen',
    },

    execute = function(domoticz, device, item)

        local SolarEdgeToday = domoticz.devices(9).counterToday
        local SolarEdge = domoticz.devices(9).actualWatt
        local GoodweToday = domoticz.devices(632).counterToday
        local Goodwe = domoticz.devices(632).actualWatt
        local Total = SolarEdge + Goodwe
        local TotalToday = SolarEdgeToday + GoodweToday

        domoticz.log('Totaalopbrengst Zonnepanelen actualWatt: ' .. Total)
        domoticz.log('Totaalopbrengst Zonnepanelen counterToday ' .. TotalToday)

--        domoticz.devices(648).updateEnergy(Total)
        domoticz.devices(649).updateElectricity(Total,TotalToday)
    end
}

Dat lijkt helaas niet te werken nog...

doh. aanhalingstekens om de IDX weghalen natuurlijk

[Voor 7% gewijzigd door MikeyMan op 06-03-2023 09:53]

[Heinemancp]

MikeyMan schreef op maandag 6 maart 2023 @ 09:42:
[...]


Ah, check, ik snap wat je bedoelt. Die energy devices vanuit Goodwe/Solaredge hebben ook meedere waardes.

Dit lijkt te werken.
Nu nog ff kijken hoe we on change fixen :-)

edit; zo eens proberen:

code:

return
{
    on =
    {
--        timer = {
--          'every minute'       
--                }
        devices =   {
            '9',
            '632'
                    }
    },

    logging =
    {
        level = domoticz.LOG_DEBUG,
        marker = 'Totaal Zonnepanelen',
    },

    execute = function(domoticz, device, item)

        local SolarEdgeToday = domoticz.devices(9).counterToday
        local SolarEdge = domoticz.devices(9).actualWatt
        local GoodweToday = domoticz.devices(632).counterToday
        local Goodwe = domoticz.devices(632).actualWatt
        local Total = SolarEdge + Goodwe
        local TotalToday = SolarEdgeToday + GoodweToday

        domoticz.log('Totaalopbrengst Zonnepanelen actualWatt: ' .. Total)
        domoticz.log('Totaalopbrengst Zonnepanelen counterToday ' .. TotalToday)

--        domoticz.devices(648).updateEnergy(Total)
        domoticz.devices(649).updateElectricity(Total,TotalToday)
    end
}

Dat lijkt helaas niet te werken nog...

doh. aanhalingstekens om de IDX weghalen natuurlijk

top! zie:

on = {
devices = {
'Solaredgde', 'Goodwe'

[MikeyMan]

Heinemancp schreef op maandag 6 maart 2023 @ 10:00:
[...]


top! zie:

[...]

Hij lijkt het nu te doen. Maar hoe werkt dit in de praktijk?
Als één van beiden bijwerkt, gaat ie het script draaien. Krijg je dan geen dubbelingen?

[Heinemancp]

MikeyMan schreef op maandag 6 maart 2023 @ 10:07:
[...]


Hij lijkt het nu te doen. Maar hoe werkt dit in de praktijk?
Als één van beiden bijwerkt, gaat ie het script draaien. Krijg je dan geen dubbelingen?

Hij update de Total counter bij elke wijziging van een van de twee omvormers, je krijgt zeker geen dubbelingen - want hij update de counter alleen maar. Zelfde als bij elke energiemeter, je krijgt door deze 'on change' aanroep een veel accurater totaal.

[MikeyMan]

Heinemancp schreef op maandag 6 maart 2023 @ 10:11:
[...]


Hij update de Total counter bij elke wijziging van een van de twee omvormers, je krijgt zeker geen dubbelingen - want hij update de counter alleen maar. Zelfde als bij elke energiemeter, je krijgt door deze 'on change' aanroep een veel accurater totaal.

Cool

Geloof dat er nog iets mis gaat nog:



De totaalopbrengst loopt niet op lijkt het. Zie in log wel veranderende waardes.

code:

2023-03-06 10:22:48.555 Status: dzVents: Info: Totaal Zonnepanelen: ------ Start internal script: Zonnepanelen: Device: "Goodwe - Inverter output power (Goodwe)", Index: 632
2023-03-06 10:22:48.556 Status: dzVents: Debug: Totaal Zonnepanelen: Processing device-adapter for Solaredge - kWh Meter Inverter 1: kWh device adapter
2023-03-06 10:22:48.556 Status: dzVents: Info: Totaal Zonnepanelen: Totaalopbrengst Zonnepanelen actualWatt: 1461.0
2023-03-06 10:22:48.556 Status: dzVents: Info: Totaal Zonnepanelen: Totaalopbrengst Zonnepanelen counterToday 1.9
2023-03-06 10:22:48.558 Status: dzVents: Debug: Totaal Zonnepanelen: Processing device-adapter for Totaal opbrengst: kWh device adapter
2023-03-06 10:22:48.558 Status: dzVents: Info: Totaal Zonnepanelen: ------ Finished Zonnepanelen

Misschien ben ik wat ongeduldig

edit:

Toch maar andere waarde gebruiken:

code:

kWh, Electricity (instant and counter)
actualWatt: Number. Actual usage in Watt.
counterToday: Number.
updateElectricity(power, energy): Function. Supports command options.
usage: Number.
WhToday: Number. Total Wh usage of the day. Note the unit is Wh and not kWh!
WhTotal: Number. Total Wh usage.
WhActual: Number. Actual reading in Watt. Please use actualWatt

WhToday gaan we eens proberen

Ha, victorie!

[Voor 19% gewijzigd door MikeyMan op 06-03-2023 10:47]