Als het over domotica-apparaten gaat, hoor je doorgaans over Philips Hue of het onderliggende Zigbee, over Z-Wave en zelfs over wifi, en de laatste tijd ook over Thread. Bluetooth Low Energy wordt vaak vergeten, en dat terwijl het heel wat troeven heeft.
Er bestaan talloze draadloze standaarden voor domotica-apparaten. Er is plaats voor allemaal, want elke standaard heeft zijn voor- en nadelen. Zigbee en Z-Wave maken apparaten met een laag verbruik mogelijk en scoren punten op flexibiliteit met hun meshnetwerk. Wifiapparaten verbruiken meer, maar hebben het grote voordeel dat ze in je lan geïntegreerd zijn en dus gemakkelijk te benaderen. Thread combineert een laag verbruik met een op IPv6 gebaseerde connectiviteit en zelfhelende netwerkarchitectuur.
Bluetooth Low Energy is niet het eerste protocol waar mensen aan denken als ze het over domotica hebben en dat is onterecht. Net als de hierboven vermelde standaarden heeft BLE zijn unieke combinatie van eigenschappen die het een interessant protocol voor domotica maken.Een BLE-temperatuursensor kan gemakkelijk tien jaar op een knoopcelbatterij draaien
Lage drempel
‘Low Energy’ in de naam maakt al duidelijk dat het protocol focust op laag energiegebruik. In vergelijkingenmet andere draadloze protocols scoort BLE dan ook net dat ietsje beter. Zo kan een BLE-temperatuursensor gemakkelijk tien jaar op een knoopcelbatterij draaien. Een ander voordeel dat bluetooth met wifi deelt, is dat het alomtegenwoordig is. Zowat alle smartphones, tablets en laptops hebben een BLE-chip ingebouwd. Dat betekent dat al deze apparaten met je BLE-sensoren of -lampen kunnen spreken, bijvoorbeeld via een mobiele app van de fabrikant. Ook de Raspberry Pi vanaf model 3 (uit 2016) en de ESP32 hebben BLE ingebouwd. Beide apparaten zijn populair bij domoticahobbyisten. BLE heeft dan ook een lage instapdrempel.
Een nadeel van bluetooth is het kortere bereik vergeleken met Zigbee, Z-Wave en Thread, die een mesharchitectuur hebben. Sinds 2017 is er ook een meshprotocol Bluetooth Mesh. Dat gebruikt de physical layer en link layer van BLE, en bouwt daarboven een volledig nieuwe stack voor een meshnetwerk. Hoewel er domoticaproducten met Bluetooth Mesh bestaan, bijvoorbeeld van Crownstone, Xiaomi en Yeelight, is het in de domoticawereld nog niet echt doorgebroken.
Gelaagde architectuur en databroadcasting
De Bluetooth Core Specification telt meer dan 3200 pagina’s en daar komen nog heel wat andere specificaties bij. Net als andere protocollen maakt BLE echter gebruik van een gelaagde architectuur, waardoor de meeste eindgebruikertoepassingen alleen met de hogere lagen in contact komen.
De lagen zijn onderverdeeld in twee blokken: controller en host. Onderaan bevinden zich de lagen die door de controller worden uitgevoerd: physical layer, link layer en direct test mode. In deze lagen doet de bluetoothradio zijn werk. De communicatie met de buitenwereld gebeurt via de antenne, in een frequentieband rond 2,4GHz, en de communicatie met de host gebeurt via een laag die tussen de twee blokken zit: de host controller interface.
Daarboven bevindt zich dus het host-blok, waarmee de host zijn taken uitvoert. Ruwweg kun je zeggen dat de controller een BLE-dongle is en je laptop of Raspberry Pi een BLE-host. Tegenwoordig hebben de meeste computers al een BLE-controller ingebouwd en dan gebeurt de communicatie tussen controller en host niet via USB, maar via SDIO of UART. In domotica-apparaten die op batterijen werken, zijn de controller en host vaak uitgevoerd in één chipset, en dan is de HCI geen fysieke, maar een logische interface.
Bluetooth Low Energy heeft een gelaagde architectuur. Bron: Bluetooth SIG
Data broadcasten
De software die uiteindelijk van BLE gebruikmaakt, doet dat via de bovenste lagen in het host-blok. Om het gebruik van BLE in domotica te begrijpen, is het minder belangrijk om exact te weten wat in welke laag gebeurt, maar moet je wel enkele sleutelconcepten kennen. De peripheral en central zijn de belangrijkste.
Een peripheral is een apparaat dat zijn aanwezigheid aankondigt door advertising packets uit te sturen en eventueel een verbinding toe te laten vanaf een ander BLE-apparaat. In zo’n advertising packet kan ook data verstuurd worden: 31 bytes in een pakket op een primary advertisement channel en 254 bytes in de andere kanalen. Een central kan luisteren naar advertisements en dus eventueel aanwezige data uitlezen. Omdat elk BLE-apparaat in de buurt deze pakketten kan ontvangen, is dit een vorm van broadcastcommunicatie. Dat gebeurt onversleuteld.
Een van de types advertising packets is manufacturer-specific data. Hierin kan elke fabrikant zijn eigen, al dan niet openbaar gespecificeerde dataformaat gebruiken. Bluetoothbeacons zijn een voorbeeld hiervan. Deze sturen via manufacturer-specific advertising packets een uuid, major en minor, en het zendvermogen op 1m afstand uit, zodat je telefoon de afstand tot het beacon kan bepalen. Ook allerlei sensoren maken gebruik van manufacturer-specific data, zoals de RuuviTag en Xiaomi Mijia-sensoren. Sommige van die laatste versleutelen overigens wel de advertising packets. Je hebt dan een ‘bindkey’ nodig om de sensordata te lezen.
De RuuviTag is een BLE-sensor die temperatuur, luchtvochtigheid en luchtdruk meet.
Verbindingen en services verkennen
Terwijl broadcasten een one-to-many-vorm van communicatie is die maar in één richting werkt, heeft BLE ook een one-to-one-vorm van communicatie in twee richtingen: verbindingen. Als een peripheral verbindingen accepteert, wordt dat met een speciaal type advertising packet aangeduid. Zo kunnen centrals in de buurt te weten komen met welke apparaten ze verbinding kunnen maken.
Een peripheral kan maar met één central tegelijk verbonden zijn, maar een central kan met verschillende peripherals tegelijk verbinding maken. Een verbinding is in BLE by design asymmetrisch; de central voert de zwaarste taken uit, zodat de peripheral zo weinig mogelijk stroom verbruikt en dus lang meekan op een batterijlading.
Een peripheral kun je beschouwen als een verzameling data en die data wordt in BLE gestructureerd volgens het Attribute Protocol, of ATT. Elk stukje data is een attribuut, met een type (een 16bit- of 128bit-uuid), een handle (een 16bit-adres), een waarde en permissies. Twee types attributen zijn belangrijk om in een verbinding toegang tot de data van een peripheral te krijgen: services en characteristics. In het Attribute Protocol wordt overigens niet meer van peripheral en central gesproken, maar van server (die de data heeft) en client (die de data wil lezen of schrijven).
Services en characteristics
Het generic attribute profile (afgekort tot GATT, omdat het anders dezelfde afkorting zou hebben als generic access profile, een andere laag van de protocolstack) definieert het formaat van services en characteristics en hoe je deze vindt en gebruikt. Elk stukje informatie, zoals een batterijniveau of een temperatuur, is een characteristic. Een characteristic staat nooit geïsoleerd, maar maakt altijd deel uit van een service. Een service is een groepering van een of meer characteristics die samen een specifieke functionaliteit van een apparaat definiëren. Zo heeft de service device information characteristics voor de naam van de fabrikant, het modelnummer, de firmwarerevisie en nog andere informatie van het apparaat. Veel services bevatten echter gewoon één characteristic, zoals de battery service die een battery level heeft.
Met nRF Connect kun je eenvoudig de services en characteristics van je BLE-apparaten in huis verkennenAls je de services en characteristics van je BLE-apparaten in huis eens wilt verkennen, kan dat eenvoudig met de mobiele app nRF Connect van Nordic Semiconductor, die bestaat voor Android en iOS. De app scant naar BLE-apparaten, toont je de advertisementdata en laat je verbinding maken met de apparaten. Zodra je verbonden bent, kun je de services verkennen en van alle characteristics de waarde lezen of schrijven.
Een client die altijd de recentste temperatuur of het recentste batterijniveau wil weten, kan in principe om de zoveel seconden of minuten de overeenkomstige characteristics uitlezen. Dan zou de server echter heel wat energie verspillen. Daarom kan een server bij een characteristic ook aanduiden dat hij notificaties ondersteunt. De client laat dan aan de server weten dat hij geïnteresseerd is in notificaties voor die ene characteristic, bijvoorbeeld de temperatuur, en de server stuurt dan alleen een bericht naar de client als de waarde van die characteristic verandert. Een variant zijn indicaties; dat zijn notificaties waarbij de client een bevestiging moet terugsturen dat hij de data heeft ontvangen.
Domoticaproducten met BLE en beveiliging
Heel wat BLE-producten hebben een bijbehorende mobiele app voor Android en/of iOS. Android heeft BLE-api’s sinds versie 4.3 van juli 2012 en iOS sinds versie 5 van oktober 2011. Die app neemt dan de rol van central op zich om met het product te communiceren, wat een vertrouwde interface voor gebruikers is. Vaak kan de app ook data die het van een BLE-sensor leest naar een clouddienst van de fabrikant sturen voor gemakkelijkere toegang later.
Hartslagmeters, fitnesstrackers, bluetoothtrackers en -beacons zijn allemaal al ingeburgerd. Er zijn ook heel wat ledstrips en ledlampen met BLE te vinden. Philips Hue, dat van Zigbee gebruikmaakt, heeft ook lampen die je op je smartphone via BLE kunt bedienen. Zo heb je geen Hue-bridge nodig.
Opvallend is dat BLE vanwege van zijn gebruiksgemak vaak wordt ingezet voor on-boarding van apparaten in andere netwerken. Zo introduceerde Thread 1.2 uit 2019 de mogelijkheid om via BLE met een smartphone een Thread-netwerk aan te sturen. En de wifilampen van WiZ gebruiken BLE om ze nog eenvoudiger te koppelen. Zo zie je dat zelfs concurrerende technologieën BLE omarmen, omdat ze de voordelen ervan niet kunnen negeren.
In Thread 1.2 kun je via BLE op je smartphone het Thread-netwerk aansturen. Bron: Thread Group
Beveiliging
De beveiliging van BLE ligt vaak onder vuur. Doorgaans gaat het om een zwakke implementatie in het product van het uitwisselen van sleutelmateriaal bij de eerste keer dat een verbinding wordt gemaakt. Het gaat hier om de pairingmethode. BLE Legacy-verbindingen (in BLE 4.0 en 4.1) zijn standaard kwetsbaar voor afluisteren en man-in-the-middleaanvallen. Er kan wel een out-of-band-pairingmethode gekozen worden; beide apparaten wisselen hun sleutelmateriaal dan via een andere weg dan BLE uit. Als die weg veilig is, is dit de veiligste methode voor BLE Legacy-verbindingen.
Sinds BLE 4.2 zijn ook BLE Secure-verbindingen mogelijk. Dan gebeurt het uitwisselen van sleutelmateriaal met het protocol Elliptic Curve Diffie Hellman, waardoor de gedeelde geheime sleutel niet af te luisteren is. Een extra pairingmethode, numeric comparison, genereert op het einde op beide apparaten een getal van zes cijfers om de apparaten te authenticeren. Door na te kijken of die overeenkomen, kun je verifiëren of er geen man-in-the-middleaanval aan de gang is. BLE biedt dus alle functionaliteit voor veilige verbindingen, maar veel apparaten hebben geen manier om cijfers te tonen, en pairing gebeurt in de praktijk vaak onveilig.
Specificaties
Een belangrijk voordeel van Bluetooth Low Energy is dat de documenten met officiële specificaties gratis beschikbaar zijn. Je kunt de specificaties gewoon downloaden van de website van de Bluetooth Special Interest Group, die toezicht houdt op de ontwikkeling van de bluetoothstandaarden.
Een belangrijk voordeel van BLE is dat de documenten met officiële specificaties gratis beschikbaar zijnDe Bluetooth SIG heeft heel wat services en characteristics gedefinieerd met hun uuid en naam. Daarom kan een app als nRF Connect namen zoals Heart Rate tonen in plaats van alleen 0x180D. Elke service heeft een eigen specificatiedocument. Daarin worden de characteristics van de service en hun gedrag beschreven. De uuid’s van die service en characteristics moet je weer in een ander document zoeken: het 16-bit UUID Numbers Document. Andere getallen en codes, zoals de company identifiers die worden gebruikt in advertisements met manufacturerdata, vind je op de pagina Assigned Numbers.
Profielen
In de specificaties van BLE vind je ook profielen, die elk in een eigen document zijn uitgelegd. Een BLE-profiel beschrijft het gedrag van zowel client als server in een specifiek gebruiksscenario. Zo heb je profielen als blood pressure, environmental sensing, human interface device, heart rate en weight scale. Een bloeddrukmeter, temperatuursensor, toetsenbord, hartslagmeter of weegschaal implementeert de serverrol van het relevante profiel, terwijl de app van de fabrikant de clientkant implementeert.
Als je wilt uitzoeken hoe je zo’n apparaat kunt aansturen in je domoticasysteem, komt het er dus op aan om de specificatiedocumenten van het desbetreffende profiel en de gebruikte services te raadplegen, samen met de nodige uuid’s. Je moet dan goed kijken wat het profiel van de clientrol verwacht, bijvoorbeeld op het gebied van verbindingsparameters. Dit gedrag kun je dan in je favoriete programmeertaal omzetten. Voor de populairste profielen vind je talloze opensourceprojecten die dat al hebben voorgedaan.
Zelf aan de slag en conclusie
Een nadeel van BLE is dat veel van de profielen vóór de grote opkomst van domotica zijn opgesteld. Erg talrijk zijn de profielen dan ook niet. Het staat fabrikanten echter vrij om hun eigen services en characteristics te definiëren, naast de door de Bluetooth SIG gedefinieerde services en characteristics. Die laatste hebben allemaal een uuid van de vorm 0000XXXX-0000-1000-8000-00805f9b34fb, waarbij XXXX de 16bit-verkorte uuid is. Fabrikanten bieden doorgaans geen specificatie aan, waardoor je de juiste betekenis zult moeten reverse engineeren.
Dat reverse engineeren kan op verschillende manieren. Het apk-bestand van de officiële Android-app kun je decompileren met een programma als jadx. Daarna zoek je in de Java-code welke gegevens er naar de karakteristieken worden geschreven of welke ervan worden gelezen. Een andere manier is dat je de officiële app met het apparaat laat communiceren en intussen het BLE-verkeer afluistert. Dat kun je live in Wireshark bekijken met een BLE-sniffer of je schakelt in de ontwikkelaarsopties van Android de Bluetooth HCI snoop log in, die je daarna in Wireshark kunt openen.
Ook manufacturer-specific data in advertisements zul je vaak moeten reverse engineeren. Aangezien die gebroadcast wordt, kom je daar gemakkelijker aan. Voor een temperatuursensor kijk je dan bijvoorbeeld welke waardes er op het schermpje of in de officiële app worden getoond, en vergelijk je dat met de gebroadcaste waarden. Dat is overigens voor populaire producten vaak al gebeurd. Sommige van die protocols zijn ook door de makers gedocumenteerd, zoals dat van de RuuviTag, Crownstones Bluenet of Apples Proximity Beacon Specification, beter bekend als iBeacon.
Als nRF Connect allemaal onbekende diensten toont, weet je dat je de taak van reverse engineering te wachten staat.
Zelf programmeren
BLE is een volwassen protocol dat op allerlei platforms een goede ondersteuning heeft. In Windows 10 is dat de Windows.Devices.Bluetooth-namespace, in Linux is de officiële bluetoothstack BlueZ en in macOS gaat het om de Core Bluetooth-api. Vaak gebruik je deze api’s niet rechtstreeks, maar via een bibliotheek in je favoriete programmeertaal. Een interessante cross-platform Python-bibliotheek die zowel Windows en Linux als macOS ondersteunt, is Bleak. Hiermee maak je eenvoudig een BLE-client van je pc of Raspberry Pi.
ESP-IDF (IoT Development Framework) van Espressif voor de ESP32 bevat een bluetooth-api. De hoststack is standaard gebaseerd op Bluedroid, dat zowel Bluetooth Classic als Bluetooth Low Energy ondersteunt, maar je kunt ook NimBLE gebruiken. Programmeer je de ESP32 liever in het Arduino-platform, dan kun je met NimBLE-Arduino werken. Ook ESPHome heeft gedeeltelijke ondersteuning voor BLE op de ESP32. Zo kun je advertisements ontvangen en zijn enkele specifieke sensoren ondersteund. Een volwaardige BLE-client en BLE-server zijn werk in uitvoering.
De nRF5-serie microcontrollers van Nordic Semiconductor is andere interessante hardware om met BLE te programmeren. De chips zitten onder andere in de BBC micro:bit en de RuuviTag. Nordic Semiconductor heeft heel wat opensourcesoftware en voorbeeldprojecten op zijn GitHub-pagina staan. Het bedrijf is de laatste jaren actief in Zephyr, een realtime besturingssysteem van de Linux Foundation dat uitstekende documentatie over BLE heeft en heel wat voorbeeldcode. Ook Mbed en Apache Mynewt, waarvan de NimBLE-bibliotheek komt, hebben ondersteuning voor BLE.
Mbed is een van de embedded besturingssystemen met ingebouwde ondersteuning voor BLE.
Je kunt je fantasie de vrije loop laten wat projecten waaraan je kunt werken betreft. Een voorbeeld is een dashboard voor temperatuur, luchtvochtigheid en luchtdruk op basis van de eerder genoemde RuuviTag-bluetoothsensor. Zo kun je BLE van de sensoren uitlezen met een Raspberry Pi via bt-mqtt-gateway, waaraan je RuuviTag-ondersteuning moet toevoegen. Ook met de M5Stack M5Core2 zijn leuke dingen te doen. Dit is een developmentkit gebaseerd op een ESP32 met onder andere een ingebouwd touchscreen en tal van sensoren. Een voorbeeld van een gebruikerstoepassing is de M5Core2 Heart Rate Display, om tijdens het fitnessen met een borstband de hartslag op een schermpje voor je te tonen.
Conclusie
De bekendste draadloze domoticaprotocols zijn allemaal meshnetwerken, maar Bluetooth Mesh lijkt voorlopig meer succes te hebben in de industrie en in kantoren dan in huiskamers. Voor domotica is het nog lang niet zo populair als Zigbee, Z-Wave en Thread. Nu zowel Google en Apple als Amazon zich achter Thread scharen, lijkt het momentum van Bluetooth Mesh voor domotica voorbij.
Het niet-meshgedeelte van Bluetooth Low Energy blijft echter een toekomst hebben in domotica. Het is geen toeval dat zowel Thread als heel wat wifilampen gebruikmaken van BLE om via je smartphone apparaten toe te voegen, en dat Philips Hue ook BLE-lampen heeft geïntroduceerd. BLE is een technologie met een lage drempel, ook voor domoticahobbyisten, en wordt breed ondersteund.
Mooi Plus artikel! Ook bij Domoticz blijkt BLE al gearriveerd te zijn, zoals bijvoorbeeld voor aanwezigheid detectie aan de hand van Bluetooth beacons: https://www.domoticz.com/...th_4.0_Low_energy_Beacon).
En ook een plantsensor wordt via BLE verbonden: https://www.plantsensor.nl/.
Leuk om als tweaker te kijken wat dit weer voor mogelijkheden geeft. Een temperatuursensor die 10 jaar geen batterijwissel nodig heeft lijkt mij bijvoorbeeld wel wat. Nu is het periodiek batterijen wisselen in huis.
Edit: ik zie dat een Bluetooth mesh gateway al voor minder dan 30 euro beschikbaar is: https://www.hlhv.nl/Webwi...et-Alexa-Google-Home.html.
De uitdaging is om dat met Domoticz of een ander systeem wat tweakbaar is draaiend te krijgen
[Reactie gewijzigd door Frij5fd op 22 juli 2024 14:36]
In mijn woning heb ik een professionele (bedrade) KNX domotica-installatie en ook een Zigbee-componenten (Philips Hue, Ikea Trådfri). Die Zigbee-componenten werkten nooit betrouwbaar: meerdere keren per maand reageerden lampen niet meer op de afstandsbediening, verloren ze contact met de bridge, of was er opeens een batterij leeg. Voor verlichting vind ik die onbetrouwbaarheid onacceptabel. Als je het licht aan doet, behoort de lamp altijd te gaan branden, niet meestal. En ook oma moet het kunnen bedienen, zonder dat ze eerst een toelichting moet krijgen het het werkt. Pas toen ik alleen Hue-lampen ging gebruiken en deze via een bridge verbond met de bedrade KNX bedienknoppen in huis gingen de lampen betrouwbaar werken.
Als je maar genoeg apparaten op batterijen in huis hebt, zal er altijd een apparaat zijn met een lege batterij. Of dat nou de RFID-sensor in het kattenluik is of de draadloze sleutel voor je auto, vaak krijg je pas door dat een batterij leegraakt wanneer je een patroon begint de herkennen: de kat komt telkens niet binnen, de auto wordt pas ontgrendeld als je ernaartoe loopt en er vlak naast staat. Het vervelende is dat je vooraf meestal niet een duidelijke foutmelding hebt ontvangen dat de batterij leeg begint te raken en dat je actie dient te ondernemen. Dat maakt een huis vol draadloze apparaten in de praktijk foutgevoelig en onderhoudsgevoelig.
De combinatie van draadloos bedienbaar én werkend op batterijen is voor individuele apparaten vaak een mooie oplossing, maar je kunt maar beter niet een huis vol van dergelijke apparaten hebben. Bedraad is ouderwets, vaak onmogelijk om aan te leggen in een bestaande situatie, maar wel zeer betrouwbaar en onderhoudsarm. Voor professionele domotica zijn dat toch basisvereisten, die door grotere draadloze domotica-installaties onvoldoende worden vervuld. Ik ben daarom heel geïnteresseerd in de ontwikkelingen bij BLE, maar sta nog niet te trappelen om mijn huis ermee vol te hangen.
[Reactie gewijzigd door Tomatoman op 22 juli 2024 14:35]
Ik ben het grotendeels met je eens. Bekabeld is nog altijd beter dan draadloos.
Ik heb gebruik zelf BLE, Zwave en Zigbee. Dat laatste is zeker goed voor 80% van mijn domotica setup en een groot deel daarvan zijn battery operated devices. Ik schat dat het er zo'n 30 zijn. Wat jij zegt herkende ik al te goed. Soms ging een device offline zonder dat je van te voren wist dat de batterijen aan het leeg raken zijn. Ja, er is vaak informatie over het batterijniveau aanwezig, maar die is ook vaak niet accuraat. Het hangt denk ik af van de fabrikant en de implementatie van batterij status.
Ik heb inmiddels een tweetal zaken geleerd, waardoor ik tegenwoordig geen last meer heb van devices die zomaar offline gaan of dat ik er te laat achter kom.
1. Koop geen huismerk knoopcellen die je vaak bij de Xenos, Action, Blokker of ander soortgelijke winkel kan vinden. Deze zijn vaak al half leeg voordat je die überhaupt in gebruik gaat nemen. Ik koop tegenwoordig verschillende typen knoopcellen van Murata . Deze heeft jaren geleden de batterij divisie van Sony overgenomen. Erg content mee, aangezien deze bijna eindeloos meegaan.
2. Focus niet op monitoring van battery levels, maar op de tijd dat een device zich niet meer heeft gemeld. Voor de meest gebruikte sensoren zet ik bijvoorbeeld de tijd strak. Ik heb dit zodanig getuned dat ik geen false-positives ontvang. In HA kijk ik naar de last-updated field.
[Reactie gewijzigd door Aurora op 22 juli 2024 14:35]
Als ik je reactie lees, dan snap ik aan de ene kant de richting van je argumenten... Aan de andere kant maak ik er graag een kanttekening bij uit eigen ervaring (Zigbeenetwerk van 60 apparaten, 32 op batterij, middelgrote woning), waardoor het ook flink te relativeren valt.
Die Zigbee-componenten werkten nooit betrouwbaar
Ga je ecosystemen mixen, dan mag je niet meer 100% verwachten dat alles perfect gaat werken. Hue werkte hier altijd perfect. IKEA op Hue minder. IKEA los weet ik niet. Kies je de echte custom aanpak zoals met Zigbee2MQTT, dan moet je soms aan de slag om het goed werkend te krijgen, dat kan vervelend zijn maar als je eenmaal het punt bereikt hebt van stabiliteit dan is het helemaal prima en heb je een prachtige dekking. Je hebt dus door eigen keuzes en configuratie een grote invloed op die betrouwbaarheid.
Als je maar genoeg apparaten op batterijen in huis hebt, zal er altijd een apparaat zijn met een lege batterij
Een beetje een dooddoener die wel erg ver van de praktijk af staat. Qua batterijen kan ik de tips van @Aurora bevestigen. Action knoopcellen werken hier meestal niet, letterlijk. Maar Panasonics gaan 1,5-2 jaar mee in allerlei soorten sensoren, zolang ze in een omgeving met niet koude temperatuur gebruikt worden, ~14+ graden. Dus het geschetste beeld dat je veel bezig bent batterijen te vervangen hoeft niet waar te zijn.
Ik houd niet van draadloos en heb genoeg netwerkkabels in het zicht door huis lopen, maar als ik zie hoe goed Zigbee hier eigenlijk werkt, dan kan ik er niet omheen om te concluderen dat dat gewoon prima is. Daarom vind ik het argument dat 'bedraad een basisvereiste van professionele domotica is' gewoonweg onwaar. Nouja, het ligt aan hoe je 'professionele domotica' invult natuurlijk, maar ik denk dat ik wel aardig die kant op ga ondertussen... Ook ik zal voor bedraad blijven kiezen waar het kan, maar draadloos kan je niet afschrijven.
Al met al, als je Philips Hue neemt zit je goed. Als je voor een geavanceerdere aanpak gaat moet je ook de verantwoordelijkheid nemen voor een goede dekking, configuratie en batterijen.
[Reactie gewijzigd door Saturnus op 22 juli 2024 14:35]
Het vervelende is dat je vooraf meestal niet een duidelijke foutmelding hebt ontvangen dat de batterij leeg begint te raken en dat je actie dient te ondernemen.
Omdat je eerder Hue en Tradfri noemt ga ik ervan uit dat dit punt over Zigbee gaat.
De meeste zo niet alle Zigbee apparaten die op batterijen werken rapporteren de status inclusief een percentage. Bij sommige bevat de payload zelfs het type batterij en het aantal stuks. Voor Hue kan je in de iConnectHue app de actuele batterijstatus zien van alle dimmers en motionsensors bij elkaar en krijg je een melding als er een bijna leeg is. Al is dat niet heel accuraat. De status blijft jarenlang op 100% staan. Als het na 4 jaar gaat dalen kan je er vanuit gaan dat het over een paar maanden leeg is. Ik heb daarvoor in Homey een alert ingesteld als een batterij onder de 80% komt.
Daarnaast zijn er ook batterijloze dimmers beschikbaar voor Hue. Die werken met kinetische energieopwekking en gaan dus nooit leeg.
Ik heb dezelfde ervaringen met devices op batterijen. Maar moet zeggen dat alle Zigbee apparaten die op netspanning zitten aangesloten over het algemeen rocksolid zijn.
Hetzelfde verhaal voor de ESP32 zelfbouw(wifi) apparaten en de vele Shelly's die ik in huis heb: super stabiel(maar je moet zelf voor goed wifi bereik zorgen natuurlijk ).
Als je met de Xiaomi plant sensoren aan de slag wilt gaan, zeker doen! Werkt top.
Zoals het artikel al aangeeft, het bereik van BLE is ruk. En je planten staan doorgaans door het hele huis. Ik gebruik zelf Pi Zero's, die ik al zoiezo had draaien, met dit:
Ik heb plant modules op basis van ESP32, dus WiFi. EspHome doet periodiek (heb ik op 30 minuten gezet) data versturen zodat deze de WiFi verbinding niet continue actief hoeft te houden. Ik heb 8 plant modules en de CR3032 batterijen heb ik nog steeds niet hoeven te vervangen..
Als je veel WiFi devices hebt, is het wel raadzaam om een WiFi mesh netwerk op te zetten en het Access Point van je internet modem/router ter vermijden. Deze werkt in de regel goed met een handvol connect devices, maar niet met tientallen..
Wat wellicht heel logisch lijkt, vergeten toch een heleboel mensen. Namelijk dat een goed functionerend mesh netwerk een stabiele backbone nodig heeft.
2,5 jaar terug ben ik begonnen met een mengelmoes van protocollen in mijn huidige woning, maar hoofdzakelijk z-wave, ondanks dat er veel mensen met problemen zijn waar het te pas en te onpas niet zou werken. Bij mij werkt alles zodra ik op de tablet de knop in druk, met een aantal milliseconden vertraging.
De reden waarom het bij mij zo stabiel is, al mijn lichtschakelaars door het hele huis zijn vervangen door vaste Z-wave schakelaars, continu op de netstroom en werken als de backbone/repeaters door het hele huis voor alle devices die op batterij functioneren.
Dit zelfde principe heb ik voor Zigbee (Philips Hue) gedaan, de z-wave lichtschakelaars blijven altijd aan in geval er een Hue lichtpunt achter zit, zo houd je een stabiele always-on backbone voor Zigbee op netstroom.
Alles valt en staat bij het ontwerp wat je implementeert, zo zul je voor BLE ook goed na moeten denken hoe je een goede backbone op het lichtnet krijgt zodat de apparaten op batterijen nooit een belangrijke hop vormen om de mesh in stand te houden.
BLE leent zich wat mij betreft echt niet voor smart home oplossingen. Doordat alle devices relatief dichtbij de initiator moeten blijven. Devices zelf kunnen onderling geen “mesh” opzetten waardoor het bereik echt beperkt is.
Veelbelovend op dat vlak is Thread. Een op IPV6 low energy gebaseerd protocol, waar een aantal bedrijven zoals Apple, Google, Osram, Somfy achter zitten.
Ja, maar ik heb Mesh nog nooit gezien in een product. Ik heb overigens een tijd gewerkt met Bluetooth Mesh en vond het zeer complex om te implementeren vergeleken met 'standaard' Bluetooth.
Ik heb momenteel een aantal temperatuur sensoren op BLE die binnenshuis wel werken maar in de tuin hebben ze al geen signaal meer, hoe dicht ik ze ook plaats bij de ontvanger (die binnen staat). Als een enkele muur al genoeg is om het signaal volledig te stoppen zie ik niet hoe Mesh dit gaat verhelpen.
Het BLE device weet niets van een mash netwerk af. Net zoals jouw smartphone ook niet weet dat het met een WiFi mesh access point connect. Wifi mesh access point zijn eigenlijk geavanceerde repeaters met dien verstande dat het mash point zelf de verbinding beheerd, maar data zoals DHCP naar het hoofd access point gaat.. Hierdoor kun je zonder problemen honderden wifi devices op je netwerk hebben..
Zelfde gaat op een BLE mesh device. Het zorgt ervoor dat je bereikt wordt vergroot..
Hoe gaat mesh jouw helpen? Je plaatst simpelweg je BLE mesh device aan de andere kant van de muur, bijvoorbeeld onder het afdakje van een schuur.. De meeste apparaten met BLE hebben echter maar zeer beperkt vermogen en daar zit het grootste probleem. Minder zend vermogen = minder bereik..
Veel zigbee en z-wave devices welke continue spanning hebben (zoals gateways, relays en lampen) acteren als een mash hub. Als je dus in elke ruimte een zigbee lamp ophangt, dan heb je ineens een heel erg sterk zigbee netwerk..
Ik kan het device niet verplaatsen. Als de effectieve afstand tussen twee nodes niet veranderd dan helpt mesh niet om het bereik te vergroten. Er zit helaas geen node tussen ontvanger en receiver. Daarnaast ondersteunt geen van de devices überhaupt mesh
Lijkt wel leuk om eens mee aan de slag te gaan. Ik draai nu thuis een lorawan/thethingsnetwork met eigen gateway. Vooral de range is erg prettig. Maar nadeel is dat je altijd vast zit aan de gateway en de Cloud, ik draai liever alles thuis. De Arduino based sensor nodes zijn ook niet heel anders dan voor BLE lijkt mij. Oké er moet ESP bij op en de RF moet eraf, maar dat is niet echt een probleem.
Hoe groot zijn de lib’s? Passen die op een Arduino mini?
Ik draai thuis toch al een NUC als centrale server met een Pi voor wat ander spul. BLE voelt zeker voor de hobby/thuis wat handiger dan LoRaWAN. En mogelijk nog belangrijker, iets anders om mee te gaan knutselen, dat is net zo belangrijk 😀
Hum, thanks. nooit naar gekeken eigenlijk. Vond Thingsnetwork wel handig, dat was een beetje mijn start zeg maar en tot nu sla ik uiteindelijk alles thuis op in InlfuxDB. Nu al dikke 2 jaar data beschikbaar
chirpstack ga ik maar eens even induiken.
Kan mijn namelijk niet voorstellen dat BLE de afstanden gaat overbruggen die ik met LoRa wel kan halen. En dat is juist zo leuk, beetje meetingen over veel groter oppervlak dan allen je eigen huis en tuin.
Kan mijn namelijk niet voorstellen dat BLE de afstanden gaat overbruggen die ik met LoRa wel kan halen. En dat is juist zo leuk, beetje meetingen over veel groter oppervlak dan allen je eigen huis en tuin.
In deze reactie kan ik me 101% in vinden. Meer mensen zouden LoRa eens moeten ontdekken. Helium is momenteel ook groot aan het worden, en met de blockchain configuratie als ruggesteun is het een ontwikkeling om in de gaten te houden.
Het werkt problematisch. De centrale moet wel in bereik zijn van alle sensoren en andere BLE apparaten. En mijn ervaring is dat BLE niet of nauwelijks door gewapend beton heen komt, of door ramen met een hitte coating. In kantoortuinen zoals in het artikel staat heb je daar veel minder last van.
Het mesh stukje benieuwd me wel maar ze melden ook dat apparaten een zuinigere versie aan boord hebben en de controlekast een sterkere minder zuinige versie. Dan lijkt mesh me niet goed te werken. Dat is ook de reden dat bij zigbee en zwave batterij apparaten eind stations zijn in het mesh.
Idee van Bluetooth Mesh is dat je een lighting backbone hebt die aan 100 % duty cycle werkt (i.e. veronderstellend dat je verlichting mains-powered is). Daar hang je dan bv. batterijgevoede devices aan, die niet aan 100 % duty cycle moeten opereren om deel te kunnen uitmaken van de mesh. Ze onderhouden een zogenaamde 'friendship' met een node uit de backbone, die berichten bestemd voor de batterijgevoede devices kan bijhouden tot ze er om vragen.
Zelfs in mijn niet al te grote, oude woning is BLE niet sterk genoeg om overal bereik te hebben. Dat maakt het erg beperkt bruikbaar. Zigbee en WiFi daarentegen zijn gewoon prima betrouwbaar. De temperatuursensors binnen doen meer dan een jaar met de batterij, dat is prima te doen. Buiten moeten ze wat vaker vervangen worden, maar de sensors zijn dan ook eigenlijk niet voor buiten bedoeld.
Bluetooth in het algemeen is leuk wanneer zender en ontvanger statisch op korte afstand van elkaar zijn, zoals een telefoon en een carkit, of een telefoon en een speaker.
Voor de rest is Bluetooth gewoon ruk terwijl het overal als heilige graal ingezet word maar in de praktijk alleen maar tot frustraties leid.
Te vaak word BT ingezet voor oplossingen waarin 1 van de 2 partijen veel van locatie en afstand wisselt.
Een mooi voorbeeld zijn de bbq thermometers op BT Leuk als je met de telefoon in de hand naast je bbq staat om zo op de app de temperatuur van je steak te zien. Totdat je naar je keuken loopt om een potje bier te pakken. Blijkt de verbinding ineens weg te zijn.
Ik ben mij ervan bewust dat ik een iets groter huis heb dan gemiddeld, maar als ik hier een fatsoenlijk mesh netwerk met BT zou willen opbouwen, mag ik elke kamer behangen met sensors/beacons.
Ik zal direct toegeven: ik heb nog nooit BLE mesh gebruikt, simpelweg omdat ik er nul vertrouwen in heb en er betere alternatieven zijn zoals zigbee of wifi. Een zigbee meshed ook uit zichzelf, en op een veel grotere afstand dan Bluetooth.
Wat is "op korte afstand"? Ik heb mijn laptop wel eens 2 verdiepingen hoger staan dan mijn bluetooth-speaker, bijv. als ik 2 verdiepingen lager aan het schoonmaken ben, en geen enkel probleem.
Ik heb het niet echt voor die smart home gadgets; WiFi, BlueTooth, Zigbee, RF, Z-Wave ... Heb het allemaal in huis en het geeft mij alleen maar werk. Stabiliteit zowel van producenten (Hue) als custom developement (Home Assistant) is bedenkelijk. Je zit dikwijls met vendor lock-in (geen updates na x jaar) en het werkt niet zo eenvoudig samen.
Ja ik weet dat ik hiervoor naar KNX moet, maar bij renovatie is dat moeilijker en dan nog... eens je met apps begint.
Ik bouw mijn huis steeds meer vol met sensoren met LoRaWAN. Al is de sensor 1 km weg heb ik nog bereik. Zowel op TheThingsNetwork en Helium en local een Chirpstack setup. Werkt als een trein, mqtt/http intergratie. een aanrader.
[Reactie gewijzigd door arnord op 22 juli 2024 14:35]
/i/2004213736.png?f=imagenormal)
/i/2004213740.png?f=imagenormal)
/i/2004215806.png?f=imagegallery)
:strip_icc():strip_exif()/i/2004584384.jpeg?f=fpa_thumb)
:strip_icc():strip_exif()/i/2004494268.jpeg?f=fpa_thumb)
:strip_icc():strip_exif()/i/2004163462.jpeg?f=fpa_thumb)
:strip_icc():strip_exif()/i/2002944894.jpeg?f=fpa_thumb)
:strip_icc():strip_exif()/i/2001735733.jpeg?f=fpa_thumb)
:strip_icc():strip_exif()/i/2000589285.jpeg?f=fpa_thumb)
/i/2001711701.png?f=fpa)
:strip_icc():strip_exif()/u/474290/crop5612d647692a7.jpeg?f=community){kind=small}
:strip_exif()/u/15310/tomato60%252072%2520frames%25205%2520deg%2520per%2520frame%2520optimized%252026%2520colors.gif?f=community){kind=small}
:strip_icc():strip_exif()/u/151605/1201277976.jpg?f=community){kind=small}
/u/137180/TS4YTL60R.png?f=community){kind=small}
:strip_icc():strip_exif()/u/54320/crop66d223ef9f585_cropped.jpg?f=community){kind=small}
:strip_icc():strip_exif()/u/249570/twitter-icon.jpeg?f=community){kind=icon}
/u/550928/crop6048843c4bcce_cropped.png?f=community){kind=small}
/u/581347/crop64beea7e7f624_cropped.png?f=community){kind=small}
/u/414606/crop61fc2908c41cc_cropped.png?f=community){kind=small}
:strip_icc():strip_exif()/u/385679/crop5a2cfd5984e3a_cropped.jpeg?f=community){kind=small}
:strip_icc():strip_exif()/u/10517/nwkoffie.jpg?f=community){kind=small}
:strip_icc():strip_exif()/u/277895/crop5eda5f3273e75_cropped.jpeg?f=community){kind=small}