[PHP] Wekker in php

[Knopsje]

Hallo iedereen,

Wij hebben een systeem gemaakt waarmee je met je Iphone een ledstrip in de kamer kan bedienen. Dit werkt doordat deze ledstrip op een server aangesloten zit met een chromoflex controller. De Iphone kan de server aansturen met behulp van een php script. Tot zover werkt alles. Wat nu wilden maken is een soort Wake-up light, waardoor de verlichting langzaam aangaat op een vooraf ingestelde tijd.

Het volgende hebben we al geprobeerd:
-Een hele lange while-loop die stopt op het moment dat de gezette wekkertijd wordt bereikt.
-Een hele lange sleep die stopt op het moment dat de gezette wekkertijd wordt bereikt.
-Bij de laatste manier hadden we een cookie geset met hierin de wekkertijd opgeslagen. De pagina werd dan elke minuut gerefreshed en als de wekkertijd overschreden was dan ging de wekker.
Dit werkt allemaal wel als er een korte tijd wordt ingesteld maar helaas niet als het script voor lange tijd wordt uitgevoerd. We hebben ook de max_execution_time in de php.ini al heel hoog gezet. Is er een manier om dit toch te laten werken of is er een hele andere aanpak nodig?
Het enige nadeel van deze manieren is dat de client zijn browser aan moet laten staan, dus het zou nog beter zijn als er een manier is waarbij de client zijn browser gewoon kan sluiten en dat het script dan door blijft lopen op de server.
Iemand die ons op het goede pad kan zetten? Alvast bedankt!

[bakakaizoku]

Wellicht een cronjob aanmaken als oplossing hiervoor.

[Megamind]

Een cronjob maken die elke minuut die cookie checkt?

[Erkens]

Kan je niet een cronjob op de server maken? Dat is handiger dan iedere keer een request doen naar je server.

edit:

[ Voor 5% gewijzigd door Erkens op 03-05-2010 11:38 ]

[Knopsje]

Een cronjob is inderdaad wel een mogelijkheid, maar we willen eigenlijk via de browser (op de site van de server) elke avond een andere tijd kunnen instellen. Zouden we dat op die manier ook met een cronjob kunnen doen?

[bakakaizoku]

Dat is prima te doen, lees je eens in hoe de crontab files in elkaar steken en je kan er zo een webbased admin panel voor maken.

[ItsValium]

cronjob die een scriptje lokaal uitvoert, en een tweede scriptje(pagina) die de wekkertijd ergens wegschrijft waar het cronjob scriptje dan naar kan kijken of het iets of niets moet doen.

[woutertje]

Je zou een script kunnen maken wat in een database de tijd aanpast, en een andere die door een cronjob
wordt aangeroepen die die tijd dan weer uitleest en vergelijkt met de huidige tijd.

Edit: Doh!

[ Voor 3% gewijzigd door woutertje op 03-05-2010 11:48 ]

[base_]

Ja: met cronjob een php script oproepen dat checkt of het al tijd is (tijd opslaan in config file of database)

[Knopsje]

Heel erg bedankt! Daar kunnen we wat mee!
Als het gelukt is dan laten we het weten

[dragontje124]

je kan ook de max execution time in php.ini op 0 zetten dan is er dus geen max execution time

[Mike2k]

dragontje124 schreef op maandag 03 mei 2010 @ 23:08:
je kan ook de max execution time in php.ini op 0 zetten dan is er dus geen max execution time

Dat is volgens mij toch wel een heel smerige oplossing
Kan me ook niet voorstellen dat dat goed is voor het geheugengebruik ?

[dragontje124]

Mike2k schreef op maandag 03 mei 2010 @ 23:11:
[...]


Dat is volgens mij toch wel een heel smerige oplossing
Kan me ook niet voorstellen dat dat goed is voor het geheugengebruik ?

haha tuurlijk is dat zo, maar ik denk ik meld het even, misschien handig voor de volgende keer .
edit:
maar een cronjob gebruiken hiervoor is niet erg precies, als je 'm bijvoorbeeld elke 10 minuten laat controleren kan je er al 9 minuten naast zitten, of je moet 'm bijvoorbeeld elke minuut of elke seconde laten controleren, maar dan kan je net zo goed een php scriptje op de achtergrond laten draaien (je kan PHP scripts ook op de achtergrond laten draaien door deze op te starten via de php executable), dat lijkt me hier een goeie oplossing
dat kan door bijv in Linux dit commando te draaien met behulp van een ander PHP script:
exec ("/usr/bin/php hierhetpadnaarjouwwekkerscript.php >/dev/null &");
en dat script dan gewoon laten loopen

[ Voor 50% gewijzigd door dragontje124 op 03-05-2010 23:21 ]

[Erkens]

