De caravan die nét iets slimmer moest worden

[RSV31]

De Eriba Rockabilly die nét iets slimmer moest worden 

Na het topic over mijn buitenkeuken leek het me tijd om ook dit project maar eens vast te leggen. De buitenkeuken begon ooit met de vraag of ik niet gewoon ergens een pizzaoven in kon zetten. Bij de caravan ging het ongeveer hetzelfde. We hebben een Eriba Touring 530 Rockabilly caravan. Jaren geleden heb ik e.e.a. van E-Trailer ingebouwd, maar dat werkte beperkt. Dat kon anders en dat liep uiteraard weer volledig uit de hand.



Het idee achter E-Trailer is op zichzelf leuk. Je plaatst een aantal draadloze modules, opent een app en kunt onder andere de waterstand en gasvoorraad bekijken. In de praktijk irriteerde ik me echter steeds meer aan de (altijd lege) knoopcellen, verbindingsproblemen en de zeer beperkte mogelijkheden om het systeem zelf uit te breiden. Als een sensor soms wel en soms niet wordt gevonden, ben ik er vrij snel klaar mee. Zeker wanneer in een caravan op veel plaatsen gewoon bekabeling aanwezig is of relatief eenvoudig kan worden aangelegd.  Mijn conclusie was dus vrij eenvoudig: dit kan beter, stabieler en vooral uitgebreider.

Ontwerp

Voordat ik componenten ging bestellen, heb ik eerst bepaald wat voor systeem het moest worden. De belangrijkste eis was dat alle essentiële functies lokaal blijven werken. Een alarm, droogloopbeveiliging of waarschuwing voor de mover mag niet afhankelijk zijn van internet, een cloudbroker, Homey of een app op mijn telefoon. Als een verbinding wegvalt, mag hooguit de melding op afstand ontbreken. De caravan zelf moet gewoon blijven functioneren.

Daarnaast wilde ik geen verzameling losse apparaten bouwen die allemaal hun eigen voeding, protocol en eigenaardigheden hebben. Het moest een modulair systeem worden met één centrale controller, lokale slaves en een vaste dataverbinding door de caravan. Nieuwe sensoren en functies moesten later toegevoegd kunnen worden zonder de complete installatie opnieuw te bouwen.

De installatie is daarom in drie functionele lagen verdeeld. De eerste laag bevat alles wat lokaal en zelfstandig moet blijven werken, zoals beveiligingen, relaislogica en alarmen. De tweede laag verzorgt de communicatie, waaronder Modbus, MQTT, wifi en 4G. De derde laag is het comfortgedeelte met de Nextion-schermen, bediening op afstand en eventuele toekomstige logging. Een storing in laag twee of drie mag nooit betekenen dat laag één ermee ophoudt.

Ook gewicht en plaatsing speelden mee. Het totale extra gewicht van de hardware blijft beperkt tot een paar kilogram, maar alles wat laag kan zitten plaats ik liever laag. Onder in de hangkast, achter de gaskachel, was nog behoorlijk wat ongebruikte ruimte. Die ruimte wordt niet heet en de bestaande elektrische infrastructuur zit er al in de buurt, waaronder het groepenkastje en de omvormer. Dat maakte dit een logische plek voor de centrale besturing, voedingen en aansluitingen.

 





Tot slot moest het systeem onderhoudbaar en uitbreidbaar blijven. Dus geen onverklaarbare draadbundel met overal losse verbindingen, maar vaste kleurcodering, afgeschermde kabel, degelijke aansluitklemmen, zekeringen en onderdelen die ook later nog bereikbaar en vervangbaar zijn.

Infrastructuur

De eerste echte bouwstap was daarom niet het aansluiten van een sensor, maar het aanleggen van de infrastructuur. De ruggengraat is Modbus RTU over RS485. De bus loopt als een lineaire daisy chain van de centrale Master langs de verschillende slaves. Aan beide fysieke uiteinden zit terminatie en de afscherming is alleen aan de Masterzijde geaard.



Voor de backbone gebruik ik afgeschermde LAPP LiYCY(TP) twisted-pairkabel. De communicatie draait bewust op 9600 baud met 8N1. Voor de beperkte hoeveelheid data is dat meer dan snel genoeg. In een caravan met relais, voedingen, een mover, lange kabeltrajecten en uiteindelijk ook een 4G-modem heb ik liever extra storingsmarge dan een theoretisch hoge snelheid waar ik niets aan heb. Naast de datalijn is een centrale voedingslijn aangelegd. De bestaande Schaudt-installatie levert 12 volt.

Daarachter zit een DC-UPS met LiFePO4-cellen, gevolgd door een Mean Well DIN-railconverter van 12 volt naar 5 volt voor de controllers, displays en sensoren. De centrale elektronica blijft daardoor ook zo’n 40 minuten werken wanneer de 230 volt wegvalt. Dit is met name belangrijk voor alarmfuncties.



Daarnaast is er nog een 230V-naar-12V-DIN-railvoeding van Mean Well. Deze is aangesloten op een nog vrije groep die af fabriek al in de caravan zat. Alle voedingen zijn beveiligd tegen kortsluiting en overbelasting en hier en daar zit ook een zekering voor diverse gebruikers om geen fikkie te krijgen 😉

De keuze voor een vaste bus en voedingslijn kost aan het begin wat meer werk, maar betaalt zich bij iedere uitbreiding terug. Een nieuwe slave heeft in de basis alleen voeding, massa en de twee RS485-draden nodig. Er hoeft dus niet voor iedere nieuwe sensor opnieuw een compleet los systeem door de caravan te worden getrokken.

Toen de plaats van de componenten en de kabelroutes duidelijk waren, ben ik begonnen met de verschillende 3D-geprinte behuizingen, montageplaten en beugels. In een caravan is vrijwel geen wand recht en zit er altijd precies een leiding, rand, kastscharnier of stuk bestaande bekabeling waar een standaard doos zou moeten komen.  Daarom is een flink deel op maat ontworpen. Niet alleen de zichtbare behuizingen voor de displays, maar ook houders voor pcb's, sensoren en modules. Ook trekontlasting en de mogelijkheid om een onderdeel later te vervangen zijn meegenomen. De caravan hobbelt nu eenmaal achter de auto aan en hoewel de impact op de hardware minimaal is, heb ik geen zin in etterende connecties.



Dus waar nodig heb ik Dupont/JST-XH-connectoren met uv-lijm vastgezet, zodat deze niet kunnen lostrillen, maar eventueel wel los te maken zijn zonder schade.

Mega Master als centrale regelaar

