• Momenteel zijn we bezig met een onderzoek naar het gebruik en de ervaringen met grindmatten. Wil jij ons helpen? Meld je aan of registreer dan vlug en reageer op dit topic

Teleruptoren - Raspberry Pi

Lid geworden
4 mrt 2012
Berichten
120
Waarderingsscore
0
Punten
16
Hey,





Voor onze bouw hebben we gekozen voor het teleruptor-systeem om onze elektriciteit aan te sturen, de upgrade naar domotica was voor ons iets te kostelijk.



Nu zit ik met de gedachte te spelen om een 'Raspberry Pi' te gebruiken om daarmee enkele domotica-features te hebben. De vraag is natuurlijk of dit überhaubt wel mogelijk is, ik heb nog niet veel informatie op het internet gevonden jammer genoeg.. :)



Ik weet dat zo een Raspberry Pi elektrische inputs & outputs kan ontvangen/versturen (via PGIO), maar kan ik deze dan op een of andere manier aansluiten op m'n elektriciteitskast?



Zelf ken ik (nog) bitter weinig over elektriciteit, en ik heb nog nergens een duidelijk schema gevonden over hoe de schakelingen van teleruptoren nu effectief gebeuren, en waar er welke spanning heerst:

- teleruptoren ontvangen 24V(?) signaal via een SVV kabel

- wat is de output van zo een teleruptor? Is dat direct het voltage voor de lampen, of is dat ook nog zo een 24V signaal?



Qua setup dacht ik eraan om die Raspberry Pi dus op de nodige teleruptoren als INPUT aan te sluiten. Zo zit ik nog aan het laag-voltage, en kan ik denk ik alles doen?

-> als er een signaal van een drukknop komt, ontvangt de RPi deze ook gezien die draden tegen elkaar zitten in de input van de teleruptor

-> als er een signaal moet verstuurd worden, kan dit op dezelfde manier. Ik vermoed dat het niet erg is dat die drukknop dan eigenlijk ook een signaal terug krijgt?



Extra vragen:

- Wat met de keuring? zou dit kwaad kunnen als ik later op zo een manier ingrijp in de elektriciteitskast?

- Wat met de verzekering dan, stel dat het kot afbrandt.. :)



Bedankt!



Sven
 
Sven Vlieghe;1892698 wrote:
... is een RPi werkelijk zo 'buggy'? Op zich maakt het niet ZO veel uit moest die eens crashen, dan zouden die extra features/besturing via smartphone gewoon niet meer werken maar m'n normale inputs (drukknoppen) wel.



Dit is het belangrijkste uitgangspunt, goed dat je er zelf mee afkomt.



Teleruptoren of een "toestel met relais en ingangen" zorgen voor de werking, De Rpi, smartphone, home server,... hangen errond, zorgen voor extra mogelijkheden of visualisatie maar hinderen de werking niet.



Nu dat "toestel met relais en ingangen" heeft potentieel belangrijke voordelen tov teleruptoren.

Daarom kan je misschien best eens kijken wat er zoal te koop is: PLC, Arduino, Pic, enzovoort. De lijst is eindeloos.

Deze kunnen dan gekoppeld worden aan je Rpi, smartphone, home server, net zoals je dat zou doen met je teleruptoren.
 
Om te beginnen als leek zou ik ook eerder Arduino aanraden. Eens je project klaar is, en je al wat code/elektronica ervaring hebt opgedaan, kan je het eventueel porten naar RasPi om de hogere level functies zoals netwerk en/of radio te implementeren.

Je zal inderdaad een bordje moeten maken tussen je processor gedeelte (arduino et al.) en je 24V circuit. hierin zal je inderdaad best optocouplers gebruiken, al dan niet in bidirectionle opstelling, afhankelijk van of je wil uitlezen en de status bijhouden van alles. Om je 24V te schakelen kan je dan best MOSFETs gebruiken. Die dissiperen enkel stroom bij het schakelen.