dragontje124 schreef op maandag 03 mei 2010 @ 23:14:
maar een cronjob gebruiken hiervoor is niet erg precies, als je 'm bijvoorbeeld elke 10 minuten laat controleren kan je er al 9 minuten naast zitten, of je moet 'm bijvoorbeeld elke minuut of elke seconde laten controleren,

Wat is er mis met een cronjob elke minuut? Dat is handiger dan dat je nog een extra proces draait op je server, die crondaemon draait toch. Overigens kan je cron idd niet op de seconde exact zijn werk laten doen, maar dat lijkt me voor de toepassing van een wekker ook niet super belangrijk, wil je het wel op de seconde nauwkeurig dan zit er niks anders op dan zelf een background process te schrijven (al dan niet mbv php)

[dragontje124]

Erkens schreef op maandag 03 mei 2010 @ 23:23:
[...]

Wat is er mis met een cronjob elke minuut? Dat is handiger dan dat je nog een extra proces draait op je server, die crondaemon draait toch. Overigens kan je cron idd niet op de seconde exact zijn werk laten doen, maar dat lijkt me voor de toepassing van een wekker ook niet super belangrijk, wil je het wel op de seconde nauwkeurig dan zit er niks anders op dan zelf een background process te schrijven (al dan niet mbv php)

tjah het maakt in principe niet zoveel uit, maar ik vind persoonlijk een background process netter.

[tweakerbee]

Je kunt je cronjob ook zo aanmaken dat hij precies op het goede moment draait? Is helemaal efficient.

En als je meerdere wekkers wilt, kun je meerdere cronjobs maken. Kan hij gelijk standaard elke dag draaien. Eenmalige jobs kunnen zichzelf eenvoudig weer uitschakelen door de cronjob te verwijderen.

[dragontje124]

tweakerbee schreef op maandag 03 mei 2010 @ 23:31:
Je kunt je cronjob ook zo aanmaken dat hij precies op het goede moment draait? Is helemaal efficient.

En als je meerdere wekkers wilt, kun je meerdere cronjobs maken. Kan hij gelijk standaard elke dag draaien. Eenmalige jobs kunnen zichzelf eenvoudig weer uitschakelen door de cronjob te verwijderen.

ok jij wint

[Erkens]

tweakerbee schreef op maandag 03 mei 2010 @ 23:31:
Je kunt je cronjob ook zo aanmaken dat hij precies op het goede moment draait? Is helemaal efficient.

En als je meerdere wekkers wilt, kun je meerdere cronjobs maken. Kan hij gelijk standaard elke dag draaien. Eenmalige jobs kunnen zichzelf eenvoudig weer uitschakelen door de cronjob te verwijderen.

Kan natuurlijk ook, alleen zelf wordt ik er niet happy van als een "random" (web)applicatie steeds wijzigingen zit te maken in mijn cron tabellen.

dragontje124 schreef op maandag 03 mei 2010 @ 23:25:
tjah het maakt in principe niet zoveel uit, maar ik vind persoonlijk een background process netter.

Waarom is dat netter? Resources in gebruik nemen terwijl je 59,999 sec per minuut niks doet? Waarbij je ook nog eens moet monitoren of het process nog actief is waarbij je met cron al direct voorzien bent van een (simpele) notificatie als er iets mis gaat.

[Manuel]

Dan kan je gewoon je gegevens in sleep mode zetten? Dan kost het je systeem ook nog eens niets. Ik gebruik voor dit klusje System_Daemon van Kevin van Zonneveld (ook PEAR package). Werkt perfect en heeft je heel veel pain in the arse weggehaald.

PHP:

System_Daemon::iterate(60); //60S

* Verder vallen de resources wel mee die zo'n PHP daemon dan in beslag neemt, als ik het hier zie kom ik uit op 5MB RAM en die daemon updatet mijn gegevens om de 10 seconden en kijkt of er een nieuw bericht of iets anders is binnengekomen voor me. Dus resources als argument gebruiken lijkt me een non-argument.

Alleen moet ik zeggen voor zoiets als ik dit had ik zelf ook een cronjob gekozen, omdat je de data niet realtime nodig gaat hebben. Je hoeft geen continue handelingen verrichten maar om de zoveel tijd checken of het al tijd is.

[ Voor 48% gewijzigd door Manuel op 04-05-2010 00:36 . Reden: *additional ]

[Erkens]

Manuel schreef op dinsdag 04 mei 2010 @ 00:29:
* Verder vallen de resources wel mee die zo'n PHP daemon dan in beslag neemt, als ik het hier zie kom ik uit op 5MB RAM en die daemon updatet mijn gegevens om de 10 seconden en kijkt of er een nieuw bericht of iets anders is binnengekomen voor me. Dus resources als argument gebruiken lijkt me een non-argument.