Met de infrastructuur op zijn plaats kon de centrale besturing worden opgebouwd. Hiervoor gebruik ik een Arduino Mega 2560. Niet omdat een Mega de modernste controller is, maar omdat hij voor dit project een prettige combinatie biedt van veel in- en uitgangen en met name meerdere hardwarematige seriële poorten en voorspelbaar lokaal gedrag. Daarbij is het inmiddels een dinosaurus onder de controllers met een proven track record, talloze libraries en volgeschreven forums.

De Master leest de Modbus-slaves uit, bedient het centrale Nextion-scherm, schakelt onder andere boiler en wifi-installatie, verwerkt het fietsalarm en de GPS-data, bewaakt de mover en vormt uiteindelijk ook het knooppunt voor de MQTT-communicatie. De lokale beveiligingen blijven daarbij leidend. Het scherm en de communicatiekanalen geven opdrachten en tonen informatie, maar bepalen niet of een kritische beveiliging wel of niet functioneert.

De slaves worden op vaste intervallen gepolld. Gas en verlichting hoeven bijvoorbeeld niet tientallen keren per seconde te worden uitgelezen en een watertank verandert al helemaal niet veel per seconde, laat staan op videosnelheid. Door alleen te communiceren wanneer het zinvol is, blijft de bus rustig en is er voldoende tijd voor lokale taken op iedere controller. Ondanks dat heb ik een testopstelling met RS485 gemaakt en die onwijs mishandeld met een ground loop, zeer twijfelachtige bekabeling en slechte contacten, maar wat ik ook deed, RS485 is zeer robuust gebleken!

Gasmeting: de E-Trailer-sensor openmaken

De eerste echte sensoruitbreiding was de gasmeting. E-Trailer gebruikt hiervoor een private-labeluitvoering van een Mopeka-sensor. De sensor zelf is technisch prima, dus het zou zonde zijn om een goed werkend meetprincipe te vervangen. Het probleem zat vooral in het gesloten ecosysteem eromheen. Een Mopeka-sensor meet met ultrasoon geluid vanaf de onderzijde van de gasfles. De gegevens worden via Bluetooth Low Energy uitgezonden.





In theorie zou een ESP32 die BLE-berichten dus moeten kunnen ontvangen. In de praktijk was het bij de E-Trailer-versie niet zo eenvoudig. Het benodigde MAC-adres wordt niet netjes beschikbaar gemaakt en de gebruikelijke methoden om de juiste sensor te vinden of rechtstreeks te koppelen leverden niets bruikbaars op. Uiteindelijk heb ik de sensor geopend om de benodigde gegevens fysiek te kunnen achterhalen. Dat doe je natuurlijk liever niet met een onderdeel dat op zichzelf gewoon functioneert, maar zonder identificatie van de juiste sensor kon ik de uitgezonden BLE-data niet vinden/ontvangen.

Na veel zoeken, testen en ook behoorlijk wat hulp van AI bleek er voor deze specifieke combinatie eigenlijk maar één oplossing aantoonbaar te werken: een ESP32 met ESPHome, een BLE-sniffer en een YAML-configuratie voor het Mopeka-protocol. Dat detail is belangrijk. De ESP32 draait hier niet op een zelfgeschreven Arduino-sketch. De bewezen oplossing werkt juist binnen ESPHome met de bijbehorende YAML-configuratie. De 3V-knoopcel heb ik uit de sensor gehaald en nu hangt de sensor aan de 12V-voeding en wordt hij via een buckconverter naar 3V gevoed.

De ESP32 ontvangt de BLE-advertenties van de sensor, haalt daar onder andere het gasniveau uit en stuurt de bruikbare gegevens via een seriële verbinding naar een tweede Arduino Mega. Die Mega is de Gas-slave op de Modbus-daisy-chain. De Gas-slave zet gaspercentage, meetafstand, onlinestatus en de leeftijd van de laatste meting in registers die door de Master kunnen worden uitgelezen. De keuze voor een tweede Mega lijkt voor alleen een gaspercentage misschien wat ruim (mild uitgedrukt ). Dat was echter bewust. De ESP32 is nodig voor BLE en ESPHome, terwijl de Mega zorgt voor de stabiele seriële koppeling, de Modbus-communicatie en voldoende ruimte voor lokale uitbreidingen. Later zijn op diezelfde slave ook de leveler, het aparte Nextion-scherm en een deel van de movergerelateerde logica terechtgekomen. De architectuur was dus vanaf het begin ruimer opgezet dan alleen één gassensor.

Als de ESP32 of de Mopeka tijdelijk geen nieuwe meting levert, blijft de Gas-slave gewoon bereikbaar. De rest van de functies op die Mega draait door en de Master kan aan de ouderdom van de laatste meting zien dat de gaswaarde niet meer actueel is.  

Andere manieren om met een Arduino het gasniveau te meten bestaan uiteraard. Er zijn bijvoorbeeld industriële afstands-, druk- en weegoplossingen. Voor deze toepassing worden dat echter al snel hele dure sensoren, terwijl de bestaande ultrasone Mopeka in principe prima meet. De uitdaging was dus niet de meting zelf, maar het ontsluiten van data van een afgeschermde private-label sensor.

Drinkwatertank

Na de gasmeting volgde de drinkwatertank. Hiervoor wordt een QDY30A-niveausensor gebruikt. De gemeten waarde wordt op een Nano Every omgerekend naar de werkelijke waterhoogte en vervolgens naar een percentage. De kalibratie is gebaseerd op het bruikbare meetbereik van de echte tank en niet simpelweg op een theoretische nul en honderd procent uit een datasheet.

 

Omdat dit de drinkwaterinstallatie is, heb ik voor alle delen die met het water in aanraking komen bewust RVS en drinkwatergeschikte materialen gebruikt. Een sensorwaarde op een mooi scherm is leuk, maar niet wanneer daarvoor materiaal in de tank wordt toegepast dat daar eigenlijk niet thuishoort.

De Nano Every vormt een eigen slave “WATER” op Modbus. De meting gebeurt lokaal en de Master hoeft alleen het berekende percentage op te vragen. Daardoor blijft ook dit deel overzichtelijk en kan de kalibratie later worden aangepast zonder dat de complete Master-sketch op de schop moet.

Optische volmelding in de toiletcassette

Daarna kwam de toiletcassette. Dat lijkt een eenvoudige volmelding, totdat je rekening houdt met het feit dat die cassette mobiel moet blijven. Die moet uit de caravan kunnen worden gehaald, geleegd en grondig schoongemaakt. Op steeds meer campings kan dat tegenwoordig bovendien in een automatische reinigingsmachine. Een vaste sensoropstelling in de caravan die afhankelijk is van een exact gepositioneerd los onderdeel is dan niet ideaal.

