:strip_exif()/i/1354526135.png?f=thumbmini)
:fill(white):strip_exif()/i/2000578080.jpeg?f=thumbmini)
:fill(white):strip_exif()/i/2000629918.jpeg?f=thumbmini)
:fill(white):strip_exif()/i/2002131643.jpeg?f=thumbmini)
:fill(white):strip_exif()/i/2000576874.jpeg?f=thumbmini)
:fill(white):strip_exif()/i/2000576862.jpeg?f=thumbmini)
:fill(white):strip_exif()/i/2000580484.jpeg?f=thumbmini)
:strip_icc():strip_exif()/u/79716/AK_avatar_100.jpg?f=community){kind=avatar}
Hoe ben je dit te weten gekomen? Het lijkt mij dat als die curl call uit mijn post hierboven werkt, alles in orde zou moeten zijn, nee?Lytsepier schreef op donderdag 19 mei 2016 @ 11:45:
Ik heb ook een uitdaging gehad mbt Logitech Hub en Domoticz. Het probleem was dat mijn Pi geen DNS kon doen. Nadat ik dit geregeld had, werkt het zonder veel problemen.
:strip_icc():strip_exif()/u/212073/crop5790930e15fe8_cropped.jpeg?f=community)
:strip_icc():strip_exif()/u/111701/crop634d24c22c9ca.jpg?f=community)
:strip_exif()/u/20090/crop584c819636958_cropped.gif?f=community)
Ik heb exact dezelfde camera en heb het volgende ingevuld (en dat werkt):
cgi-bin/CGIProxy.fcgi?cmd=snapPicture2&usr=xxxxxx&pwd=xxxxxx
Dus je had het bijna goed
cgi-bin/CGIProxy.fcgi?cmd=snapPicture2&usr=xxxxxx&pwd=xxxxxx
Dus je had het bijna goed
¯\_(ツ)_/¯
Ik had deze idd ook al geprobeerd.....geen resultaat.:
Ik heb exact dezelfde camera en heb het volgende ingevuld (en dat werkt):
cgi-bin/CGIProxy.fcgi?cmd=snapPicture2&usr=xxxxxx&pwd=xxxxxx
Dus je had het bijna goed
Verder heb ik de volgende velden ingevuld.
Actief: V
Naam: Foscam
IP Adres: xxx.xxx.xxx.xxx
Poort: 88
Gebruikersnaam: Kromme
Wachtwoord: Zuk
ImageURL: cgi-bin/CGIProxy.fcgi?cmd=snapPicture2&usr=Kromme&pwd=Zuk
Keep it calm...en lek mig de zuk
:strip_icc():strip_exif()/u/5326/crop5ff8e3fc691c6_cropped.jpeg?f=community)
Dat zit toch gewoon in domoticz ? Alleen nog een sirene er bij (wat overigens prima kan met rf brandmelders) en klaar.
Duct tape can't fix stupid, but it can muffle the sound.
Heb ik ze ook gekocht, zeker ook gekocht toen ze in de aanbieding waren
Misschien proberen om niet direct de nieuwste firmware te flashen maar stap voor stap te upgraden.
Als ik op de firmware pagina kijk heb jij de oudste versie dus mogelijk eerst de volgende versie upgraden en als dat lukt ga je weer naar de volgende etc tot je bij de nieuwste uitkomt.
Wel altijd readme even lezen die erbij zit zodat je zeker weet dat je dit firmware kan gebruiken.
Reset de camera altijd terug naar fabrieksinstellingen voor je de upgrade start en wordt ook als advies gegeven.
Lukt dat ook niet dan retour sturen want dan klopt er echt iets niet.
Ik heb Paradigit al gemaild.
Zal vanavond eens upgrade voor upgrade proberen maar heb er geen vertrouwen in ...
En ja deze zijn van de aanbieding
Zal vanavond eens upgrade voor upgrade proberen maar heb er geen vertrouwen in ...
En ja deze zijn van de aanbieding
Keep it calm...en lek mig de zuk
Bij mij heeft dit geholpen. Kan nu idd ook via app updaten.:
Ik heb Paradigit al gemaild.
Zal vanavond eens upgrade voor upgrade proberen maar heb er geen vertrouwen in ...
En ja deze zijn van de aanbieding
:strip_icc():strip_exif()/u/44988/crop5ebb1607ca069_cropped.jpeg?f=community)
:strip_icc():strip_exif()/u/63553/crop5702a8827f86e_cropped.jpeg?f=community)
Heb er even naar gekeken, goed om te zien dat ik niet de enige malloot ben die alles altijd in PHP wil doen
Begrijp ik nu goed dat alles via jouw systeem werkt door op de switches een action url op te geven en verder via cron de boel afgehandeld wordt?
Ik doe het zelf nu door middels een LUA device script alle LUA vars om te zetten naar JSON en Base64 te encoden en die naar een PHP CLI script door te sturen. Het doorsturen en weer decoderen en opzetten van de arrays in PHP kost een kleine 2ms aan tijd, dus dat is verwaarloosbaar. Vervolgens heb ik in PHP de beschikking over alle data die je ook in LUA zou hebben. Hier hoef ik dan ook geen switches te voorzien van action URL's.
-==||| INSANE |||==-
Het viel mij op dat het opvragen van status van devices via JSON inderdaad behoorlijk lang duurde.
Door het zo te doen en de vars vanuit LUA direct door te geven is de delay minimaal.
Als er vervolgens nog geschakeld moet worden, dan krijg je wel nog de delay van de JSON call erbij, maar daar kom je niet omheen.
Dus in mijn gedachte is elke JSON call die je kan vermijden een goed iets
Door het zo te doen en de vars vanuit LUA direct door te geven is de delay minimaal.
Als er vervolgens nog geschakeld moet worden, dan krijg je wel nog de delay van de JSON call erbij, maar daar kom je niet omheen.
Dus in mijn gedachte is elke JSON call die je kan vermijden een goed iets
-==||| INSANE |||==-
Zou het via PHP dan ook sneller gaan om een virtuele schakelaar om te zetten?
Ik heb het nu via een script lopen die wordt aangeroepen middels: script:///volume1/@appstore/domoticz/var/scripts/switch.sh bij de ON-action.
Dit script doet het volgende:
Deze togglet dus de virtuele switch "Wandschakelaar" omdat bij het gebruiken van de "Killswitch" (pulse drukker), de "Killswitch" aan, maar ook meteen weer uit gaat.
Ik wil dit dus het liefst sneller laten gaan. Ik heb het met een Blockly event geprobeerd, maar dat ging ook niet lekker vlot. Als jullie me de tools kunnen geven om dit in een PHP script te vangen zodat ik ermee kan testen, heel graag.
Ik heb in lua het volgende, en dat lijkt alweer iets vlotter / stabieler te gaan dan met het aanroepen van het .sh script:
script_device_wandschakelaar.lua :
Ik ben wel benieuwd hoe ik e.e.a. precies kan meten (Blockly, script, PHP) zodat ik weet welke methode het snelst is.
Dus: hoe meet ik dit precies, en durven jullie de uitdaging aan
?
Ik heb het nu via een script lopen die wordt aangeroepen middels: script:///volume1/@appstore/domoticz/var/scripts/switch.sh bij de ON-action.
Dit script doet het volgende:
code:
1
2
| #!/bin/sh /usr/bin/curl -s --connect-timeout 4 --max-time 5 "http://127.0.0.1:8084/json.htm?type=command¶m=switchlight&idx=1379&switchcmd=Toggle&level=0&" |
Deze togglet dus de virtuele switch "Wandschakelaar" omdat bij het gebruiken van de "Killswitch" (pulse drukker), de "Killswitch" aan, maar ook meteen weer uit gaat.
Ik wil dit dus het liefst sneller laten gaan. Ik heb het met een Blockly event geprobeerd, maar dat ging ook niet lekker vlot. Als jullie me de tools kunnen geven om dit in een PHP script te vangen zodat ik ermee kan testen, heel graag.
Ik heb in lua het volgende, en dat lijkt alweer iets vlotter / stabieler te gaan dan met het aanroepen van het .sh script:
script_device_wandschakelaar.lua :
code:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
| local physical_switch = 'Killswitch (Z)'
local virtual_switch = 'Wandschakelaar'
commandArray = {}
if (devicechanged[physical_switch] == 'On' and otherdevices[virtual_switch] == 'Off') then
commandArray[virtual_switch]='On'
print('Wandschakelaar ON door bedienen Killswitch (Z)')
elseif (devicechanged[physical_switch] == 'On' and otherdevices[virtual_switch] == 'On') then
commandArray[virtual_switch]='Off'
print('Wandschakelaar OFF door bedienen Killswitch (Z)')
end
return commandArray |
Ik ben wel benieuwd hoe ik e.e.a. precies kan meten (Blockly, script, PHP) zodat ik weet welke methode het snelst is.
Dus: hoe meet ik dit precies, en durven jullie de uitdaging aan
?
[ Voor 31% gewijzigd door M.v.Veelen op 23-05-2016 18:40 ]
¯\_(ツ)_/¯
Het lijkt me niet dat je met PHP snellere resultaten gaat behalen dan direct in LUA. Simpelweg vanwege het feit dat de LUA native is voor Domoticz. Dit is er even vanuit gaande dat je middels de 'script_device_bla.lua' te werk gaat.:
Zou het via PHP dan ook sneller gaan om een virtuele schakelaar om te zetten?
Ik heb het nu via een script lopen die wordt aangeroepen middels: script:///volume1/@appstore/domoticz/var/scripts/switch.sh bij de ON-action.
Dit script doet het volgende:
code:
Deze togglet dus de virtuele switch "Wandschakelaar" omdat bij het gebruiken van de "Killswitch" (pulse drukker), de "Killswitch" aan, maar ook meteen weer uit gaat.
Ik wil dit dus het liefst sneller laten gaan. Ik heb het met een Blockly event geprobeerd, maar dat ging ook niet lekker vlot. Als jullie me de tools kunnen geven om dit in een PHP script te vangen zodat ik ermee kan testen, heel graag.
Ik heb in lua het volgende, en dat lijkt alweer iets vlotter / stabieler te gaan dan met het aanroepen van het .sh script:
script_device_wandschakelaar.lua :
code:
local physical_switch = 'Killswitch (Z)' local virtual_switch = 'Wandschakelaar' commandArray = {} if (devicechanged[physical_switch] == 'On' and otherdevices[virtual_switch] == 'Off') then commandArray[virtual_switch]='On' print('Wandschakelaar ON door bedienen Killswitch (Z)') elseif (devicechanged[physical_switch] == 'On' and otherdevices[virtual_switch] == 'On') then commandArray[virtual_switch]='Off' print('Wandschakelaar OFF door bedienen Killswitch (Z)') end return commandArray
Ik ben wel benieuwd hoe ik e.e.a. precies kan meten (Blockly, script, PHP) zodat ik weet welke methode het snelst is.
Dus: hoe meet ik dit precies, en durven jullie de uitdaging aan
Direct een vergelijking tussen LUA en PHP performance zou ik zeggen dat voor veel dingen PHP toch net ff iets sneller is, maar dat is gevoelsmatig, niet getest.
Door jouw post ben ik nog eens even verder naar mijn code gaan kijken om te zien hoe ik de dingen gemeten heb en ik kom tot de conclusie dat mijn metingen niet 'volledig' zijn
Ik meette de tijd die het kost om de LUA os.execute call te doen tot het PHP script alle arrays opgezet had. Dit koste inderdaad 2ms. Echter, LUA heeft ook nog wat tijd nodig om de tables om te zetten naar JSON en vervolgens BASE64 te encoden. Voornamelijk dit encoding blijkt lang te duren (gemeten ~120ms). Dit gaf een totaal van ongeveer 180ms om van LUA naar PHP te gaan. Dit is natuurlijk niet erg prettig
Ik ben dan ook eens verder gaan kijken en testen en heb nu een andere base64 encode functie in gebruik. Nu is het totaal gereduceerd tot 18ms voor het LUA script (waarvan 14ms aan encoding) en 2ms voor PHP, voor een totaal van 20ms. Dit vindt ik wel acceptabel.
In LUA heb ik het gemeten middels de os.clock() functie en in PHP middels de microtime(true) functie.
Met een betere base64 encode functie zou je waarschijnlijk de LUA tijd terug kunnen dringen tot een gelijke 2 - 4 ms.
-==||| INSANE |||==-
:strip_icc():strip_exif()/u/380074/crop5fa41ade46076_cropped.jpeg?f=community)
:strip_icc():strip_exif()/u/206968/325134.jpg?f=community)
:strip_exif()/u/84038/LogoHD.gif?f=community)
Ik ondervindt wat rare uitval problemen met een z-wave device, wat wellicht komt door de wijze van aansturing?
Ik heb een PHILIOTECH DOMOTICAMODULE 2X1,5KW. http://alturl.com/s2cf2
Ik heb dus 2 schakelingen, met 2 aparte scripts.
1: Schakelen tuinverlichting. Dit gaat op basis van device triggered lua script in de eventmanager.
Dit werkt in principe goed, blijft netjes continu branden.
lamp gaat aan als dummy Sunset_Sunrise waar is. Het script wordt getriggerd bij statusverandering SunSet-SunRise of Tuin_Spotjes
2. Aansluiting waterelement, Lua time based.
Hier is dus een probleem, pomp wordt met enige regelmaat uitgeschakeld om vervolgens de minuut erop weer ingeschakeld te worden door het script.
Echter, het "off" commando wordt NIET verstuurd.
Ik heb bedacht:
Ik krijg dus via telegram nooit het bericht "Pomp uitgeschakeld, maar de pomp is dus wel regelmatig "uit".
Script ziet dat pomp uit is, overige condities voldoen ook, dus wordt wordt pomp weer ingeschakeld.
Iemand idee hoe dit kan gebeuren? zelfde z-wave device waar de ene regelmatig "uitvalt" en de andere netjes blijft werken.
als niet werkt: https://www.dropbox.com/s/qoxrnkr90jqlcj1/pomp.png?dl=0
Ik heb een PHILIOTECH DOMOTICAMODULE 2X1,5KW. http://alturl.com/s2cf2
Ik heb dus 2 schakelingen, met 2 aparte scripts.
1: Schakelen tuinverlichting. Dit gaat op basis van device triggered lua script in de eventmanager.
Dit werkt in principe goed, blijft netjes continu branden.
lamp gaat aan als dummy Sunset_Sunrise waar is. Het script wordt getriggerd bij statusverandering SunSet-SunRise of Tuin_Spotjes
2. Aansluiting waterelement, Lua time based.
Hier is dus een probleem, pomp wordt met enige regelmaat uitgeschakeld om vervolgens de minuut erop weer ingeschakeld te worden door het script.
Echter, het "off" commando wordt NIET verstuurd.
Ik heb bedacht:
code:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
| if CurrentUsage > 10 then
PompUsageToHigh = 'Ja';
else
PompUsageToHigh = 'Nee';
end
if ActTemp < 5 then
ToCold = 'Ja';
else
ToCold = 'Nee';
end
if (((time.hour < 23) and (time.hour >= 12)) and -- Alleen aan tussen 12.00 en 23.00
(otherdevices['Hulp_ZijnThuis'] == 'On') and -- Aan als we thuis zijn
(ToCold == 'Nee') and -- Aan als temp hoog genoeg is.
PompState == 'Off' then // blokkeren dat elke minuut pomp ingeschakeld wordt als deze al aan is.
commandArray['Tuin_Pomp'] = 'On'
print ("Pomp ingeschakeld");
commandArray['SendNotification']='Pomp ingeschakeld'
else
--
end
if (((time.hour > 22) or (time.hour < 12)) or -- Uit tussen 23 en 12
(otherdevices['Hulp_ZijnThuis'] == 'Off') or -- Uit we weg zijn
(ToCold == 'Ja') or -- Uit als temp te hoog is.
(PompUsageToHigh == 'Ja')) and -- Uit als verbruik niet klopt (zwaar aanlopen??)
PompState == 'On' then // blokkeren dat elke minuut pomp uitgeschakeld wordt als deze al uit is.
commandArray['Tuin_Pomp'] = 'Off'
print ("Pomp uitgeschakeld");
commandArray['SendNotification']='Pomp uitgeschakeld'
else
--
end |
Ik krijg dus via telegram nooit het bericht "Pomp uitgeschakeld, maar de pomp is dus wel regelmatig "uit".
Script ziet dat pomp uit is, overige condities voldoen ook, dus wordt wordt pomp weer ingeschakeld.
Iemand idee hoe dit kan gebeuren? zelfde z-wave device waar de ene regelmatig "uitvalt" en de andere netjes blijft werken.
als niet werkt: https://www.dropbox.com/s/qoxrnkr90jqlcj1/pomp.png?dl=0
| NL | 2.2k Wp (ZW) | MHI SRC/SRK35ZS-W2 & ME MXZ-2F42+AP20+AP25 | MT E 5.12KWh V151+CT003 V114 | Home Assistant |
:strip_icc():strip_exif()/u/146731/crop562615a0aa64c.jpeg?f=community)
Ik gebruikte dit Lua-script om te zorgen dat ik maar één keer een melding kreeg als er meerdere keren werd aangebeld.
Het script kijkt of de switch geactiveerd wordt en kijkt naar de datum/tijd die vorige keer is weggeschreven in een uservariabele. Als de datum/tijd in die uservar ouder is dan 30s dan wordt er een pushbericht verstuurd dat er iemand voor de deur staat. Ook wordt de datum/tijd in de uservar dan overschreven met de huidige datum/tijd.
Stel dat er een ongeduldig iemand aan de deur staat die binnen 30s meerdere keren op de bel drukt, dan ziet het script bij elke keer indrukken van de bel dat de datum/tijd in de uservar niet ouder is dan 30s en zal dus geen actie ondernemen.
Daar kun jij vast wel wat aan verbouwen om jouw doel te bereiken.
Vergeet dan niet om een var te zetten als je de melding verstuurd hebt, anders blijf je berichten krijgen zolang je Nefit spul eruit ligt, erg leuk als je niet bij je Domoticz kan en je maar berichtjes blijft binnenkrijgen
Die var moet je dan ook nog weer ergens resetten, het zij automatisch, hetzij met de hand. Anders zal je bij een volgende keer dat je Nefit spul eruit ligt geen melding krijgen.Plaatje doet het niet.
Je kunt natuurlijk om te proberen het script even aanpassen naar een lamp in je woonkamer, dan kun je zien of het gedrag daar ook optreedt.
En verder, zou je je script niet simpeler kunnen maken? Je hebt nu allerlei voorwaarden voor aan, en eigenlijk diezelfde voorwaarden (maar dan omgekeerd) voor uit. Dat kan simpeler lijkt mij? Als aan de voorwaarden voor 'aan' niet wordt voldaan, dan is de else-conditie daarvan toch niet meer dan een IF pomp = On THEN commandarray(pomp) == Off ?
Op die manier voorkom je denk ik dat de boel gaat lopen 'klapperen' tussen aan/uit.
offtopic:
'Teveel' is 'too', de 'to' die jij gebruikt staat voor 'naar' ("I'm going to ...")
'Teveel' is 'too', de 'to' die jij gebruikt staat voor 'naar' ("I'm going to ...")
[ Voor 59% gewijzigd door ThinkPad op 24-05-2016 09:54 ]
ah, directe link ook toegevoegd: https://www.dropbox.com/s/qoxrnkr90jqlcj1/pomp.png?dl=0
Inderdaad, kan eenvoudiger / netter. Maar het 'klapperen' wordt niet geforceerd door het script, dat is het "grappige". Het "off" commando wordt immers niet verstuurd.
maar kan niet kwaad om evengoed aan te passen en resultaat te checken.
offtopic:
lol, @ Too/To. Inderdaad. blijft vervelende
lol, @ Too/To. Inderdaad. blijft vervelende
| NL | 2.2k Wp (ZW) | MHI SRC/SRK35ZS-W2 & ME MXZ-2F42+AP20+AP25 | MT E 5.12KWh V151+CT003 V114 | Home Assistant |
Verwijderd
'k Heb de code alweer gewist
Maar was simpel op een pir: if pir = on toggleswitch on.
Een ander nadeel van die lua scripts is dat ze altijd uitgevoerd worden. Bij elke device update dus. Met 209 devices is dat dus serieus frequent. Voordeel van de on/off action is dat je het enkel instelt op de devices waar je meteen reactie op wil (pirs, remotes).
Nadeel ervan is dat het lijkt alsof domoticz eerst al de rest doet en pas op het laatste denkt oei, ik moet nog een script starten.
code:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
| 2016-05-24 08:02:12.319 (RFXCOM) Lighting 2 (pirlivingR) 2016-05-24 08:02:12.552 <b><font color='green'>MOTION: Detected motion in 'pirlivingR'</font></b> 2016-05-24 08:02:12.553 User: Admin initiated a switch command 2016-05-24 08:02:12.554 OpenZWave: Domoticz has send a Switch command! NodeID: 3 (0x03) 2016-05-24 08:02:12.506 (ZWAVE) Thermostat (alexZ) Duration: 2.93 ms 2016-05-24 08:02:12.692 (ZWAVE) Light/Switch (tvled) Duration: 333.14 ms Logic Duration: 330.12 ms Duration: 2.93 ms 2016-05-24 08:02:13.166 Executing script: /volume1/web/secure/cron.sh 2016-05-24 08:02:19.252 (ZWAVE) Temp (kamer) Duration: 2.94 ms 2016-05-24 08:02:25.786 (ZWAVE) Thermostat (tobiZ) Duration: 2.99 ms 2016-05-24 08:02:56.840 (ZWAVE) Thermostat (livingZZ) Duration: 2.93 ms 2016-05-24 08:03:01.085 (ZWAVE) Thermostat (kamerZ) Duration: 2.98 ms |
[ Voor 35% gewijzigd door Verwijderd op 24-05-2016 10:09 ]
Thanks.
Ik was met zoiets aan het stoeien geweest gisteravond. Het "garagedeur staat langer dan 30 minuten open" script lijkt hier namelijk sterk op, maar er is telkens 1 ding waar ik over struikel.
In jouw script staat bijvoorbeeld:
code:
1
| if (devicechanged['Deurbel beneden'] == 'On') then |
Dat kan ik niet herschrijven naar de Easy. Omdat de devicechanged geen On of Off waarde heeft, maar een telkens wisselende temperatuur. En die kan ook zomaar 2 uur lang hetzelfde zijn. Andere switches/utilities/temp.sensoren kan ik hier ook niet voor gebruiken als je begrijpt wat ik bedoel.
Er moet dus alleen gekeken naar wanneer het device voor het laatst "gezien" is. En als dat langer is dan x-minuten, dan een signaal. En dat dan inderdaad afvangen met een variabele die ervoor zorgt dat niet elke minuut m'n Prowl begint te brullen
Dus ik zie zo 1,2,3 niet hoe ik dit moet herschrijven zodat hij alleen naar de "Last seen" luistert zeg maar.
De volgende mogelijkheden heb ik (en ik kan ze dus allemaal niet gebruikern hiervoor lijkt mij):
Nefit | Boiler Status (On / Off)
Nefit | Clock Mode (On / Off /....)
Nefit | CV Druk (x,x Bar)
Nefit | Display Code (System standby / ?)
Nefit | Flow Temperature (xx,x C)
Nefit | Setpoint (xx,x C)
Nefit | Temp buiten (xx,x C)
Nefit | Temp woonkamer (xx,x C)
[ Voor 11% gewijzigd door M.v.Veelen op 24-05-2016 10:22 ]
¯\_(ツ)_/¯
Gezien het schakelen via de JSON API loopt, zie ik niet in hoe je dit sneller zou kunnen doen. Lijkt me ook niet dat jouw eigen code die switch veel sneller zal schakelen dan de mijne? Als dit wel zo is, dan zou ik dat graag zien natuurlijk'k Heb de code alweer gewist
Maar was simpel op een pir: if pir = on toggleswitch on.
Dat is ook iets wat bij mij niet lekker zit en niet 'efficient' aanvoelt. Ik heb zelf nu ongeveer een 250 devices en de overhead van < 20ms vindt ik wel acceptabel vanwege het gemak dat ik krijg door alle data direct beschikbaar te hebben in PHP waar ik niet voor hoef te pollen.
Het lijkt me dat jij in je on/off scripts toch wel vaak de JSON API zal moeten pollen voor status van devices, wat in mijn beleving de grootste delays oplevert.
Mijn C++ kennis is dermate slecht dat ik niet eens een poging heb gedaan om te begrijpen hoe Domoticz de 'events' precies afhandeld, maar ik heb ook het gevoel dat Domoticz er 'even' over doet om acties uit te voeren. Deze delay leek mij het minst als het via een device script ging.
Ik maak in mijn script nu gebruik van de volgende LUA Base64 functie : https://github.com/ErnieE...lob/master/ee5_base64.lua
Dit verkort het encoden van de data voor het naar PHP gaat behoorlijk. Misschien als je hiermee test dat je resultaten krijgt waar je wel vrolijk van wordt ?
-==||| INSANE |||==-
Dan zou je toch een flinke verbetering kunnen realiseren door middels LUA de arrays door te sturen naar PHP ?
Klein voorbeelde uit mijn log :
code:
1
2
3
4
5
| 2016-05-24 11:05:53.733 (IPBrain) Thermostat (Woonkamer - Setpoint) 2016-05-24 11:05:53.876 LUA: LUA: Init => 3.629999999248 ms 2016-05-24 11:05:53.889 LUA: LUA: Encoding => 13.405999998213 ms 2016-05-24 11:05:53.889 LUA: LUA: Total (Pre PHP) => 17.035999997461 ms 2016-05-24 11:05:53.893 LUA: LUA: Total (Post PHP) => 18.11699999962 ms |
De LUA Init is de benodigde tijd voor het inladen van de JSON en BASE64 functies
De LUA Encoding is de benodigde tijd voor het gereed maken van de arrays
De LUA Totals zijn de totalen aan benodigde tijd van het hele script, waar Pre PHP is voor de PHP call en Post PHP na de PHP script call.
Totaal is dus 18.11ms in dit voorbeeld en dan is LUA klaar en heb je alle data die je in LUA hebt dus in PHP arrays zitten.
Dit zorgt ervoor dat je de JSON calls in je script niet meer hoeft te doen in het begin. Waar je nu voor een enkele room op 58ms zit, zou je middels deze methode naar de 20ms gaan, met het voordeel dat je meteen alle data hebt. Het verschil is nog groter met je cron script, daar ga je van 111ms naar 20ms.
Verder zou je dan natuurlijk je PHP code kunnen aanpassen, gezien je geen data meer hoeft op te vragen via de JSON API, die staat tenslotte allemaal in de arrays in PHP.
Wat denk je daar van ?
Edit: Voorbeeldje met schakelen
code:
1
2
3
4
5
6
7
8
9
| 2016-05-24 11:25:52.847 (Aeon Labs ZWAVE Plus Gen5) Light/Switch (Aanbouw - Motion) 2016-05-24 11:25:52.923 User: Admin initiated a switch command 2016-05-24 11:25:52.924 OpenZWave: Domoticz has send a Switch command!, Level: 255, NodeID: 6 (0x06) 2016-05-24 11:25:52.953 LUA: LUA: Init => 3.9220000035129 ms 2016-05-24 11:25:52.966 LUA: LUA: Encoding => 13.999999995576 ms 2016-05-24 11:25:52.966 LUA: LUA: Total (Pre PHP) => 17.921999999089 ms 2016-05-24 11:25:52.970 LUA: LUA: Total (Post PHP) => 19.047000001592 ms 2016-05-24 11:25:52.924 (Aeon Labs ZWAVE Plus Gen5) Light/Switch (Aanbouw - Lampen - Switch) PHP Duration: 56.59 ms |
[ Voor 15% gewijzigd door Intellium op 24-05-2016 11:29 . Reden: Voorbeeld toegevoegd ]
-==||| INSANE |||==-
Verwijderd
Ik ben natuurlijk te vinden voor sneller reageren:
[...]
Wat denk je daar van ?
Zal me wel wat moeite kosten om die manier van programmeren onder de knie te krijgen.
Bij mij zijn het allemaal simpele variabelen die ik kan vergelijken.
Variabelen zijn eenvoudig. Alles wat begint met $S is de status, $ST de update time en $SI de idx. Alles wat begint met $T zijn thermometers, $R setpoints.
Hoe zou bij jou dit er ongeveer uit zien?
PHP:
1
2
3
| if($Sdeurbadkamer=='Closed' && ($Tbadkamer < 22 || $Tbadkamer < $Rbadkamer) && ($Slichtbadkamer1=='On'||$Slichtbadkamer2=='On')) { if($Sbadkamervuur=='Off') {Schakel($SIbadkamervuur,'On','badkamervuur');$Sbadkamervuur='On';} } else if($Tbadkamer > 22 && $Tbadkamer > $Rbadkamer && $Sbadkamervuur=='On') {Schakel($SIbadkamervuur,'Off','badkamervuur');$Sbadkamervuur='Off';} |
Bovenstaande schakelt een elektrisch voor in de badkamer, op voorwaarde dat de deur dicht is en 1 van de lichten aan ligt en de temperatuur lager dan 22 of de temperatuur lager dan een setpoint.
Zou er ongeveer zo uitzien dan::
[...]
Ik ben natuurlijk te vinden voor sneller reageren
Zal me wel wat moeite kosten om die manier van programmeren onder de knie te krijgen.
Bij mij zijn het allemaal simpele variabelen die ik kan vergelijken.
Variabelen zijn eenvoudig. Alles wat begint met $S is de status, $ST de update time en $SI de idx. Alles wat begint met $T zijn thermometers, $R setpoints.
Hoe zou bij jou dit er ongeveer uit zien?
PHP:
Bovenstaande schakelt een elektrisch voor in de badkamer, op voorwaarde dat de deur dicht is en 1 van de lichten aan ligt en de temperatuur lager dan 22 of de temperatuur lager dan een setpoint.
PHP:
1
2
3
| if($this->devicestatus=='Closed' && ($this->otherdevices['badkamer_temp'] < 22 || $this->otherdevices['badkamer_temp'] < $this->otherdevices['badkamer_set']) && ($this->otherdevices['badkamer_licht1']=='On'||$this->otherdevices['badkamer_licht2']=='On')) { if($this->otherdevices['badkamer_vuur']=='Off') {$this->toggleSwitch($this->otherdevices_idx['badkamer_vuur'],'On')} } else if($this->otherdevices['badkamer_temp'] > 22 && $this->otherdevices['badkamer_temp'] > $this->otherdevices['badkamer_set'] && $this->otherdevices['badkamer_vuur']=='On') {$this->toggleSwitch($this->otherdevices_idx['badkamer_vuur'],'Off')} |
Je zou het ook alle logica op IDX kunnen doen, wat ik nu doe. Verder heb ik voor event handling een opzet waarin alle IDX's waar op geacteerd moet worden in een array worden gezet met een callback function
PHP:
1
2
3
4
| $this->events = array( 177 => 'event_test', //Kantoor - Eye - Motion 210 => 'aanbouw_motion' //Aanbouw - Motion ); |
In het main.php script die aangeroepen wordt door de LUA scripts zit dan de volgende check :
PHP:
1
2
3
4
5
| //EVENT / LOGIC Handling if(isset($devidx) && isset($dom->events[$devidx])) { call_user_func(array($dom,$dom->events[$devidx])); } |
Deze controlleerd dus of de IDX van het devicechanged device in de event array voorkomt, zoja, dan wordt de functie aangeroepen om het event af te handelen.
Voor beweging in de aanbouw ziet die functie er dan als volgt uit:
PHP:
1
2
3
4
5
6
7
8
9
10
11
12
13
| function aanbouw_motion() { if($this->devicestatus == "On") //Motion has been detected just now { //Check for LUX level and light switch status if($this->otherdevices[$this->idxToName(212)] < 70 && $this->otherdevices[$this->idxToName(81)] == "Off") { //Conditions met to turn on the light $switch = $this->toggleSwitch(81,"On"); $vars = $this->setVariable("aanbouw_motion_lights",2,"On",2); } } } |
Dat is de huidige opzet waar ik mee aan het spelen ben om te kijken of dat prettig werkt. Opmerkingen hoor ik graag
-==||| INSANE |||==-
Ik heb het volgende lua script nu draaien (afgeleid van de garagedeur-lua):
Ik krijg keurig elke minuut de melding in het log te zien dat alles nog naar wens verloopt (ik laat het tijdelijk even zo), en ik moet nog even kijken of ik een melding krijg als de updates stoppen. Zoals het hier nu staat zou het na 10 minuten (600 sec.) moeten roepen dat er iets mis is en dat blijven roepen totdat de 700sec. verstreken zijn.
Ik ben vanavond pas laat thuis zodat ik dan pas (als ik eraan denk) de thermostaat even van de muur kan halen om te testen. Maar als iemand hier nog fouten in ziet, dan hoor ik dat graag natuurlijk !
Edit: dat heeft natuurlijk geen zin....toch? De Easy server maakt verbinding met de Bosch backend, dus ik moet wachten tot deze de verbinding blokkeert voordat ik weet of het script werkt
Ohja, wat ik wel gek vind: als ik de regel "commandArray['SendNotification']='Nefit Easy alert#No updates recorded for 10 minutes!'" onder de print regel zet (om te testen), dan verschijnt er dit:
"2016-05-24 12:15:00.938 Kodi Notification (192.168.0.100:9777, TTL 5): Nefit Easy alert, No updates recorded for 10 minutes!, Icon /usr/local/domoticz/www//images/logo.png"
Wat dit met Kodi te maken heeft weet ik niet, misschien moet ik daar eerst een <br> voor gebruiken en komt de melding toevallig op dezelfde regel als Kodi, maar dan nog snap ik de "Icon /usr/local/domoticz/www//images/logo.png" niet die erachter wordt geplaatst. Iemand?
code:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
| -- script_time_nefit.lua
t1 = os.time()
s = otherdevices_lastupdate['Nefit | Temp woonkamer']
-- returns a date time like 2013-07-11 17:23:12
year = string.sub(s, 1, 4)
month = string.sub(s, 6, 7)
day = string.sub(s, 9, 10)
hour = string.sub(s, 12, 13)
minutes = string.sub(s, 15, 16)
seconds = string.sub(s, 18, 19)
commandArray = {}
t2 = os.time{year=year, month=month, day=day, hour=hour, min=minutes, sec=seconds}
difference = (os.difftime (t1, t2))
if (otherdevices['Nefit | Temp woonkamer'] and difference > 600 and difference < 700) then
commandArray['SendNotification']='Nefit Easy alert#No updates recorded for 10 minutes!'
else
print ('<b style="color:Blue">Nefit Easy is still up and running........')
end
return commandArray |
Ik krijg keurig elke minuut de melding in het log te zien dat alles nog naar wens verloopt (ik laat het tijdelijk even zo), en ik moet nog even kijken of ik een melding krijg als de updates stoppen. Zoals het hier nu staat zou het na 10 minuten (600 sec.) moeten roepen dat er iets mis is en dat blijven roepen totdat de 700sec. verstreken zijn.
Ik ben vanavond pas laat thuis zodat ik dan pas (als ik eraan denk) de thermostaat even van de muur kan halen om te testen. Maar als iemand hier nog fouten in ziet, dan hoor ik dat graag natuurlijk
!Edit: dat heeft natuurlijk geen zin....toch? De Easy server maakt verbinding met de Bosch backend, dus ik moet wachten tot deze de verbinding blokkeert voordat ik weet of het script werkt
Ohja, wat ik wel gek vind: als ik de regel "commandArray['SendNotification']='Nefit Easy alert#No updates recorded for 10 minutes!'" onder de print regel zet (om te testen), dan verschijnt er dit:
"2016-05-24 12:15:00.938 Kodi Notification (192.168.0.100:9777, TTL 5): Nefit Easy alert, No updates recorded for 10 minutes!, Icon /usr/local/domoticz/www//images/logo.png"
Wat dit met Kodi te maken heeft weet ik niet, misschien moet ik daar eerst een <br> voor gebruiken en komt de melding toevallig op dezelfde regel als Kodi, maar dan nog snap ik de "Icon /usr/local/domoticz/www//images/logo.png" niet die erachter wordt geplaatst. Iemand?
[ Voor 4% gewijzigd door M.v.Veelen op 24-05-2016 12:32 ]
¯\_(ツ)_/¯
Verwijderd
Bedankt voor het meedenken:
[...]
Zou er ongeveer zo uitzien dan:
PHP:
Je zou het ook alle logica op IDX kunnen doen, wat ik nu doe. Verder heb ik voor event handling een opzet waarin alle IDX's waar op geacteerd moet worden in een array worden gezet met een callback function
PHP:
In het main.php script die aangeroepen wordt door de LUA scripts zit dan de volgende check :
PHP:
Deze controlleerd dus of de IDX van het devicechanged device in de event array voorkomt, zoja, dan wordt de functie aangeroepen om het event af te handelen.
Voor beweging in de aanbouw ziet die functie er dan als volgt uit:
PHP:
Dat is de huidige opzet waar ik mee aan het spelen ben om te kijken of dat prettig werkt. Opmerkingen hoor ik graag
Echter,
even de code zoveel mogelijk ingekort kom ik bij:
PHP:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
| #!/usr/bin/php <?php class domoticz { function __construct() {$this->api = "http://127.0.0.1:8084/json.htm";} function toggleSwitch($idx,$state="") { if(!empty($state)) { $key = array_search($idx, $this->otherdevices_idx); $state = ($this->otherdevices[$key] == "Off" ? "On" : "Off"); $switch = file_get_contents($this->api . "?type=command¶m=switchlight&idx=" . $idx . "&switchcmd=" . $state); $switch = json_decode($switch,true); return($switch); } else { $switch = file_get_contents($this->api . "?type=command¶m=switchlight&idx=" . $idx . "&switchcmd=" . $state); $switch = json_decode($switch,true); return($switch); } } } $dom = new domoticz; switch($argv[1]) { case "device": $dom->devicechanged = json_decode(base64_decode($argv[2]),true); $dom->otherdevices = json_decode(base64_decode($argv[3]),true); $dom->otherdevices_lastupdate = json_decode(base64_decode($argv[4]),true); $dom->otherdevices_svalues = json_decode(base64_decode($argv[5]),true); $dom->otherdevices_idx = json_decode(base64_decode($argv[6]),true); $dom->uservariables = json_decode(base64_decode($argv[7]),true); $dom->timeofday = json_decode(base64_decode($argv[8]),true); $dom->devicestatus = $dom->otherdevices[key($dom->devicechanged)]; $devidx = $dom->otherdevices_idx[key($dom->devicechanged)]; break; default: print("Unknown case! (" . $argv[1] . ")\r\n"); break; } if(($dom->otherdevices['pirgarage']=='On'||$dom->otherdevices['poort']=='Open')&&$dom->otherdevices['garage']=='Off'&&$dom->otherdevices['garage_auto']=='On') $dom->toggleSwitch($dom->otherdevices_idx['garage'],'On'); |
Het werkt, licht wordt ingeschakeld.
Echter, na 0,3 sec. Terwijl het met m'n vorige aanpassing na 0,12 sec was.
Dus, ik kan rustig mijn code blijven gebruiken. Grootste winst heb ik vandaag gehaald door het PHP script op te roepen door een script_device.lua script ipv de on/off actions voorheen.
Klinkt alsof je nog de oude base64 encode function in LUA gebruikt (die was tergend langzaam). Gebruik je de ee5_base64.lua file van https://github.com/ErnieE...lob/master/ee5_base64.lua in je device script?:
[...]
Bedankt voor het meedenken
Echter,
even de code zoveel mogelijk ingekort kom ik bij:
PHP:
Het werkt, licht wordt ingeschakeld.
Echter, na 0,3 sec. Terwijl het met m'n vorige aanpassing na 0,12 sec was.
Dus, ik kan rustig mijn code blijven gebruiken. Grootste winst heb ik vandaag gehaald door het PHP script op te roepen door een script_device.lua script ipv de on/off actions voorheen.
-==||| INSANE |||==-
Ik zou hem even anders neerzetten
Kijk naar de mijne :code:
1
2
3
4
5
| -- INIT JSON
JSON = (loadfile '/src/domoticz/scripts/lua/JSON.lua')()
-- INIT BASE64
base64 = loadfile('/src/domoticz/scripts/lua/ee5_base64.lua')() |
-==||| INSANE |||==-
/u/189310/crop571f5b38cbd6b_cropped.png?f=community)
Verwijderd
Genieten van een hypersnel reagerend systeem en daarbij uiteraard af en toe een pintje pakken
Aangezien wij alles overhevelen naar PHP, hebben we daardoor wat overhead. Door de besparingen in ms is het effect van de overhead minder en kunnen wij blij in PHP blijven knutselen zonder te veel delays
PS. en natuurlijk die pintjes pakken
-==||| INSANE |||==-
Nou vooruit dan.
Sinds ik m'n domoticz installatie verplaatst heb van een systeem op SSD naar m'n thuisserver met een trage 5400rpm schijf gaat het allemaal merkbaar langzamer hier.
Mijn minuut cron doet alle uservariables, devices en scenes ophalen en extern weerdata, aanwezigheidsdata via wifi, tado thermostaat data ophalen, data van televisies die mogelijk aan staan ophalen en alle bijbehordende logic binnen 400ms.
Gemeten met time, dus inclusief de tijd dat het duurt voordat mijn Perl scriptje klaar is om iets te gaan doen.
Ik heb nog ergens een socket server scriptje liggen die direct data uit de database pompt. wellicht is die weg leuk om te bewandelen als je de laatste ms eruit wilt persen. Dat LUA vind ik verschrikkelijk namelijk.
Sinds ik m'n domoticz installatie verplaatst heb van een systeem op SSD naar m'n thuisserver met een trage 5400rpm schijf gaat het allemaal merkbaar langzamer hier.
Mijn minuut cron doet alle uservariables, devices en scenes ophalen en extern weerdata, aanwezigheidsdata via wifi, tado thermostaat data ophalen, data van televisies die mogelijk aan staan ophalen en alle bijbehordende logic binnen 400ms.
Gemeten met time, dus inclusief de tijd dat het duurt voordat mijn Perl scriptje klaar is om iets te gaan doen.
Ik heb nog ergens een socket server scriptje liggen die direct data uit de database pompt. wellicht is die weg leuk om te bewandelen als je de laatste ms eruit wilt persen. Dat LUA vind ik verschrikkelijk namelijk.
- knip -
Verwijderd
http://www.ebay.com/itm/1...geName=STRK%3AMEBIDX%3AIT
Top dingetje! Volgens mij 2x zoveel zendvermogen. NB: illegaal
Verwijderd
@Intellium: Wil je even kijken of ik op goede weg ben om jouw code te gebruiken aub?
https://gist.github.com/E...5b1f02ebe91fd7d6035a30640
Kost redelijk wat tijd om alles om te bouwen, maar het schakelen gaat lekker vlot. Gemiddeld 12 msec.
Ik heb de code zover mogelijk geminimaliseerd, elke byte is een byte
En samengevoegd in 1 bestand, dat scheelt ook weer 1 msec
https://gist.github.com/E...5b1f02ebe91fd7d6035a30640
Kost redelijk wat tijd om alles om te bouwen, maar het schakelen gaat lekker vlot. Gemiddeld 12 msec.
Ik heb de code zover mogelijk geminimaliseerd, elke byte is een byte
En samengevoegd in 1 bestand, dat scheelt ook weer 1 msec
[ Voor 6% gewijzigd door Verwijderd op 25-05-2016 10:02 ]
Verwijderd
Ik vind een losse webpagina met de stream prettiger werken dan de meeste apps.
Uiteraard wel een login methode inbouwen zodat de stream niet publiek zichtbaar is
Uiteraard wel een login methode inbouwen zodat de stream niet publiek zichtbaar is
Haha, lekker bezig:
@Intellium: Wil je even kijken of ik op goede weg ben om jouw code te gebruiken aub?
https://gist.github.com/E...5b1f02ebe91fd7d6035a30640
Kost redelijk wat tijd om alles om te bouwen, maar het schakelen gaat lekker vlot. Gemiddeld 12 msec.
Ik heb de code zover mogelijk geminimaliseerd, elke byte is een byte
En samengevoegd in 1 bestand, dat scheelt ook weer 1 msec
Ik hou de mijne nog even wat uitgebreider terwijl ik ermee speel (leest wat makkelijker)
Verder ziet het er wat mij betreft prima uit. Hoe vindt je dat de event afhandeling werkt op deze manier?
[ Voor 0% gewijzigd door Intellium op 25-05-2016 11:26 . Reden: typo ]
-==||| INSANE |||==-
Verwijderd
Het is even aanpassen
Ik was gewoon dat alle statussen in variabelen stonden, en dat elk device waarbij dit nodig was het volledige script uitvoert.
Nu is het per device dat er een functie en dus maar een deeltje uitgevoerd wordt.
Maar als het eindresultaat een sneller systeem is heb ik er het gerust voor over om er een paar dagen mee bezig te zijn.
Ook een aantal van mijn functies moeten omgebouwd worden, zoals voor Denon, Telegram, iOS, updatedevice, en wel nog een hoopje
In ieder geval: DIKKE MERCI!
edit: O ja, ook wel aantal devices te hernoemen. Blijkbaar mag je geen schakelaar, setpoint en thermometer met dezelfde naam hebben. Dan blijft er maar 1 van over
Ik was gewoon dat alle statussen in variabelen stonden, en dat elk device waarbij dit nodig was het volledige script uitvoert.
Nu is het per device dat er een functie en dus maar een deeltje uitgevoerd wordt.
Maar als het eindresultaat een sneller systeem is heb ik er het gerust voor over om er een paar dagen mee bezig te zijn.
Ook een aantal van mijn functies moeten omgebouwd worden, zoals voor Denon, Telegram, iOS, updatedevice, en wel nog een hoopje
In ieder geval: DIKKE MERCI!
edit: O ja, ook wel aantal devices te hernoemen. Blijkbaar mag je geen schakelaar, setpoint en thermometer met dezelfde naam hebben. Dan blijft er maar 1 van over
[ Voor 13% gewijzigd door Verwijderd op 25-05-2016 11:42 ]
Goed om te horen.:
Het is even aanpassen
Ik was gewoon dat alle statussen in variabelen stonden, en dat elk device waarbij dit nodig was het volledige script uitvoert.
Nu is het per device dat er een functie en dus maar een deeltje uitgevoerd wordt.
Maar als het eindresultaat een sneller systeem is heb ik er het gerust voor over om er een paar dagen mee bezig te zijn.
Ook een aantal van mijn functies moeten omgebouwd worden, zoals voor Denon, Telegram, iOS, updatedevice, en wel nog een hoopje
In ieder geval: DIKKE MERCI!
Ik moet zelf ook nog een berg ombouwen (komende vanaf een eigen Domotica systeem in PHP) al mijn scripts en data invoer aanpassen naar Domoticz (IPbrain, Zonnepanelen, etc.)
Telegram heb ik een eigen webservice voor gemaakt intern, misschien dat ik die ook nog even ombouw.
-==||| INSANE |||==-
:strip_icc():strip_exif()/u/154963/crop659be07d13f5a_cropped.jpg?f=community)
:strip_icc():strip_exif()/u/23183/gndm60.jpg?f=community)
Ik heb een Fibaro FGD-211 dimmer die ik wil aansluiten zónder schakelaar. Deze moet alleen bediend worden door Domoticz. Ik kan verder alleen maar schema's vinden met een enkele of een dubbele schakelaar. Iemand die me kan vertellen hoe ik deze zonder een schakelaar precies aan kan sluiten?
¯\_(ツ)_/¯
| NL | 2.2k Wp (ZW) | MHI SRC/SRK35ZS-W2 & ME MXZ-2F42+AP20+AP25 | MT E 5.12KWh V151+CT003 V114 | Home Assistant |
Het is meer dat ik ze eerst wel zag staan en nu niet meer. Ik vraag me af waarom, en daarbij het weerstation van de buren had ik graag toegevoegd tot ik er zelf een heb.
Na een het terug zetten van de database zie ik er ineens weer 1 bij staan...
[ Voor 9% gewijzigd door kromme op 26-05-2016 14:10 ]
Keep it calm...en lek mig de zuk
Zo? Ik heb de zwarte draad zwart/bruin gemaakt omdat het een 2-draads-aansluiting is met een netsnoer + eurostekker.
Dan zou ik de nuldraad die naar de lamp loopt op de N kunnen aansluiten en de fase (in) op N en de schakeldraad op O. Right?
Edit:
zo dus.....
[ Voor 7% gewijzigd door M.v.Veelen op 26-05-2016 14:04 ]
¯\_(ツ)_/¯
Dit topic is gesloten.