Kleine tip voor uw zoekwerk en uitgewerkte projecten als dit: hackaday.com



Kleine vraag trouwens: zijn uw schakelaars in daisy-chain gezet bij zo'n systeem, m.a.w. zendt elke schakelaar een digitale code uit? of ligt er van elke schakelaar een kabel naar uw teleruptorkast (ster netwerk)?
 
hoe ik het gedaan heb:



alle knoppen op 12V, alle te schakelen punten op eltako modules



in plaats van rijgklemmen zelf een printje getekend met 4 rijen steekklemmen van phoenix contact



op onderste rij komen alle knoppen toe

op de bovenste rij komen alle stuuringangen van de eltako modules

zowel bovenste als onderste rijen zijn 1 op 1 ontdubbeld in de middelste 2 rijen waartussen dan de verbindingen zitten die een bepaalde knop aan een bepaald relais verbinden.



standaard installatie tot nu toe, werkt direct na plaatsing, zonder programmeren en failsafe (scoort dus hoge WAF)

maar nu komt het



op de achterkant van het printje staan level-converters naar 5V en I/O expanders op i2C bus zodat eender welke controller die i2c kan sturen kan dienen om de boel te automatiseren.



dit zou kunnen een raspberry pi zijn met bvb op linux een webserver die een vloerplan toont met alle schakelaars zodat alles remote te bedienen is.



het vraagt wat basis elektronica kennis en wat praktische ervaring om het in de kast te krijgen maar het concept is poepsimpel



en nu de truuk mit die doif

mijn IO-printjes waren goedkoper dan het equivalent in din-rail steekklemmen en nemen veel minder kastruimte in

(maar daarvoor heb ik wel hier en daar wat aan materiaal kunnen geraken)
 
dinges;1893298 wrote:
hoe ik het gedaan heb:



alle knoppen op 12V, alle te schakelen punten op eltako modules



in plaats van rijgklemmen zelf een printje getekend met 4 rijen steekklemmen van phoenix contact



op onderste rij komen alle knoppen toe

op de bovenste rij komen alle stuuringangen van de eltako modules

zowel bovenste als onderste rijen zijn 1 op 1 ontdubbeld in de middelste 2 rijen waartussen dan de verbindingen zitten die een bepaalde knop aan een bepaald relais verbinden.



standaard installatie tot nu toe, werkt direct na plaatsing, zonder programmeren en failsafe (scoort dus hoge WAF)

maar nu komt het



op de achterkant van het printje staan level-converters naar 5V en I/O expanders op i2C bus zodat eender welke controller die i2c kan sturen kan dienen om de boel te automatiseren.



dit zou kunnen een raspberry pi zijn met bvb op linux een webserver die een vloerplan toont met alle schakelaars zodat alles remote te bedienen is.



het vraagt wat basis elektronica kennis en wat praktische ervaring om het in de kast te krijgen maar het concept is poepsimpel



en nu de truuk mit die doif

mijn IO-printjes waren goedkoper dan het equivalent in din-rail steekklemmen en nemen veel minder kastruimte in

(maar daarvoor heb ik wel hier en daar wat aan materiaal kunnen geraken)



Als je wil mag je er een foto aan toevoegen, dat maakt het eens zo duidelijk.
 
dinges;1893298 wrote:
...en I/O expanders op i2C bus zodat eender welke controller die i2c kan sturen kan dienen om de boel te automatiseren.



dit zou kunnen een raspberry pi zijn met bvb op linux een webserver die een vloerplan toont met alle schakelaars zodat alles remote te bedienen is.



Als de i2c communicatie naar uw expanders zo is opgevat dat ze als slave enkel de veranderingen krijgen doorgestuurd, gaat dit goed werken.
 
De i2c i/O extenders zijn inderdaad slave op de bus maar ze hebben een interruptlijn zodat het indrukken van een knop ook de controller (i2c master) wakker schudt.