Mijn eerste idee was om mee te liften op de bestaande infrastructuur en met een inductieve schakelaar de aanwezige niveaumelding uit te lezen. Ook heb ik geprobeerd om met een kleine schakeling de status van de bestaande led af te vangen. Beide bleken in de praktijk zeer onbetrouwbaar. Het resultaat was wisselvallig voor iets dat juist simpel en betrouwbaar moet zijn.

 

Daarom heb ik uiteindelijk een optische vloeistofdetectie in de toiletcassette zelf gemonteerd. Daarmee wordt rechtstreeks vastgesteld wanneer het niveau de gekozen hoogte bereikt. Het grote voordeel was dat de sensor aan de bovenzijde kon worden geplaatst. De doorvoer zit daardoor niet in een wand waar continu vloeistofdruk op staat. Dat lijkt een klein detail, maar voor mij was het juist een belangrijke voorwaarde. Een doorvoer onder vloeistofniveau afdichten met een O-ring kan vandaag prima dicht zijn. Na jaren dienstdoen, temperatuurwisselingen en veroudering gaat zo'n O-ring geheid een keer lekken. En dan heb je natuurlijk feest in je caravan. Daar heb ik geen zin in 😉 en heb gezeik in de caravan. LETTERLIJK Aan de bovenzijde is de afdichting veel minder kritisch en blijft de cassette normaal uitneembaar en reinigbaar.

 De optische melding wordt door dezelfde waterslave verwerkt. De Master ontvangt bij één poll dus zowel het drinkwaterpercentage als de status van de toiletcassette. Bij een volle cassette verschijnt een waarschuwing op het centrale scherm.

Het centrale bedieningspaneel

Toen gas, drinkwater en toilet als losse functies werkten, ben ik het centrale Nextion-touchscreen gaan testen. Dat toont de belangrijkste waarden en biedt bediening voor onder andere verlichting, boiler, wifi en fietsalarm. De Arduino blijft de werkelijke toestand bepalen. Het scherm is dus geen tweede brein met eigen veiligheidslogica, maar uitsluitend bediening en weergave.

De boiler wordt via een relais geschakeld (de voeding van de boiler is 230V/AC). De vlotterschakelaar zit daarnaast fysiek in serie met de relaisspoel. Daardoor kan de boiler ook bij een softwarefout niet worden ingeschakeld wanneer er onvoldoende water aanwezig is. De software controleert dezelfde toestand en toont een waarschuwing, maar de uiteindelijke droogloopbeveiliging is bewust (ook) hardwarematig uitgevoerd.




Het scherm zorgde uiteraard voor de nodige avondvulling. In een eerdere versie werd het bij iedere minimale verandering van één procent in gas- of waterniveau wakker. Nadat dat was opgelost ontstond een veel vreemder probleem. De aanraakknoppen bleven in het donker gewoon werken, maar het display werd niet zichtbaar. Je kon dus blind de boiler inschakelen en het relais horen klikken, terwijl het scherm zwart bleef.

Na verschillende pogingen met touch-events in Nextion Editor, pakketdetectie en dimcommando's bleek opnieuw dat een Nextion soms precies doet wat je hem opdraagt, maar niet noodzakelijk wat je bedoelt. De huidige versie gebruikt een eigen touch-wakeupmechanisme met een HMI-variabele en werkt inmiddels betrouwbaar.

Bij normaal gebruik staat het scherm eerst volledig helder. Na vijf seconden zonder bediening dimt het naar 25 procent en tien seconden later gaat de achtergrondverlichting naar nul. Die tussenstap stond eerst op 50 procent, maar dat was in een donkere caravan nog steeds ongeveer bouwlampniveau.

Automatische verlichting

In dezelfde bouwfase is ook de automatische verlichting op de infrastructuur aangesloten voor de opbergruimte onder de bedden die toegankelijk is via 2 serviceluiken aan de zijkant. Hiervoor gebruik ik een aparte Nano Every met twee PIR-sensoren. De verlichting kent drie standen: automatisch, handmatig aan en handmatig uit. In de automatische stand handelt de slave de bewegingsdetectie en het schakelen van het relais lokaal af.

De PIR-sensoren zijn uitsluitend bedoeld voor de verlichting. Een eventueel toekomstig interieuralarm krijgt een eigen sensor, rechtstreeks op de Master. Ik wil niet dat een storing op de Modbus-bus of in de verlichtingsslave bepaalt of een lokaal beveiligingsalarm wel of niet afgaat. Interieuralarm is een TO-DO

Het fietsalarm

 De volgende uitbreiding was het fietsalarm. De aansluiting is opgebouwd als een bewaakte EOL-lus via een waterdichte CNLINKO-connector aan de buitenzijde van de caravan. De analoge ingang van de Master kan drie toestanden onderscheiden: de lus is open, de lus is normaal aangesloten met de eindweerstand aanwezig, of de lus is kortgesloten om de beveiliging te omzeilen. De bandbreedte is ruim genoeg om vals alarm te voorkomen.

Daarmee ziet het systeem dus verschil tussen een niet aangesloten fiets, een correct bewaakte verbinding en sabotage. Alleen twee draadjes kortsluiten is niet voldoende om het alarm voor de gek te houden.

Het fietsalarm moet lokaal een sirene kunnen activeren en daarnaast via MQTT een melding versturen. Die volgorde is bewust. De sirene is onderdeel van de lokale beveiliging en mag nooit wachten op wifi, 4G, HiveMQ of Homey. De melding op mijn telefoon is aanvullend. De hardware en drempelwaarden zijn getest. De uiteindelijke sirenelogica en de volledige bediening via MQTT zijn TO-DO.

De leveler met een eigen scherm

 Na het fietsalarm volgde de leveler. Een caravan waterpas zetten met een los waterpasje werkt natuurlijk prima. Maar als er toch al een controller, bus en displays aanwezig zijn, dan kan dat ook beter, mooier (en ingewikkelder) 😉.



De eerste poging was met een Murata SCL3300. Dat is op papier een mooie hellingssensor, maar de communicatie wilde in deze opstelling niet betrouwbaar werken.



Uiteindelijk heb ik deze vervangen door een Adafruit ISM330DLC. Alleen de accelerometer wordt gebruikt. De gyro blijft uit, want de caravan hoeft niet te weten hoe spectaculair hij om zijn as draait .

De sensor zit in de disselbak en is via I2C rechtstreeks aangesloten op de Gas-Mega. Die berekent lokaal de lengte- en breedtehelling. Een eenmalige kalibratie wordt als offset in EEPROM opgeslagen. Daarna worden de waarden gefilterd en rechtstreeks naar een apart Nextion-scherm gestuurd.

 


Dat scherm zit in een eigen 3D-geprinte behuizing en is met een krulsnoer verbonden. Tijdens het levelen kan ik het scherm naar buiten halen en op een handige plaats neerleggen. Pitch en roll hoeven niet eerst via de centrale Master te lopen voordat er een pijl op het display beweegt. Dat is precies het voordeel van lokale verwerking op een slave.

