Hulp nodig bij het kiezen van de juiste programmeer taal.

[SnowDude]

Om even helemaal vanaf het begin te beginnen, ik heb momenteel een Arduino draaien die mijn aquarium aanstuurt. Nu wil ik deze gaan vervangen door een Raspberry Pi.

De software heeft meerdere functionaliteiten:

• Instellingen en monitoring via een web interface.
• Pollen van temperatuur en andere sensoren.
• Aansturen van relais op basis van de sensoren.
• Aansturen van relais op basis van tijd en user input.
• Aansturen van i2c pwm outputs voor de LED verlichting op basis van tijd en user input.
• Logging naar een database(je)

Mijn huidige oplossing doet rest calls naar een php scriptje en stuurt MQTT info naar mijn Domoticz home automation systeem. Voor de config stuur ik via MQTT een paar simpele commando's naar de Arduino toe

Op de raspberry zou ik alles het liefste in 1 applicatie gieten, zodat ik ook alles in 1 taal kan schrijven. Nu gebruik ik C++ op de Arduino, PHP op de webserver en Javascript op de webpages.

Aangezien ik voornamelijk ervaring heb met de arduino en de arduino code altijd in een simpele loop draait, ben ik op zoek hoe ik dit het beste kan aanvliegen op de Pi.

Ik kan alles opdelen in 3 threads:

Data acquisitie (Het pollen van de sensoren, relatief heel veel wachttijd)
Core prosessing (Verwerken van de sensor data, reageren op de timers, output naar database en hardware outputs)
Web frontend

De uitdaging van multi-threaded oplossingen waar ik altijd tegen aanloop is het sharen van data tussen de threads zonder veel globale variabelen te gebruiken.

Een simpele oplossing is is om 3 separate oplossingen te schrijven die via tmpfs data sharen, en voor het uitlezen van de sensoren is dit waarschijnlijk de beste oplossing.

Ik heb zitten kijken naar een Node.JS oplossing, en de web integratie lijkt me super makkelijk, maar ik betwijfel of de eventloop niet te beperkt is voor het control deel en aansturen van de hardware.

Maar er zullen vast efficiëntere oplossingen zijn en dan vooral voor de koppeling naar de web interface, en daar heb ik jullie hulp een beetje bij nodig. Ik hoef geen voorgekauwde oplossing te hebben maar ik heb een duwtje nodig in de richting waar ik naar zou kunnen kijken.

Ik heb voornamelijk veel ervaring met C op de arduino, maar tegenwoordig doe ik ook steeds meer in Javascript en Python. Nu ben ik wel van mening dat alle programmeer talen op elkaar lijken dus over stappen naar een Java oplossing of iets dergelijks is niet een onoverkomelijk probleem

[Bigs]

Ik zou gewoon een taal kiezen die je beheerst en die voor alle drie de toepassingen geschikt is. Dat kan zowel PHP en JavaScript zijn op basis van je post.

Schrijf drie losse scriptjes die commando’s uitwisselen via MQTT en data opslaan in een gedeelde SQL database. Dan gebruik je concepten die je al kent en hoef je je verder niet te verdiepen in multithreaded programmeren.

[ Voor 5% gewijzigd door Bigs op 29-10-2017 14:06 ]

[farlane]

Het lijkt er op dat je een stap terug wilt gaan doen : waarom zou je de IO (het lezen van sensoren etc) willen gaan doen met een RPi en Node, terwijl de Arduino voor dat werk gemaakt is?

[SnowDude]

Ik wil geen stap terug doen maar de gehele oplossing juist wat versimpelen. Ik heb van een vriend van me het verzoek gekregen om eens iets vergelijkbaars te ontwikkelen voor zijn aquarium en ik wil bij hem gewoon 1 device neerzetten.

Mijn probleem nu is is dat de enige real time data info die ik krijg via MQTT op het netwerk wordt gepushed. Dit heeft als gevolg dat als ik de webinterface open ik eerst moet wachten op een nieuwe temperatuur meting voor ik data op de client krijg. Je kan met MQTT niet pollen.

Een ander probleem met MQTT in mijn implementatie is beveiliging, MQTT ondersteund wel SSL, maar dan moet je op elke client die connect de certificaten eerst handmatig moet installeren. Dat is niet handig als je ergens met een browser wil inloggen op het device. MQTT is handig om data van sensoren naar een centraal punt te sturen maar niet om data naar meerdere web clients te sturen.

Een ander probleem dat ik nu te afhankelijk ben van mijn netwerk. Alle data wordt nu via mijn netwerk gelogd, als mijn netwerk wegvalt dan valt mijn logging ook weg.