Zo moet door de master ook niet constant gepolld worden of er iets op de ingangen is veranderd.

In het stuurprogramma wordt dan zogezegd in een lijst met instellingen gecheckt of er nog iets moet gebeuren wat nog niet door de vaste bedrading naar de teleruptoren gedaan wordt.



Maar op de lijnen die enkel uitgang zijn is er geen teruglezing voorzien; al kan dit voor een beperkt aantal wel door bij te bedraden naar enkele spare ingangen.



Praktisch heb ik de volgende toepassingen in gedachte:



- schakelklok voor rolluiken bij zons-op/ondergang

- een aantal niet gebruikte knoppen in mijn schakelaars een sfeer laten instellen

- koppeling tussen knoppen in huis en bvb de tuinverlichting die nu op een andere schakelkast in het tuinhuis zit

- remote bediening van alle knoppen via webinterface, maar dat is meer om mee te showen



allemaal extra's dus die geen €€€ installatie verantwoorden maar wel een 'hobbyprojectje'



ik zoek nog eens een foto

maar momenteel is er dus nog niks van controller voorzien, enkel de io printjes in de bedrading van drie aparte schakelkasten
 
Galenbo;1893574 wrote:
dinges;1893298 wrote:
...en I/O expanders op i2C bus zodat eender welke controller die i2c kan sturen kan dienen om de boel te automatiseren.



dit zou kunnen een raspberry pi zijn met bvb op linux een webserver die een vloerplan toont met alle schakelaars zodat alles remote te bedienen is.



Als de i2c communicatie naar uw expanders zo is opgevat dat ze als slave enkel de veranderingen krijgen doorgestuurd, gaat dit goed werken.



I2C is eigenlijk bedoeld voor on-board gebruik. Velen verkrachten deze standaard en sturen het over kabels (wat nooit de bedoeling was vroeger). (zelfs bij philips, zij die het uitgevonden hebben). DDC bij monitors en hdmi is ook een verkrachtte I2C bus met alle miserie en ellende van compatibiliteitsissues vandien...



voor robustheid en storingsongevoeligheid kan je beter iets a la CAN-bus of RS485 gebruiken.
 
Kris77;1893913 wrote:
Galenbo;1893574 wrote:
dinges;1893298 wrote:
...en I/O expanders op i2C bus zodat eender welke controller die i2c kan sturen kan dienen om de boel te automatiseren.



dit zou kunnen een raspberry pi zijn met bvb op linux een webserver die een vloerplan toont met alle schakelaars zodat alles remote te bedienen is.



Als de i2c communicatie naar uw expanders zo is opgevat dat ze als slave enkel de veranderingen krijgen doorgestuurd, gaat dit goed werken.



I2C is eigenlijk bedoeld voor on-board gebruik. Velen verkrachten deze standaard en sturen het over kabels (wat nooit de bedoeling was vroeger). (zelfs bij philips, zij die het uitgevonden hebben). DDC bij monitors en hdmi is ook een verkrachtte I2C bus met alle miserie en ellende van compatibiliteitsissues vandien...



voor robustheid en storingsongevoeligheid kan je beter iets a la CAN-bus of RS485 gebruiken.

Ik wilde het niet zeggen, maar gelijk heb je Kris77.
 
De IO ic's staan op printjes naast elkaar en het is de bedoeling dat de controller ook op zijn printje in de rij komt te staan.



Waar verschillende controllers in verschillende kasten moeten interfacen is er ftp voorzien met ethernet in gedachte.



Het wordt dus enkel lokaal, board to board gebruikt.



Ik ben er trouwens nog niet uit of ik de intelligentie van de sturing wel in de controllers in de kasten steek of gewoon ergens op een server of een naske een programma draai.

In het laatste geval kunnen de controllers in de kast dan redelijk domme i2C naar ethernet interfaces zijn.
 
Ja, de sturing van automatisering op een of ander operating system draaien: doen.
 