Door de kabellengte en het feit dat dit gewone UART is, draait de verbinding op 9600 baud. Dat bleek in de praktijk voldoende. Zolang de aandrijfrollen van de mover tegen de caravanband aan staan (feitelijk is het: ze zijn niet home en staan dus niet in de thuispositie), blijft het levelerscherm volledig aan. Zodra de rollen terug naar de thuispositie gaan, start een nalooptijd van tien minuten. Daarna gaat het scherm uit. Een aanraking start die tijd opnieuw.

De filtering leverde nog een interessante fout op. De leveler nam oorspronkelijk twintig samples met telkens acht milliseconden ertussen. Binnen een cyclus van tweehonderd milliseconden was de slave daardoor bijna permanent aan het meten. De Modbus-afhandeling kreeg nauwelijks tijd en de Master begon op vaste momenten timeouts te melden.

De oplossing was niet simpelweg minder filteren. Tijdens de wachttijd tussen de samples wordt nu steeds de Modbus-taak uitgevoerd. Het aantal samples is teruggebracht naar tien, maar de updatecyclus is tweehonderd milliseconden gebleven. Een eerdere poging om die cyclus naar vijfhonderd milliseconden te brengen maakte de aanwijzing merkbaar te traag. Dat kwam niet door de sensor, maar doordat de tijdconstante van de filters rechtstreeks mee veranderde.

Waarom zijn aandrijfrollen van een mover niet beveiligd?

Tijdens het werken aan de leveler verbaasde ik me over iets anders. De moverrollen kunnen nog tegen de banden staan terwijl de auto alweer wordt aangekoppeld. Er is standaard geen beveiliging die voorkomt dat je in die toestand probeert weg te rijden. Bij een systeem dat mechanisch stevig tegen beide banden wordt gedrukt, vond ik dat nogal bijzonder. De afgelopen paar jaar heb ik, als ik eens liep te struinen op een kampeer-/caravanbeurs, mijn licht opgestoken bij diverse fabrikanten. Waarom niet een potentiaalvrij contact aanbieden als de mover in de homepositie staat? Het was alsof ze water zagen branden, terwijl het voor aanzienlijke schade kan zorgen aan mover en caravan. Daarom heb ik een akoestische waarschuwing toegevoegd. Twee positieschakelaars bewaken de linker- en rechteraandrijfrol als deze in de home positie staan (NIET tegen de band aan). Zodra de 13-polige stekker van de auto wordt aangesloten terwijl één van de rollen nog niet in de thuispositie staat, gaat lokaal een zoemer af. De logica gebruikt bewust een OF-voorwaarde. Eén vergeten rol is voldoende voor een waarschuwing.

Het aankoppelsignaal komt via een solid-state relais binnen. Daarmee is de caravanbesturing volledig galvanisch gescheiden van de elektrische installatie van de auto. De ingang van het SSR accepteert ongeveer 3 tot 36 volt en kan daardoor ook de normale variaties van een 12-volts boordnet opvangen.

 

Daarnaast zit er een degelijke softwarematige debounce op het signaal. Tijdens het insteken van een caravanstekker ontstaan vrijwel altijd meerdere korte contacten. Ook weet ik niet wat iedere auto tijdens het aankoppelen precies aan testpulsen of minder fraaie spanningsvormen op de aansluiting zet. Misschien valt het in de praktijk allemaal mee, maar hier neem ik liever het zekere voor het onzekere. De Master accepteert het signaal pas wanneer het voldoende lang stabiel is.

De volledige waarschuwingsketen draait lokaal op de Master. Geen internet, GPS of werkende Modbus-bus nodig. Op het levelerscherm zit wel een tijdelijke overbruggingsknop, mocht een eindschakelaar falen. Je zal maar met je akoestische zoemer vanuit Noord-Italië komen terugrijden



Omdat een Modbus-slave niet uit zichzelf een bericht naar de Master stuurt, leest de Master die instelling bij de normale poll van de Gas-slave. Daardoor kan er enkele seconden zitten tussen het aanraken van de knop en het stoppen van de zoemer. Voor deze toepassing is dat geen probleem. Als het hele project af is, ga ik wellicht de pollingsintervallen verhogen.

De eventuele overbrugging wordt bij een nieuwe aankoppeling of als de aandrijfrollen weer in de homepositie staan automatisch gewist. Daarmee voorkom ik dat een oude handmatige uitschakeling weken later nog actief blijkt te zijn.

Ook hier liep ik tegen een mooie Nextion "grap" aan; het scherm stuurde de waarde van een numerieke variabele als vier ruwe bytes, terwijl de Arduino-parser het teken 0 of 1 verwachtte. De knop reageerde visueel prima, maar functioneel gebeurde er niets. Door vanuit de HMI expliciet 0 of 1 te versturen werkte het wel.

MQTT: het hoofdpijndossier

 Pas nadat de lokale functies werkten, ben ik begonnen met de communicatie naar buiten. Voor een alarmmelding op afstand moet de caravan ook zonder camping-wifi data kunnen versturen. Daarvoor gebruik ik een Waveshare SIM7600G-H 4G HAT met een IoT 1NCE-simkaart.

1NCE is specifiek gericht op IoT-toepassingen met zeer weinig dataverbruik. Dat past goed bij dit project. De caravan hoeft geen foto's, video of grote hoeveelheden meetdata te versturen. Het gaat vooral om enkele statussen, commando's en incidentele alarmberichten. Na honderden testberichten over en weer was mijn saldo op de sim van 500 MB naar 499,1 MB gezakt. Ik heb uitgerekend dat, als ik elke 15 minuten een heartbeat laat versturen als ik met de caravan weg ben en er geen wifi beschikbaar is, 500 MB zo lang meegaat dat geen enkel regulier abonnement daartegen opweegt. Ik kan er jaren mee doen en het kost EUR 12,- per 500 MB.



 De SIM7600 heeft heeeeeeeeeeeeeeeeeeeeel veel tijd gekost. De eerste tests leverden niets bruikbaars op. De uiteindelijke oorzaak was pijnlijk eenvoudig: de voeding zat op de verkeerde header (en weer doooooooooor)
Nu moet ik zeggen dat de ID’s op de PCB ook niet heel duidelijk waren. Maar RTFM was wel van toepassing; wellicht had ik eerst even de documentatie moeten lezen. . Nadat de 5 volt en GND op de juiste GPIO-pinnen waren aangesloten, werkte de module via USB direct.

Nou ja....werken....daarmee werkte de voeding, maar de rest niet. De verbinding met de Mega werkt op 115200 baud. Permanent op 9600 baud zetten (vanwege stabiliteit) moest in theorie mogelijk zijn, maar was in de praktijk een drama en heb ik niet voor elkaar gekregen.