Ik wil naar 1 device waar ik alle hardware op aansluit (en voor de A/D converters is de kans groot dat ik daar een Arduino Nano voor gebruik als serieel USB device) maar daarop alle storage en logging. Er hoeft dan op mijn router maar 1 poort open voor een https verbinding, en authenticatie doe ik dan wel op applicatie level.

Uiteraard is mijn persoonlijke doel om er ook wat van te leren.

[farlane]

SnowDude schreef op zondag 29 oktober 2017 @ 14:48:
Ik wil geen stap terug doen maar de gehele oplossing juist wat versimpelen.

Uiteraard is mijn persoonlijke doel om er ook wat van te leren.

Prima, im just saying.

Mijn probleem nu is is dat de enige real time data info die ik krijg via MQTT op het netwerk wordt gepushed. Dit heeft als gevolg dat als ik de webinterface open ik eerst moet wachten op een nieuwe temperatuur meting voor ik data op de client krijg. Je kan met MQTT niet pollen.

Kijk eens naar persistent sessions

[Tip]
Als je toch leren wilt, misschien zou je ook eens naar een BeagleBoneBlack (BBB) kunnen kijken. Deze draait ook Linux, maar heeft (veel) meer mogelijkheden qua I/O. Als je het heel gek wilt maken kun je zelfs zijn twee ingebakken PRU's (32 bit microcontrollers) gebruiken voor de realtime taken die je hebt (het binnenharken van de sensoren bv),

[BarôZZa]

Volgens mij is Node.js prima geschikt voor wat je wil doen. Aangezien je steeds meer met Javascript doet lijkt het me ideaal om op te pakken en van te leren.

[Hydra]

@SnowDude je hebt verschillende 'HATs' voor je Raspberry. M.i. is het een volkomen logische keuze om gewoon een enkele device te pakken om het simpel te houden. De raspberry is prima in staat om dingen als temp logging e.d. te regelen en heeft gewoon een voordeel dat je CPU power genoeg hebt om te doen wat je wil.

[farlane]

Hydra schreef op maandag 30 oktober 2017 @ 08:52:
M.i. is het een volkomen logische keuze om gewoon een enkele device te pakken om het simpel te houden. De raspberry is prima in staat om dingen als temp logging e.d. te regelen en heeft gewoon een voordeel dat je CPU power genoeg hebt om te doen wat je wil.

Het is inderdaad helemaal niet verkeerd om het op 1 device te houden, maar de RPi is (voor deze use case) wmb niet de beste keuze.
Daarnaast worden een aantal nadelen van MQTT genoemd die ik niet herken : dit protocol is juist bedacht voor een setup zoals de TS nu heeft.

[SnowDude]

farlane schreef op woensdag 1 november 2017 @ 22:06:
[...]


Het is inderdaad helemaal niet verkeerd om het op 1 device te houden, maar de RPi is (voor deze use case) wmb niet de beste keuze.
Daarnaast worden een aantal nadelen van MQTT genoemd die ik niet herken : dit protocol is juist bedacht voor een setup zoals de TS nu heeft.

Nee MQTT is bedacht om sensor data naar een centrale plek te versturen. Voor een volledig versleutelde en geauthenticeerde verbinding naar een willekeurige webdevice ben ik nog geen oplossing tegen gekomen waar je niet een vooraf gedefinieerde sleutel handmatig in de browser moet installeren. Tevens is het pushen van settings via lange strings nou juist niet het sterkste punt van de arduino, dat kost gewoon veel geheugen, ik moet al overstappen naar een arduino mega omdat het geheugen gebruik en de code te groot werden voor een Arduino Uno.

Het is niet of een Raspberry of een Arduino, het is of een Raspberry en een Arduino of een Raspberry.

Waarom zou ik een Raspberry Pi neer zetten met een broker en database die via MQTT praat met een Arduino, en dan moet je ook nog eens meer poorten open zetten op de firewall. Het is leuk dat het kan en het werkt voor mij ook nog wel, maar dat is overkill voor als ik een kopie van het systeem bij een leek neer zet.

De hardware aansluiten op de Pi is een fluitje van een cent, ik had in een half uur een printplaat ontworpen om alle hardware aan te sluiten op de Pi zelf. Dat is een PCB van 6 euro, dat scheelt zo'n 60 euro met een originele Arduino Mega met een ethernet interface. En ook daar zit nog een interface board op.

[WK100]

SnowDude schreef op zondag 29 oktober 2017 @ 14:48:
Je kan met MQTT niet pollen.

Je kunt toch als device een SUBSCRIBE packet met als topic 'poll_(devicename)' sturen? Dan reageer je op zo'n bericht door een PUBLISH te doen met de gegevens die je op dat moment op dat apparaatje hebt.