non-argument? Vind ik niet, ik heb het (zoals gezegt) niet alleen over de resources als geheugen en cpu, maar ook van de systeembeheerder die er verantwoordelijk voor is om alle services "up" te houden, je moet dus een check in je monitoring tool hebben om te kijken of er niet iets mis is, wellicht voor het hiet gegeven voorbeeld (wekker) niet super belangrijk, maar wel nuttig als je op tijd wakker wilt worden

[Verwijderd]

Ik zou voor een background proces gaan i.p.v. een cronjob, kwestie van voorkeur.
Kan je geen chasing pattern instellen via je chromoflex software? Of zit daar geen software bij? In dat geval zou je ook een hele lange stap (enkele uren ) kunnen maken op intensiteit 0 en daarna kortere chases met kleine toenames van intensiteit...
Als je hier geen software voor hebt zou ik er een klein programmaatje voor schrijven die dat doet. Laat hem dan iedere zoveel tijd de instellingen van het PHP script krijgen (bijv. ieder half uur even checken of er andere instellingen zijn opgeslagen).
Een daemon is heel makkelijk te schrijven doordat je met het & teken na een commando een proces in de background kunt laten gaan.

[PeterSelie]

Verwijderd schreef op dinsdag 04 mei 2010 @ 08:18:

[...]

Hoe zou je dat (zoals Erkens al aangeeft) dan willen afvangen wanneer de applicatie crashed of niet draait (om welke reden dan ook)? Wil je dan een ander background proces draaien die de applicatie weer start wanneer deze stopt met reageren, of richt je voor die check dan wel weer een cron in?

[Verwijderd]

SoaDmaggot schreef op dinsdag 04 mei 2010 @ 08:27:
Hoe zou je dat (zoals Erkens al aangeeft) dan willen afvangen wanneer de applicatie crashed of niet draait (om welke reden dan ook)? Wil je dan een ander background proces draaien die de applicatie weer start wanneer deze stopt met reageren, of richt je voor die check dan wel weer een cron in?

Ja, dat de app niet draait ga je geen rekening mee houden, of wou je dan de applicatie ook laten controleren of ie wel in de cron list staat, en zoniet zichzelf toevoegen, en dan controleren of cron wel draait?
Het crashen van de applicatie kan je simpelweg voorkomen door goede foutafvang. Apache e.d. gebruiken een extra monitoring daemon die controleert of de child processen nog draaien, maar het gaat hier om een enkele taak zonder verdere rare fratsen met andere applicaties die worden aangeroepen.
Desnoods combineer je de beiden: start de applicatie via een cronjob eens per uur, laat die als aller eerste controleren of het proces nu niet twee keer draait, als dat wel zo is meteen stoppen (of de andere killen, maar dan kan je weer race conditions krijgen enzo) en anders normale functie.

[ Voor 13% gewijzigd door Verwijderd op 04-05-2010 08:43 ]

[Manuel]

Erkens schreef op dinsdag 04 mei 2010 @ 07:58:
[...]

non-argument? Vind ik niet, ik heb het (zoals gezegt) niet alleen over de resources als geheugen en cpu, maar ook van de systeembeheerder die er verantwoordelijk voor is om alle services "up" te houden, je moet dus een check in je monitoring tool hebben om te kijken of er niet iets mis is, wellicht voor het hiet gegeven voorbeeld (wekker) niet super belangrijk, maar wel nuttig als je op tijd wakker wilt worden

Heb je gelijk in, maar zoals je zegt hebben ze daar gelukkig tools voor zoals Monit, werkt simpel doet zijn ding en kan je heel veel mee. Een wekker in PHP is niet een al te goed voorbeeld maar zal officieel realtime moeten lopen wil je op de seconde nauwkeurig wakker worden. (Door een cronjob gaat dat niet, of je moet het al perfect kunnen afstellen). Maar als de TS monit heeft draaien en hij wil eens wat met zijn Wekker testen, probeer dan beide methodes.

Verwijderd schreef op dinsdag 04 mei 2010 @ 08:41:
[...]

Ja, dat de app niet draait ga je geen rekening mee houden, of wou je dan de applicatie ook laten controleren of ie wel in de cron list staat, en zoniet zichzelf toevoegen, en dan controleren of cron wel draait?
Het crashen van de applicatie kan je simpelweg voorkomen door goede foutafvang. Apache e.d. gebruiken een extra monitoring daemon die controleert of de child processen nog draaien, maar het gaat hier om een enkele taak zonder verdere rare fratsen met andere applicaties die worden aangeroepen.
Desnoods combineer je de beiden: start de applicatie via een cronjob eens per uur, laat die als aller eerste controleren of het proces nu niet twee keer draait, als dat wel zo is meteen stoppen (of de andere killen, maar dan kan je weer race conditions krijgen enzo) en anders normale functie.

Met ^^