Vervolgens bleek de MQTT-opbouw gevoeliger voor volgorde en timing dan de losse AT-commando's deden vermoeden. Een antwoord OK betekent bij dit modem vaak alleen dat een opdracht is aangenomen. Het betekent nog niet dat de netwerkactie daadwerkelijk gereed is. Voordat ik daarachter was, was ik een paar avonden verder. Dat veroorzaakte onder andere een race condition bij het starten van MQTT. De code ging al door naar de volgende stap nadat OK was ontvangen, terwijl de modem de definitieve melding dat het netwerk open stond nog niet had gestuurd. Het volgende commando faalde daardoor structureel met de mededeling dat het netwerk niet open was. De modemlogica is daarom opgebouwd als een non-blocking state machine. Iedere stap onthoudt waar hij is, controleert in volgende rondes van de hoofdloop of het verwachte antwoord is ontvangen en heeft een eigen timeout. De rest van de caravan blijft ondertussen gewoon doorwerken. Dat geleuter met dat modem heeft heel veel tijd gekost, aangezien een dergelijk modem en AT-commando’s redelijk nieuw voor mij waren.

Ook de herstelstrategie is getest. Eerst probeert de software de verbinding gecontroleerd opnieuw op te bouwen. Als dat herhaaldelijk mislukt, onderbreekt een relais de voeding van de SIM7600 voor een echte koude start. Een eerdere tussenstap via de PWRKEY-ingang bleek in de praktijk niets aantoonbaars te doen en is daarom weer verwijderd.

Tijdens een fouttest bleek vervolgens dat de teller voor opeenvolgende storingen na een succesvolle tussenstap alweer op nul werd gezet. Een fout die pas daarna optrad kon daardoor eindeloos blijven herhalen zonder ooit de harde relaisreset te bereiken. De teller wordt nu pas gewist wanneer de complete MQTT-verbinding werkelijk is opgebouwd.

De cloudroute loopt via HiveMQ. Thuis draait Mosquitto op mijn Synology NAS en die broker is gekoppeld aan HiveMQ. Daardoor kan een bericht vanuit de caravan via 4G uiteindelijk zowel in Homey als op mijn telefoon terechtkomen. En inmiddels heb ik IoT MQTT Panel (iOS), waarmee ik een eerste dashboard heb gemaakt. Dat lijkt heel goed te werken. Bedien ik het scherm in de caravan, dan verandert de status op mijn telefoon en Homey. Dat werkt inmiddels bidirectioneel.

De eerste route was volledig via 4G. Dat werkt, maar een IoT-simkaart heeft bewust een beperkt databudget. Een altijd geopende MQTT-verbinding verbruikt ook zonder echte berichten data door keepalives en herverbindingen. Daarom wordt wifi de primaire route zodra de caravan op een campingnetwerk is aangesloten en blijft 4G beschikbaar als fallback.



Voor camping-wifi gebruik ik een Alfa WiFi Camp Pro 3. Daarmee ontvang ik het campingnetwerk en maak ik in de caravan een eigen netwerk met eigen SSID. Een Raspberry Pi 3B+ met Elecrow-touchscreen start rechtstreeks in kioskmodus op de beheerpagina van de Alfa. Met het schermtoetsenbord kan ik ter plaatse het camping-SSID, wachtwoord en eventuele inlogportal instellen zonder een laptop te pakken. Dit bedieningsdeel staat bewust los van het RS-485 project.

 



Voor de koppeling met de centrale caravanbesturing komt er een Arduino UNO R4 WiFi met W5500-Ethernetmodule en MAX485-interface. Die krijgt via UTP rechtstreeks verbinding met de Alfa en wordt een nieuwe node op de Modbus-daisy-chain. De eerste complete Ethernettest is geslaagd: W5500 gevonden, UTP-link actief, DHCP in orde, DNS werkt correcte HTTP-test.

TO-DO: integratie in de mainsketch en het Modbus-netwerk. Aansluiten op de Mega Master kon wel, maar dan vooral met SoftwareSerial. Aangezien ik zo’n stabiel mogelijk systeem wil en ik inmiddels bakken vol met boards, sensoren en weet ik veel wat nog meer heb liggen, heb ik voor een opzet met een R4 gekozen. Het beoogde gedrag is eenvoudig. Waar camping-wifi beschikbaar is, loopt MQTT via die verbinding om mobiele data te besparen. Als wifi ontbreekt of uitvalt, kan 4G als fall back gebruikt worden. Een lokaal alarm blijft ondertussen altijd lokaal werken. De verbinding naar buiten bepaalt alleen of en wanneer er ook een melding op afstand aankomt. 

Normale statusberichten mogen daarbij nooit een alarmmelding uit de wachtrij drukken. Het alarm krijgt daarom een eigen, niet-overschrijfbare plek en gaat als eerste weg zodra een verbinding beschikbaar is. Publicaties worden met QoS 1 verstuurd en pas na bevestiging door de broker uit de lokale wachtrij verwijderd.

GPS voor net wat meer slimheid

 De GPS-module kwam pas later in beeld. De SIM7600 heeft ook de mogelijkheid tot GPS, maar gezien “het gedoe” voordat ik dat ding stabiel had draaien, heb ik toch maar een extra GPS-module erbij aangesloten. Mijn caravan staat thuis in een eigen stalling en dan zijn de watertank en boiler leeg, waardoor het systeem terecht meldingen gaf en het centrale scherm onnodig lang actief bleef. Dat zou maar eens maanden op rij kunnen zijn in de winterperiode. Da’s niet lekker voor zo’n scherm.

De Master had inmiddels geen vrije hardware-UART meer. USB-debug, Nextion, RS485 en de SIM7600 gebruiken alle vier de seriële poorten. Daarom heb ik gekozen voor een DFRobot L76K GNSS-module via I2C. Die levert positie, tijd en snelheid zonder nog een seriële poort op te eisen. 

Thuis gebruikt het systeem een geofence van 500 meter. Een melding wordt daar nog één keer kort zichtbaar, maar houdt het scherm niet permanent aan. Ook tussen 20:30 en 07:30 (wanneer ik buiten de geofence ben en de auto niet is aangekoppeld; lees: ik ben op de camping) geldt een rustige meldingslogica. Tijdens het rijden worden meldingen over water en gas niet automatisch op het scherm gezet. Vloeistof die onderweg klotst, is nu eenmaal geen betrouwbare niveaumeting. En ’s nachts hoef ik als ik op vakantie ben geen oplichtend scherm dat meldt dat het waterniveau laag is.


De GPS wordt iedere minuut uitgelezen. Tijdens de eerste tests zag de module tussen de 17 en 26 satellieten en lag de berekende positie ongeveer twintig meter van de werkelijke locatie. Voor een geofence van 500 meter is dat ruim voldoende.