mijne sarcasm-o-meter is juist ontploft



pas op ik programmeer ook liefst low level (ben dan ook een hardware man)

maar als je high level dingen wilt doen (zoals bvb webinterface) is dat toch in no time opgezet met een embedded linux



maar alle, voor de liefhebbers

http://shop.tuxgraphics.org/

heeft een tcp netwerkstack voor avr

enkel jammer dat het niet in assembly geschreven is :cool:
 
Kris77;1893913 wrote:
Galenbo;1893574 wrote:
dinges;1893298 wrote:
...en I/O expanders op i2C bus zodat eender welke controller die i2c kan sturen kan dienen om de boel te automatiseren.



dit zou kunnen een raspberry pi zijn met bvb op linux een webserver die een vloerplan toont met alle schakelaars zodat alles remote te bedienen is.



Als de i2c communicatie naar uw expanders zo is opgevat dat ze als slave enkel de veranderingen krijgen doorgestuurd, gaat dit goed werken.



I2C is eigenlijk bedoeld voor on-board gebruik. Velen verkrachten deze standaard en sturen het over kabels (wat nooit de bedoeling was vroeger). (zelfs bij philips, zij die het uitgevonden hebben). DDC bij monitors en hdmi is ook een verkrachtte I2C bus met alle miserie en ellende van compatibiliteitsissues vandien...



voor robustheid en storingsongevoeligheid kan je beter iets a la CAN-bus of RS485 gebruiken.



nja, laat ons het houden op 'beperkte afstanden' want over 10cm koperbaantjes of 10cm draad is just 't zelfde hoor. Verder dan 20a 30cm zou ik er inderdaad niet mee lopen. Ik ga niet effe ingewikkeld doen en speciaal 1 board maken als ik er 2 nodig heb.
 
Vooral het opkrimpen van al die adereindhulsekes is tof.

Zeker als ge nu en dan uw open bakse met hulsekes eens de grond inkegelt
 
Ik ben het niet eens met Arduino > echte computer. Het hangt er van af (zoals altijd...) wat je wil doen. Ik wil zelf de domotica als pure bolt-on bovenop een 'gewoon' systeem hebben, dus als de domotica controller wegvalt, is alles nog met de hand te bedienen. Ik ga juist voor een volledige PC (waarschijnlijk met zwave because renovatie) omdat die veel functionaliteit heeft waar je bij een Arduino weken mee bezig bent, of waar de processor gewoon niet krachtig genoeg voor is. Juist als je achtergrond in software is, ben je beter af met off the shelf hardware en de rest in software doen.



Als je vanaf alle schakelaars, lichtpunten etc draden naar 1 plek trekt en daar een 'volledig' domotica-gestuurd systeem maakt, ja dan zou ik zeggen neem een microcontroller, da's een ander verhaal.



Nu, rPi ga ik zelf niet doen omdat de sd-card het na relatief korte tijd gaat begeven als hij 24/24 aan staat (ja je kan je boot partitie r/o mounten, en logging uitzetten etc., maar je gaat dan nog na 2 jaar je read/write cycles opgebruikt hebben). Zoek maar eens op internet hoeveel mensen er domotica op rPi bouwen en corrupted SD cards hebben. Nog los van hardware issues. Een simpele low-power volledige PC voor dit soort toepassingen kost maar 200 euro of zo tegenwoordig.



Is het voor renovatie of nieuwbouw?
 
joske_vermeulen;1894450 wrote:
Ik wil zelf de domotica als pure bolt-on bovenop een 'gewoon' systeem hebben, dus als de domotica controller wegvalt, is alles nog met de hand te bedienen.

Juist, ja. Met welke componenten heb je gekozen om het 'gewoon' systeem te maken?



joske_vermeulen;1894450 wrote:
Als je vanaf alle schakelaars, lichtpunten etc draden naar 1 plek trekt en daar een 'volledig' domotica-gestuurd systeem maakt, ja dan zou ik zeggen neem een microcontroller, da's een ander verhaal.