[SnowDude]

WK100 schreef op woensdag 1 november 2017 @ 23:40:
[...]

Je kunt toch als device een SUBSCRIBE packet met als topic 'poll_(devicename)' sturen? Dan reageer je op zo'n bericht door een PUBLISH te doen met de gegevens die je op dat moment op dat apparaatje hebt.

Nee, je moet met het sensordevice eerst subscriben op een "poll topic" daarna zal je met een client, in dit geval mijn browser een publish moeten doen van een poll commando op dat topic waarna de sensor device dat bericht binnen krijgt en dan reageert door data te versturen op.

Als je alleen een subscribe doet op een topic, komt dat alleen aan op de broker, het sensor device ziet dat niet zonder dat je een bericht publisht, maar dan moet het device ook een subscribe doen.

MQTT is altijd 1 richting verkeer en je stuurt altijd een broadcast naar een topic, je kan met QOS wel wat dingen afvangen maar je hebt nooit een handshake tussen twee devices op protocol level. Dat moet je zelf afvangen in laag 7

[WK100]

SnowDude schreef op donderdag 2 november 2017 @ 00:28:
[...]

Nee, je moet met het sensordevice eerst subscriben op een "poll topic" daarna zal je met een client, in dit geval mijn browser een publish moeten doen van een poll commando op dat topic waarna de sensor device dat bericht binnen krijgt en dan reageert door data te versturen op.

Als je alleen een subscribe doet op een topic, komt dat alleen aan op de broker, het sensor device ziet dat niet zonder dat je een bericht publisht, maar dan moet het device ook een subscribe doen.

MQTT is altijd 1 richting verkeer en je stuurt altijd een broadcast naar een topic, je kan met QOS wel wat dingen afvangen maar je hebt nooit een handshake tussen twee devices op protocol level. Dat moet je zelf afvangen in laag 7

Dat is precies wat ik voorstel. Jouw device (apparaatje) meldt zich aan voor een bepaald topic en reageert met een publish als iemand een bericht met dat topic ('poll_deviceX') publisht naar de broker. In dit geval kan dat jouw browser zijn of server.

Ik heb het polling gedeelte weggelaten uit de post want ik ging ervan uit dat dat vanzelfsprekend was.

Het komt er op neer dat ik het probleem niet zie met polling. Wat houdt je tegen?

[ Voor 4% gewijzigd door WK100 op 02-11-2017 07:48 ]

[Hydra]

farlane schreef op woensdag 1 november 2017 @ 22:06:
Het is inderdaad helemaal niet verkeerd om het op 1 device te houden, maar de RPi is (voor deze use case) wmb niet de beste keuze.

Met een sensor hat erop is het een prima keuze.

[farlane]

SnowDude schreef op woensdag 1 november 2017 @ 22:30:
Nee MQTT is bedacht om sensor data naar een centrale plek te versturen.

Het publish-subscribe model is bedoeld om informatie van een node naar 1 of meer andere nodes te krijgen, dat lijkt sterk op de situatie die je hebt.
Of het ideaal is om sensoren die je lokaal zou kunnen binnenhengelen omdat je ze alleen lokaal nodig hebt is een tweede, vandaar dat ik zeg dat dat niet een gek idee is.

"Voor een volledig versleutelde en geauthenticeerde verbinding naar een willekeurige webdevice..."

Waarom zou ik een Raspberry Pi neer zetten met een broker en database die via MQTT praat met een Arduino, en dan moet je ook nog eens meer poorten open zetten op de firewall.

Ik snap denk ik je setup (of je beoogde setup) niet helemaal: ik had begrepen dat je alles lokaal wil doen (met een RPi) om problemen met netwerken etc te voorkomen maar ik begrijp dat het toch ook nog ergens in een "cloud" terecht moet komen?

De hardware aansluiten op de Pi is een fluitje van een cent, ik had in een half uur een printplaat ontworpen om alle hardware aan te sluiten op de Pi zelf. Dat is een PCB van 6 euro, dat scheelt zo'n 60 euro met een originele Arduino Mega met een ethernet interface. En ook daar zit nog een interface board op.

Misschien lijkt het alsof ik een Arduino aanhanger ben of zo, maar het tegendeel is waar : ze kunnen te weinig en zijn te duur dus daarvan hoef je me niet te overtuigen.
Ik vroeg me alleen af of je misschien het systeem afschreef op basis van de uitdagingen met MQTT, terwijl dat volgens mij niet nodig is. Een persistent session, is dat niet een mogelijke oplossing voor je probleem?

Met een sensor hat erop is het een prima keuze.

Het is een prima keuze, maar imho zijn er betere.