Ook dit blijft een comfortfunctie. Als de GPS ontbreekt of de I2C-bus een storing heeft, moet de waarschuwing voor de aandrijfrollen van de mover of het fietsalarm gewoon blijven werken. De initialisatie heeft daarom een begrensd aantal pogingen en de I2C-bus heeft een timeout. De main loop blijft altijd doorlopen.


TO-DO:

- 3D behuizing voor centrale scherm en plaatsing (dat wordt nog een uitdaging)
- Fietsalarm afmaken
- Geofence testen

Kortom: Zo goed als klaar met een paar TO-DO's. Wanneer het volledig werkend is zal ik (veel) meer detailfoto's plaatsen.  

Wat begon als irritatie over een paar knoopcellen en wegvallende E-Trailer-sensoren is inmiddels caravandomotica geworden. Volstrekt logisch dus (voor mij) 😉



Tot in de comments.

TO BE CONTINUED

[ Voor 135% gewijzigd door RSV31 op 03-08-2026 18:12 ]

[Kecin]

Interessant topic, en zeker leuk om te maken lijkt me! Ik zou wel graag nog meer foto's en diagrammen zien (nerd-alert). Ik volg!

Edit: Ik zie dat er ondertussen (erg) veel is toegevoegd aan de TS. Die ga ik straks weer opnieuw lezen, tof!

[ Voor 30% gewijzigd door Kecin op 03-08-2026 18:55 ]

[Makrolon]

Wat vet dit! Ik snap de helft niet maar alsnog leuk om te lezen


Wel jammer dat andere mensen geen idee hebben wat voor technisch hoogstaand ding er staat als ze de eriba zien staan

[_ferry_]

Geweldig, ik zie het al helemaal voor je, lekker op de camping, laptopje erbij en dit allemaal in elkaar knutselen.
Hoe heb je ooit zonder gekund hehe

Begint bij mij ook meteen te kriebelen, want een sensor on te kijken of de boel waterpas staat zou echt een toevoeging zijn voor mijn oude campertje. Nu rij ik het veld op, denk ik dat ik recht sta, en dan in de avond ga ik slapen en blijkt recht toch niet zo recht te zijn als ik dacht
(En de Arduino met nextion schermpje en sensoren voor de motor heb ik toch al....)

[RSV31]

Daar was mijn vakantie te kort voor hoor, voor zo’n project 😂.

[ Voor 35% gewijzigd door RSV31 op 03-08-2026 22:16 ]

[_ferry_]

Dat geloof ik graag! Maar ik zou op vakantie dan nogal de neiging hebben om er verder aan te knutselen, en zaken te verbeteren.

[blitzkrieg]

Zou bandentemperatuur en druk nog wat zijn voor tijdens het rijden?

[No Hands]

_ferry_ schreef op maandag 3 augustus 2026 @ 21:51:
Geweldig, ik zie het al helemaal voor je, lekker op de camping, laptopje erbij en dit allemaal in elkaar knutselen.
Hoe heb je ooit zonder gekund hehe

Begint bij mij ook meteen te kriebelen, want een sensor on te kijken of de boel waterpas staat zou echt een toevoeging zijn voor mijn oude campertje. Nu rij ik het veld op, denk ik dat ik recht sta, en dan in de avond ga ik slapen en blijkt recht toch niet zo recht te zijn als ik dacht
(En de Arduino met nextion schermpje en sensoren voor de motor heb ik toch al....)

ftfy

[RSV31]

blitzkrieg schreef op dinsdag 4 augustus 2026 @ 07:09:
Zou bandentemperatuur en druk nog wat zijn voor tijdens het rijden?

Jazeker. Die staat ook nog op mijn to-dolijst. Ik loop daarbij vooral tegen een aantal praktische zaken aan.

De wieldoppen hebben een zeer kleine ventielopening. Bovendien staan de wieldoppen van dit type caravan erom bekend dat de scherpe felsrand van deze opening het rubberen ventiel kan doorsnijden. De wieldop zit achterlijk stevig vastgeklemd (ik krijg hem er zonder gereedschap niet af), maar kan desondanks ten opzichte van de velg roteren. Inmiddels zijn er metalen ventielen, oftewel metalen ventielstelen, gemonteerd.



Optie 1: een externe TPMS-sensor als vervangende ventieldop

• De opening in de wieldop is te klein voor de sensor. Ik zou deze met een handmatige pons durven vergroten, maar daarbij wordt de beschermende chroomlaag beschadigd. Omdat het een verchroomde stalen wieldop is, zal deze op termijn waarschijnlijk gaan roesten.
• De ventielsteel verlengen en daarop de TPMS-sensor als ventieldop monteren. Nadeel: dat is ronduit lelijk (ik trek dat echt niet ) en bovendien zijn dergelijke sensoren diefstalgevoelig.

Optie 2: een TPMS-sensor in de velg

Daarbij zou aan de buitenzijde een ontvanger of baken moeten worden geplaatst dat het signaal van de sensoren opvangt. In deze mogelijkheid heb ik mij nog onvoldoende verdiept.

Het systeem moet via MQTT kunnen communiceren, een gangbaar uitgangssignaal leveren dat binnen het bestaande systeem kan worden verwerkt, of een potentiaalvrij contact met een instelbare drempelwaarde aanbieden.

Daarnaast vraag ik mij af hoelang de batterijen of accu’s van de interne sensoren meegaan. De banden worden immers alleen gedemonteerd wanneer ze moeten worden vervangen, onder andere om aan de eisen van de Duitse Tempo 100-goedkeuring te blijven voldoen.

[RSV31]

No Hands schreef op dinsdag 4 augustus 2026 @ 07:21:
[...]

ftfy

[Afbeelding]

Dat is echt heel raar. Moet je helemaal handmatig de waterpas pakken, plaatsen, aflezen, data-analyse, kalibratierapport waterpas controleren op geldigheid, heen en weer jutteren.....Nee hoor, dat kan echt niet

[Falcon]

@RSV31 Hoe gaat je partner hier eigenlijk mee om?

[blitzkrieg]

RSV31 schreef op dinsdag 4 augustus 2026 @ 09:11:
[...]

Daarnaast vraag ik mij af hoelang de batterijen of accu’s van de interne sensoren meegaan. De banden worden immers alleen gedemonteerd wanneer ze moeten worden vervangen, onder andere om aan de eisen van de Duitse Tempo 100-goedkeuring te blijven voldoen.

Ze zeggen 5 tot 10 jaar voor de batterij, dus dat zou goed moeten gaan met 1x in de 6 jaar banden wisselen voor de tempo 100 goedkeuring. (Mijn verzekeraar verplicht trouwens ook 6 jaar)