Of een microcontroller met behuizing rond en merklogo erop, aka Loxone, PLC, KNX,...



Er is ook een combinatie mogelijk. 3 tot 5 modules die verspreid in je huis staan, en waar telkens alle kabels (schakelaars, lampen, sensors) van die zone naartoe komen.



De 5 modules zijn met elkaar verbonden via Canbus, RS485, Routed Ethernet IP of iets anders, delen eenzelfde datafield met elkaar, en sturen de veranderingen naar elkaar door. Dat heeft zelfs een naam: Multi-ster op bus.



Hier kunnen dan enkele onkritische toestellen bij opgezet worden. Zoals een server (reeds aanwezig voor andere zaken) die foutboodschappen en gegevens logt (als hij daar tijd en goesting voor heeft), een Android tablet vast aan de muur met visualisatie of om wat parameters in te stellen (als hij aanstaat, en niet toevallig aan t updaten is)
 
Galenbo;1894456 wrote:
Juist, ja. Met welke componenten heb je gekozen om het 'gewoon' systeem te maken?



Mechanische schakelaars en 2,5 carré draad ;) Met 'gewoon' bedoelde ik 'gelijk 50 jaar geleden'.



joske_vermeulen;1894450 wrote:
Als je vanaf alle schakelaars, lichtpunten etc draden naar 1 plek trekt en daar een 'volledig' domotica-gestuurd systeem maakt, ja dan zou ik zeggen neem een microcontroller, da's een ander verhaal.

Galenbo;1894456 wrote:
Of een microcontroller met behuizing rond en merklogo erop, aka Loxone, PLC, KNX,...



Ja, die dingen schaarde ik ook onder 'microcontroller' - ik bedoelde 'geintegreerde, industrial strength systemen', zij het heel basis zoals een PLC of wat meer gespecialiseerd a la Loxone.
 
joske_vermeulen;1894477 wrote:
Galenbo;1894456 wrote:
Juist, ja. Met welke componenten heb je gekozen om het 'gewoon' systeem te maken?



Mechanische schakelaars en 2,5 carré draad ;) Met 'gewoon' bedoelde ik 'gelijk 50 jaar geleden'.



Welke componenten heb je gekozen die voor de basiswerking zorgen? (het gedeelte dat blijft werken terwijl uw pc/tablet/andere reboot/update/stilligt/andere zaken belangrijker vindt)
 
Er is nog een tussenniveau waar hier niet over gesproken wordt.

Met een OS bedoel voor gebruik op desktop pc's en consoorten kun je je inderdaad verwachten aan het soort grappen waar Galenbo op wijst.



Maar eigenlijk wil je een embedded (linux) systeem waar je enkel de kernel modules en systeemsoftware inbouwt die je nodig hebt.

Zoals praktisch iedere modem of router de dag van vandaag op linux draait met bijna enkel de netwerkfunctionaliteit.



Zie de opkomst van de arm en powerpc architectuur de laatste jaren.

We komen in de tijd dat overal een grafisch display of een netwerkinterface wordt bij gelapt, niet omdat de applicatie dit vraagt maar omdat het eenvoudig en relatief goedkoop kan en omdat het verkoopt om te zeggen dat het spel bediendbaar is via een app op uwe whatever-phone.

Sterker nog, omdat de technologie zo alomtegenwoordig wordt zal dat zelfs uitzaaien naar de industriële toepassingen.



Maar ik geef toe,

mis ook de tijd waar met slimme code uitzonderlijke dingen op een bepaalde hardware konden gedaan worden.

... in tegenstelling tot nu waarbij soms enorme rekenkracht verloren gaat in de vele abstractie-lagen en bijkomstigheden om uiteindelijk nog steeds niet meer dan wat tekstkarakters naar een online forum te sturen.
 
Blijf op de hoogte. Schrijf je in voor onze nieuwsbrief.
Bovenaan