[smekkos]

Volgens mij heb je toch gewoon genoeg aan alleen een pi? Het ligt eraan hoeveel sensors je hebt om uit te lezen. Ook heeft een pi volgens mij standaard maar 1 pwm output. Dus daar moet je ook even op letten.

Aangezien die pi toch relatief sterk is kun je ook gewoon een heel framework zoals django of meteor draaien.
heb je alles onder 1 dak.

[SnowDude]

farlane schreef op donderdag 2 november 2017 @ 11:18:
[...]

Het publish-subscribe model is bedoeld om informatie van een node naar 1 of meer andere nodes te krijgen, dat lijkt sterk op de situatie die je hebt.
Of het ideaal is om sensoren die je lokaal zou kunnen binnenhengelen omdat je ze alleen lokaal nodig hebt is een tweede, vandaar dat ik zeg dat dat niet een gek idee is.


[...]


[...]

Ik snap denk ik je setup (of je beoogde setup) niet helemaal: ik had begrepen dat je alles lokaal wil doen (met een RPi) om problemen met netwerken etc te voorkomen maar ik begrijp dat het toch ook nog ergens in een "cloud" terecht moet komen?


[...]

Misschien lijkt het alsof ik een Arduino aanhanger ben of zo, maar het tegendeel is waar : ze kunnen te weinig en zijn te duur dus daarvan hoef je me niet te overtuigen.
Ik vroeg me alleen af of je misschien het systeem afschreef op basis van de uitdagingen met MQTT, terwijl dat volgens mij niet nodig is. Een persistent session, is dat niet een mogelijke oplossing voor je probleem?


[...]

Het is een prima keuze, maar imho zijn er betere.

Mijn huidige oplossing is hangt een beetje vaag in elkaar, maar ik gebruik nu MQTT voornamelijk omdat ik er even mee wilde spelen, ik ben voor een klant van me betrokken geweest bij een project met een aantal miljoen MQTT messages per seconde.

Basically gebruik ik MQTT nu zo:

Voor logging en integratie met Domoticz:

Arduino PUB Meetwaardes om de 30 seconden.
Domoticz SUB Meetwaardes voor logging


Voor controlle en settings via een webbrowser, de pages staan gehost op de Pi:

Arduino PUB Meetwaardes om de 30 seconden.
Browser met Jscript MQTT client SUB Meetwaardes voor display
Browser PUB Req for settings
Arduino SUB Settings
Arduino PUB Actual settings
Browser SUB Actual settings
Browser PUB Nieuw settings
Arduino SUB Nieuw settings

Dit werkt goed, maar het heeft een aantal nadelen:

Momenteel heb ik al een stuk of 100 verschillende settings. Het parsen en verwerken van al die (json) data is niet het sterkste punt van de Arduino, de string functies vreten relatief veel geheugen en storage.

In mijn huige implementaties, kan het 30 seconden duren voor ik de huidige meetwaardes zie, maar dat ik wel op te lossen in het protocol

Mijn grootste probleem is nu dat als ik de webpages open op een willekeurige public browser dan heb ik geen secure verbinding en zou iedereen mijn settings kunnen sniffen en aanpassen. Dit is momenteel niet mogelijk doordat mqtt geblocked is op mijn firewall.

Het laatste probleem is op te lossen door MQTT te terminaten op de webserver en dan via gewone https ajax calls de data te verversen in de browser. En daar was ik ook mee begonnen en toen realiseerde ik me dat het hele MQTT deel een beetje overbodig was als ik de hardware rechtstreeks aansloot op die zelfde Pi. En daarom kwam ik hier.

smekkos schreef op donderdag 2 november 2017 @ 11:43:
Volgens mij heb je toch gewoon genoeg aan alleen een pi? Het ligt eraan hoeveel sensors je hebt om uit te lezen. Ook heeft een pi volgens mij standaard maar 1 pwm output. Dus daar moet je ook even op letten.

Aangezien die pi toch relatief sterk is kun je ook gewoon een heel framework zoals django of meteor draaien.
heb je alles onder 1 dak.

De hardware is redelijk simpel:

Een aantal switch inputs voor float sensors
Een aantal DS18B20 temp sensoren aan gesloten via de 1-Wire bus en uitgelezen via de standaard Linux driver (nog makkelijker dan op de Arduino)

En een aantal I2C devices:
Een BMP280 barometer
4 kanaals A/D converter voor een PH meter
16 kanaals 12-bits PWM outputs en daarvan kan je er in theorie 62 devices op 1 I2C bus hangen
I2C to paralel converter voor 8 of 16 relais outputs

[ Voor 13% gewijzigd door SnowDude op 02-11-2017 15:20 ]