[RSV31]

Falcon schreef op dinsdag 4 augustus 2026 @ 09:20:
@RSV31 Hoe gaat je partner hier eigenlijk mee om?

Goeie vraag . Die vond het in eerste instantie allemaal maar mwhoaaaaaa… Lees: ja hoor, het is nu eenmaal zijn hobby, laat hem maar lekker prutsen.

Een klein beetje context: Toen we onze nieuwe woning lieten bouwen, heb ik een veel te grote meterkast laten plaatsen, overal UTP, 12 V en 24 V kabels naartoe laten trekken en een hoeveelheid loze leidingen laten aanleggen waar een gemiddeld datacenter jaloers op is. Iedereen dacht dat ik gek was. Zelfs de E-installateur wilde op een gegeven moment een ‘goed gesprek’ met me voeren om te controleren of ik nog wel helemaal in orde was.

Mooi hè? Koop je zelf een stuk grond, neem je een architect in de arm en laat je na jarenlang dromen en sparen eindelijk je eigen huis bouwen… word je als opdrachtgever door de installateur op het matje geroepen. 😄 PRACHTIG.

Inmiddels zijn we jaren, honderden Homey-flows, >100 IP-adressen verder en tientallen Z-wave en Zigbee devices verder. Zo ongeveer alles wat geautomatiseerd kán worden, is geautomatiseerd. Inclusief een paar dingen waarvan normale mensen waarschijnlijk niet eens weten dat je ze zou wíllen automatiseren. Maar wel met 1 doel: stabiel en betrouwbaar.

Mijn vrouw is ondertussen volledig om. Laatst kwam er een collega van haar langs die nog nooit bij ons thuis was geweest. Tot mijn stomme verbazing kreeg die een complete rondleiding. For the record: we wonen vrijstaand, maar beslist niet in een villa dus "complete rondleiding" een klein beetje in context plaatsen ;-). En toen kwam het mooiste:

“Het is allemaal zó betrouwbaar. En ik kan het licht ook gewoon met de normale schakelaars aanzetten, uitzetten en dimmen! Enne ....dit is slim, dat is slim, dit werkt heel makkelijk". En als we op vakantie zijn werkt de irrigatie autonoom op basis van vochtsensoren, regensensor, droogtetijd.......... Ik stond erbij en keek ernaar. Ik wist niet wat ik hoorde. Jarenlang was het ‘zijn hobby’ en nu bleek ik ineens een compleet uitgerolde referentie-installatie te hebben gebouwd. 😂

Kortom: ze weet inmiddels dat al dat gepruts haar ook behoorlijk wat gemak oplevert. Na jaren ploeteren heb ik dus carte blanche. Officieel omdat alles handig en betrouwbaar werkt en hier en daar ook kosten bespaard (of ze is gestopt met vragen stellen en bij haar lot neergelegd).

_{p.s. Er kan zomaar eens familie meelezen hier, dus beetje diplomatie vereist . Ik noem verder geen namen maar het gaat om L.M. te D}

[ Voor 3% gewijzigd door RSV31 op 04-08-2026 11:25 ]

[Josk79]

Ik zou ook graag een reactie in jou vrouw’s woorden willen lezen 😉.

[revolution-nl]

Geweldig! Deze ga ik volgen.

Ik wilde een soortgelijk project starten, toen mijn vrouw er lucht van kreeg is het expliciet VERBOTEN

[ Voor 8% gewijzigd door revolution-nl op 04-08-2026 10:04 ]

[Raznov]

Mooi werk! Wij zijn ooit begonnen met onze Home Star caravan te verbeteren, eerst een nieuw laagje verf van binnen, maar ook water meters, water sensor binnen het toilet, kwh meter en wilde het later nog allemaal "slim" maken, E-trailer vond ik geen optie (want te dom) en zelf bouwen zou te veel tijd kosten. Als ik dit zo lees, ben ik ook blij dat ik dat niet direct heb gedaan (want het kost inderdaad heel veel tijd :-), wel een heel gaaf resultaat), mogelijk over een paar jaar eens oppakken.

[RSV31]

Josk79 schreef op dinsdag 4 augustus 2026 @ 10:02:
Ik zou ook graag een reactie in jou vrouw’s woorden willen lezen 😉.

Nee, dat wil jij niet en ik al helemaal niet. Die hou ik heel wijs ver bij Tweakers vandaan

[teacher]

Goud! Het leest ook als een spannend jongensboek! I like!
Tpms systeempje met interne sensoren kost je een paar tientjes op ali.

[simplemouse]

wat een tof project!

ik krijg dit er niet door hier thuis hoor, vind mijn vrouw veel te veel onzin, nu gaat het toch ook ;-)

[franssie]

Die QDY30A-niveausensor is wel een leuk ding, eigenlijk een soort dieptemeter begrijp ik.
Ik zie dat er drie uitvoeringen zijn, waarvan ik aanneem dat jij de RS-485 versie hebt genomen?

[TheUnknowny]

Wat een gaaf project, die nextion schermen kende ik nog niet. Zien er ook wel interessant uit als een optie om een Homeassistant huis mee te bedienen.

Vroeg me wel af waarom je, de afscherming van je modbus kabels maar aan één kant aansluit. Ik heb altijd geleerd dat je beide kanten moet aansluiten zodat de storing over het scherm terug naar aarde loopt en niet door je aders. Is dit anders in een caravan?

[ron321]

Ik weet niet beter dat je afscherming altijd maar aan één kant aan aarde legt.

[Falcon]

RSV31 schreef op dinsdag 4 augustus 2026 @ 09:38:
[...]

Goeie vraag . Die vond het in eerste instantie allemaal maar mwhoaaaaaa… Lees: ja hoor, het is nu eenmaal zijn hobby, laat hem maar lekker prutsen.

Een klein beetje context: Toen we onze nieuwe woning lieten bouwen, heb ik een veel te grote meterkast laten plaatsen, overal UTP, 12 V en 24 V kabels naartoe laten trekken en een hoeveelheid loze leidingen laten aanleggen waar een gemiddeld datacenter jaloers op is. Iedereen dacht dat ik gek was. Zelfs de E-installateur wilde op een gegeven moment een ‘goed gesprek’ met me voeren om te controleren of ik nog wel helemaal in orde was.

Mooi hè? Koop je zelf een stuk grond, neem je een architect in de arm en laat je na jarenlang dromen en sparen eindelijk je eigen huis bouwen… word je als opdrachtgever door de installateur op het matje geroepen. 😄 PRACHTIG.

Inmiddels zijn we jaren, honderden Homey-flows, >100 IP-adressen verder en tientallen Z-wave en Zigbee devices verder. Zo ongeveer alles wat geautomatiseerd kán worden, is geautomatiseerd. Inclusief een paar dingen waarvan normale mensen waarschijnlijk niet eens weten dat je ze zou wíllen automatiseren. Maar wel met 1 doel: stabiel en betrouwbaar.

Mijn vrouw is ondertussen volledig om. Laatst kwam er een collega van haar langs die nog nooit bij ons thuis was geweest. Tot mijn stomme verbazing kreeg die een complete rondleiding. For the record: we wonen vrijstaand, maar beslist niet in een villa dus "complete rondleiding" een klein beetje in context plaatsen ;-). En toen kwam het mooiste:

“Het is allemaal zó betrouwbaar. En ik kan het licht ook gewoon met de normale schakelaars aanzetten, uitzetten en dimmen! Enne ....dit is slim, dat is slim, dit werkt heel makkelijk". En als we op vakantie zijn werkt de irrigatie autonoom op basis van vochtsensoren, regensensor, droogtetijd.......... Ik stond erbij en keek ernaar. Ik wist niet wat ik hoorde. Jarenlang was het ‘zijn hobby’ en nu bleek ik ineens een compleet uitgerolde referentie-installatie te hebben gebouwd. 😂

Kortom: ze weet inmiddels dat al dat gepruts haar ook behoorlijk wat gemak oplevert. Na jaren ploeteren heb ik dus carte blanche. Officieel omdat alles handig en betrouwbaar werkt en hier en daar ook kosten bespaard (of ze is gestopt met vragen stellen en bij haar lot neergelegd).

_{p.s. Er kan zomaar eens familie meelezen hier, dus beetje diplomatie vereist . Ik noem verder geen namen maar het gaat om L.M. te D}

Jouw key-user zo te lezen.. lol.. mooi man

[TheUnknowny]

ron321 schreef op dinsdag 4 augustus 2026 @ 17:28:
Ik weet niet beter dat je afscherming altijd maar aan één kant aan aarde legt.

Dat was vroeger zo toen we alleen nog maar 50Hz hadden. Sinds de komst van transistors en diodes zijn er veel meer verstoringen op verschillende frequenties. Vroeger was het gezegde in de elektrotechniek "Gij zult geen lussen maken" daar zijn ze de laatste 15 jaar van terug gekomen, het is nu "Gij zult vermazen".

Door de afscherming aan beide kanten aan te sluiten maak je een kooi van faraday. Als je een afscherming alleen aan één kant aansluit kan die als antenne gaan werken.

Ik ken nog maar twee uitzonderingen waar nog steeds maar één kant word aangesloten, audio en intrensiekveilige circuits in explosieve omgevingen.

Vandaar mijn vraag, misschien is dit een derde uitzondering.

[RSV31]

Goeie vraag! Zoals ik het vroeguh heb geleerd in het jaar kruik en e.e.a. gecheckt met Ai is dit mijn gedachtengang. Want ik wist ook niet beter (zoals ik het verleden deed toen ik bij een machinebouwer werktte) dat een PE/aarde (al dan niet gevlochten om de kabel heen) altijd aan beide kanten aansloten werd.

Mijn situatie in de caravan is alleen wat anders. Het is (voornamelijk) een 5/12 V DC-installatie en de elektronica hangt aan dezelfde voeding/massa. Als ik de afscherming aan beide kanten aan die massa knoop, maak ik dus een tweede elektrisch pad tussen master en slaves. Door spanningsverschillen in de bekabeling kunnen daar vervolgens vereffeningsstromen door gaan lopen. Dan wordt de afscherming ineens gedeeltelijk stroomdraad en dat wil ik juist niet.

Toen ik ging bekabelen heb ik de de documentatie (lees: had ik ook met de SIM HAT moeten doen en had ik direct de 5V en GND goed aangesloten) op modbus.org er maar eens op nageslagen:

https://www.modbus.org/file/secure/modbusoverserial.pdf

De officiële Modbus Serial Line Implementation Guide schrijft voor dat de kabel afgeschermd moet zijn en dat die afscherming aan één uiteinde met protective ground wordt verbonden.

Dus dat heb ik braaf gedaan

Waarom het in andere gevallen wel moet.....daar schiet mijn kennis te kort.

[RSV31]

franssie schreef op dinsdag 4 augustus 2026 @ 14:55:
Die QDY30A-niveausensor is wel een leuk ding, eigenlijk een soort dieptemeter begrijp ik.
Ik zie dat er drie uitvoeringen zijn, waarvan ik aanneem dat jij de RS-485 versie hebt genomen?

Nee, uiteindelijk de 1-5V versie gekozen omdat twijfelde of rechtstreeks op de RS-485 wel nodig zou zijn aangezien diverse Arduino Nano's als slave gebruik die al met een RS-485 module aan het netwerk hangen. Sensor werkt tot op heden probleemloos. Eenmalige kalibratie hoeveel Volt 0% en 100% is en good to go. En slecht 2 a 3 mm afwijking in de waterkolom wat voor dit project natuurlijk meer dan voldoende is

En het is idd een soort dieptemeter met een membraam die druk uitoefent op een druksensor. Er zit dan ook een kleine luchtleiding samen met de kabels vanuit de sensor die ten alle tijden moet kunnen vereffenen met de buitenlucht.

[ Voor 14% gewijzigd door RSV31 op 05-08-2026 12:01 ]

[Fraggert]

Ik heb niks met caravans en dit soort HA-projecten maar ik waardeer de technische kennis van mensen die dit leuk vinden, dikke kudo's voor de verslaglegging.

Maar die OP van TS @RSV31 vraagt natuurlijk wel om een eigen foto van die sleurhut

Ik vind die wat "retro"-ogende caravannetjes met zo'n hefdak echt uber-cool

[RSV31]

Fraggert schreef op woensdag 5 augustus 2026 @ 12:02:
Ik heb niks met caravans en dit soort HA-projecten maar ik waardeer de technische kennis van mensen die dit leuk vinden, dikke kudo's voor de verslaglegging.

Maar die OP van TS @RSV31 vraagt natuurlijk wel om een eigen foto van die sleurhut

Ik vind die wat "retro"-ogende caravannetjes met zo'n hefdak echt uber-cool

Ook die foto komt gaandeweg het project als alles klaar is. De openingsfoto is overigens wel op waarheid gebaseerd dus ik zal je niet teleurstellen

[Fraggert]

RSV31 schreef op woensdag 5 augustus 2026 @ 12:04:
[...]

Ook die foto komt gaandeweg het project als alles klaar is. De openingsfoto is overigens wel op waarheid gebaseerd dus ik zal je niet teleurstellen

Het is ook zeker wel een leuk plaatje hoor, beetje cartoony, maar was benieuwd naar je eigen Eriba-tje

Keep up the good work en veel succes met de uitvoering in elk geval, ik vind het razend knap