Xiaomi brengt later dit jaar eerste Aqara-sensoren met Thread-ondersteuning uit

Xiaomi brengt later dit jaar Aqara-sensoren uit die ondersteuning hebben voor de smarthomestandaard Thread. De deur- en raamsensoren en de bewegingssensor komen in de tweede helft van het jaar uit. Ook krijgen de Zigbee-hubs ondersteuning voor Matter.

Aanvankelijk brengt het bedrijf alleen nog die twee specifieke sensoren uit. Aqara, een dochterbedrijf van Xiaomi, maakt nog veel meer sensoren, zoals een watersensor en een temperatuurmeter, maar over een upgrade daarvan meldt Xiaomi niks. Doordat de apparaten Thread ondersteunen zijn die volgens de fabrikant betrouwbaarder, en gaan ze lang mee op een enkele knoopcelbatterij.

Thread is een relatief nieuw verbindingsprotocol dat gaat werken met Matter, de nieuwe smarthomestandaard die grote bedrijven zoals Apple, Google en Amazon in de toekomst verder willen ondersteunen. Door Thread te ondersteunen kunnen Matter-gebruikers in de toekomst ook Aqara-sensoren in hun netwerk gebruiken.

Aqara gaf eerder al aan dat het de Aqara-hubs wilde voorzien van Matter-ondersteuning. Het bedrijf zegt nu dat dat naar de M2- en de oudere M1S-hub komt via een over-the-air-update, maar wanneer dat gaat gebeuren is nog niet bekend. Gebruikers kunnen na die update Thread- en Zigbee-apparaten naast elkaar gebruiken op de hubs.

Reacties (50)

Dus weer een nieuw protocol erbij naast zigbee en zwave? Ik ben juist zo blij met zigbee2mqtt. Ik hoop dat er van voor Thread ook een soort van zigbee2mqtt uitkomt. Al zit ik eigenlijk niet te wachten op weer een protocol. Liefst alles 1 zodat het bereik goed is.

Volgens mij is Thread niet zo zeer een losstaand protocol als de opvolger van Zigbee en onderdeel van de Matter standaard. Thread is in zekere zin de ipv6 versie van Zigbee met nog wat andere voordelen.

Wel grappig trouwens dat je aangeeft: ik wil geen nieuw protocol, maar ik wil alles in 1. Juist dat je Z-wave, Zigbee, via Wi-Fi, via Bluetooth hebt zorgt er voor dat een apparaatje om Home Assistant te draaien exorbitant duur is. Eerst moet je er eentje vinden, daarna 400 dongles er aan om te zorgen dat het werkt.

Zullen Thread en Matter de laatste en enige standaarden zijn, waarschijnlijk niet. Maar dat er een poging wordt gedaan het wilde westen aan smart home samen te voegen en dat onder andere Zigbee (en volgens mij Z-wave, maar dat is volgens mij uberhaupt iets minder bekend onder het algemene publiek) daar voor open staat lijkt me alleen maar goed.

[Reactie gewijzigd door Globber op 6 januari 2022 10:17]

Is er dan ook backwards/forwards compatibility? Als in, werken Zigbee apparaten met Thread, of Thread apparaten met Zigbee? Beetje zonde als je je lampen moet weggooien omdat het niet meer compatibel is.

In theorie zouden veel van de huidige zigbee hardware ook matter/thread compatible gemaakt moeten kunnen worden met een firmware update. Of dat ook gebeurt zal voornamelijk afhangen van de fabrikant. Xiaomi heeft in tegenstelling tot andere fabrikanten zoals Ikea en Signify (Philips Hue) nog nooit een zigbee apparaat van nieuwe firmware voorzien en/of publiceert die in ieder geval niet. Een goed voorbeeld is de mgm210p chip die gebruikt word in Home Assistant Yellow. Daarvan heeft de fabrikant Silicon Labs al aangegeven dat die in de nabije toekomst matter/thread compatible te maken is met een firmware update. Ook Signify heeft al aangekondigd met firmware updates te komen die hun lampen en hubs Matter compatible maken.
[EDIT] Zoals @LDVC aangeeft blijven de Hue lampen zigbee en zal een update van de Hue hub compatibiliteit met Matter implementeren.

[Reactie gewijzigd door SqyD op 6 januari 2022 12:08]

Signify heeft aangekondigd dat de hub matter-compatible wordt en daarmee worden de lampen indirect ook matter-compatible. De lampen zelf blijven echter (enkel) via Zigbee communiceren.
(Zie ook eerste comment in het artikel dat je aanhaalt)

Dat is netto niet echt een andere oplossing dan wat veel van de huidige oplossingen zoals Home Assistant of Node Red ook doen: het aan elkaar knopen van meerdere omgevingen. Dat zou ik geen compatibel noemen. Een van de issue is dat dit in potentie integraties in de weg zit, omdat je afhankelijk bent van een gateway. Zo heb ik bijvoorbeeld een aantal Hue IR sensoren niet op de Hue hub aangesloten, maar op een apart (open) zigbee platform, om de responsetijd hiervan te verlagen voor zaken die buiten Hue vallen. Binnen de Hue bridge was dat nog wel te doen, maar de interface naar buiten zat teveel vertraging in.

Matter is 'eenvoudig' toe te voegen gezien het niet afhankelijk is van specifieke hardware. Daarom zie je veel fabrikanten deze standaard toevoegen.

Thread is een complexer verhaal:
Thread uses 6LoWPAN, which, in turn, uses the IEEE 802.15.4 wireless protocol with mesh communication, as does Zigbee and other systems
Dus een Thread device gebruikt wel dezelfde 'radio' als Zigbee maar je kunt een Zigbee apparaat niet zomaar updaten naar Thread. De chip moet daarvoor ook ondersteuning bieden (en huidige Zigbee chips doen dat niet zover ik weet). Daarom zie je bijvoorbeeld dat Philips Hue de hub compatible maakt met Matter maar de lampen niet (kan) updaten naar Thread.

Ik moet eerlijk zeggen dat ik dat niet weet, maar ik verwacht van niet aangezien het gewoon anders werkt.
Maar dan is dus meer de vraag, waarom is de eerste reactie weggooien? Het is best logisch dat er een overgangsperiode is waarin je de systemen naast elkaar draait lijkt me.

Persoonlijk zie ik niet direct een groep gebruikers waarvoor het samenwerken geen probleem zou zijn, aangezien bijvoorbeeld Hue wel gewoon Matter gaat ondersteunen. Dus nee de lampen praten niet met elkaar op dezelfde manier, maar de standaard van aansturing is er wel.
Echte enthousiasten hebben waarschijnlijk toch een eigen servertje draaien, en de rest van de consumenten gebruikt de meegeleverde hubs (en zolang die met Matter werken kan dat dus samenwerken).

Dus ja je lampen weggoien is zonde, maar een beetje hetzelfde als iedere 2 jaar een nieuwe smartphone kopen. Leuk om te doen, maar totaal onnodig en vooral veroorzaakt door de drang om alles nieuw en hetzelfde te hebben.
En nogmaals, ik denk dat een standaard aanbrengen goed is, maar het is goed om realistisch te blijven. Een standaard is niet in 1x vervangen, en je huis hoeft niet in 1 klap van Zigbee naar Thread. Dat betekent echter niet dat het niet goed is om het proces te starten, er is immers helemaal niks in deze wereld wat in 1x over is op een ander systeem, zeker niet iets wat bij miljoenen of zelfs miljarden mensen in huis staat.

Krijg het idee dat al deze systemen nog in het hobby circuit zitten en soms in pro.

Probleem lijkt me als je iets wil installeren in je huis wil je gewoon dat het over 5 10 15 jaar nog gewoon werkt en niet dat je na 7 jaar alles moet vervangen omdat de cloud connectie niet meer werkt of het geen updates meer krijgt. Dit laatste vindt ik het probleem van al dit soort smart dingen, het is uiteindelijk duur speelgoed met vaak een beperkte levensduur.

Maar hoezo denk je dat? Philips Hue lampen zijn niet voor niks zo'n succes, niet omdat ze gericht zijn op de niche hobbyisten maar op de grotere markt. Die mensen hoeven niet direct lampen weg te smijten omdat er een nieuwere standaard is natuurlijk.

Daarnaast is je verhaal over de cloud natuurlijk wel waar, maar totaal irrelevant voor de discussie waar je op reageert. Zigbee heeft niks met cloud te maken, en je hoeft je lampen niet weg te gooien zodra Thread er is omdat Zigbee op zichzelf niet afhankelijk is van internet (en de lampsystemen die ik ken ook niet). De beperkte levensduur komt vooral voort uit de drang voor het nieuwste, je Philips Hue lampen blijven echt nog wel werken als er geen nieuwe Zigbee apparaten meer komen, om ze allemaal te vervangen zodat je 1 hubje minder hebt is dan een keuze die je zelf maakt maar heeft niks met levensduur te maken.

zoals deze: https://www.iculture.nl/n...opt-oude-ronde-bridge-v1/
2012 uitgebracht 2019 geen updates meer en stop daarna met werken. Voorbeeld dus wat ik boedel, na 8 jaar kun je componenten gaan vervangen. Leuk voor de hobbyist maar als je huiseigenaar bent wil ik gewoon dat het na 8 jaar werkt en niet vervangen moet worden om het te laten blijven werken.

Oude bridge eruit, lampen koppelen aan nieuwe bridge, en weer door. Alle lampen doen het nog steeds. Heb je dit probleem zelf ervaren, of heeft het je afgeschrikt hier aan te beginnen ? Ik weet niet eens meer of ik de lampen opnieuw moest koppelen of dat het een migratie was waarin de devices via het account in nieuwe hub geplaatst werden.

Put blijft je moet wat gaan vervangen. Je praat als een tweaker die het zelf even snel doet. Daarmee bevestig je dus mijn punt leuk voor de hobby markt en mensen die er mee willen spelen. Genoeg mensen die het hebben maar niet willen/kunnen onderhouden. Dan moet je die mensen als je iets verkoopt uitleggen na x jaar, nieuwe bridge kopen, tenminste als je daar als verkoper ondersteuning voor geeft.
Misschien bestaat de verkoper niet meer, klant merkt werkt niet meer, moet iemand laten komen, kost geld die dan verteld ja maar je moet nu dit al gaan vervangen.
Maar ja het is toch niet kapot, nee de fabrikant heeft besloten het niet meer te ondersteunen en u moet een nieuwe bridge kopen.
Maar wie weet gaat deze nieuwe langer dan 8 jaar mee of stopt de fabrikant na 5 jaar met ondersteuning en werkt alles niet meer.

Dus nee de lampen praten niet met elkaar op dezelfde manier, maar de standaard van aansturing is er wel. Echte enthousiasten hebben waarschijnlijk toch een eigen servertje draaien, en de rest van de consumenten gebruikt de meegeleverde hubs (en zolang die met Matter werken kan dat dus samenwerken).

Het probleem is dat je complete mesh-network van zigbee-apparaten de nieuwe thread-messages niet kan horen/doorgeven, dus is er voor voor thread-apparaten geen mesh network.

Je kan dus niet een nieuw thread-apparaat kopen en die in de schuur ophangen waar het afhankelijk is van je mesh-network, totdat je tussenliggende zigbee-meshes hebt vervangen door compatibele meshes.

[Reactie gewijzigd door Redsandro op 6 januari 2022 15:14]

Ik denk het niet, er zijn wel chips die beide ondersteunen zoals de nrf52840. Als het dus ondersteund wordt door de chip en de fabrikanten een firmware update maken is het misschien mogelijk, maar wel onwaarschijnlijk. Ik heb zelf ook nog niets gezien dat thread en zigbee tegelijk ondersteund, wel ble+thread of ble+zigbee.

Het is vooral van belang dat de gebruikte hub/bridge ondersteuning voor Matter/Thread krijgt. Zoals Signify heeft aangegeven zal de Hue Bridge alle aangesloten devices via Matter exposen naar de buitenwereld, maar de communicatie tussen bridge en lampen/accesoires zal voor de voorziene toekomst via Zigbee blijven verlopen.

Ik ben een groot voorstander van een overkoepelend protocol als Matter, het is alleen zeer jammer dat de Matter Connectivity Standards Alliance enorm duur is, vooral voor de kleine spellers, die de leukste innovatieve producten maken.

Maar dan heb je het over de kosten van het CSA alliance (die overigens voorheen Zigbee was, dus ditzelfde argument ging toen ook op). Dan heb je het echt over het certificeren van producten, en dan is 7000 dollar op jaarbasis niet zo veel aangezien je dan waarschijnlijk op enige schaal gaat produceren dus heb je wel wat meer kapitaal nodig.

De Matter standaard zelf is open source (https://github.com/project-chip/connectedhomeip) dus voor kleinere spelers komt er vast een manier om wat hobby apparaatjes te maken die werken met Matter zonder een stickertje er op te hebben.

Soort van zigbee plus? Heb momenteel alleen zigbee en zwave. Dus valt mee met al die dongel.

Zigbee is ook niet fantastisch, het bestaat namelijk weer uit een aantal onderliggende sub-protocollen (ZLL, ZHA, Zigbee Pro, ..) die vaak niet zo lekker met elkaar communiceren. Een zigbee mesh netwerk dat bijvoorbeeld door Hue lampen gecreërd wordt, kan weer niet gebruikt worden door innr (die ook gebruikt maakt van Zigbee).

Ik denk dat Thread, in combinatie met Matter, een veelbelovend protocol is dat eindelijk een oplossing gaat zijn voor slimme huizen.

De Innr lampen werken ook minimaal met de Tradfri lampen van Ikea.
De afstandsbediening van Tradfri waarmee je de kleur en helderheid kunt aanpassen werkt alleen maar met de helderheid.
Met de Tradfri afstandsbediening kan je dan wel de Ikea en Innr lampen tegelijk aan/uit zetten en dimmen, maar niet van warm naar koud licht aanpassen, dan gaan alleen de Ikea lampen mee in kleurtemperatuur.

Met Zigbee2Mqtt gaan ze wel samen gelukkig, maar het werkt dus niet out-of-the box met Innr en andere fabrikanten zoals Phillips met Hue en Ikea met Tradfri.

ligt dan eerder aan de hub, alle zigbee producten kunnen gewoon samen in 1 mesh netwerk.
Beste om zelf een hub te creëren, bijv via een pi + conbee II stick.

Een zigbee mesh netwerk dat bijvoorbeeld door Hue lampen gecreërd wordt, kan weer niet gebruikt worden door innr (die ook gebruikt maakt van Zigbee).

Heeft dat niet eerder te maken met de beperkingen van de coördinator (in dit geval de Hue hub?) dan een verschil in sub-protocollen of de lampen zelf?

Met een zigbee-stick van €15 en software als z2m werken 2000 apparaten van bijna 300 merken probleemloos samen. Ook Hue en innr werken dan gewoon samen in je zigbee mesh.

Zelf heb ik geen producten van innr. Wel Hue-lampen die zonder problemen samenwerken met Aqara, Ikea, Heiman, Tuya, Moes, Lellki (etc ) in mijn mesh.

[Reactie gewijzigd door Gizz op 6 januari 2022 10:32]

Waar haal je dit vandaan? Mijn hue lampen werken prima met mn Innr socket en meshen zelfs.

Ik moest ook direct aan deze XKDC denken: https://xkcd.com/927/

Als je het artikel en de reacties had gelezen had je gezien dat dit geen losstaande standaard is maar juist bovenop een bestaand protocol wordt gebouwd.

Dat maakt voor het punt niet uit. Het is niet alsof eea out of the box met de bestaande standaard werkt. Dat het een aantal elementen hergebruikt maakt dat sommige devices compatible gemaakt kunnen worden (geen structureel andere techniek), niet dat het geen andere standaard is.

Ik moest ook direct aan deze XKDC denken
Dat komt omdat die link ieder nieuwsartikel gepost wordt....

Maar Thread en Matter zijn anders. Deze standaard heeft heel veel positieve eigenschappen waaronder het punt dat de boel lokaal kunt houden. Deze XKDC gaat dus waarschijnlijk niet op.

Ik snap inderdaad ook niet waarom er wéér een nieuw protocol is.
Gelukkig kunnen de zigbee bidges deze protocollen aan en hoef je niets nieuws te kopen.

Dit is niet waar. Zigbee is niet Thread. Ze maken enkel gebruik van dezelfde frequentie.

Maar dan krijg je juist storingen toch? Als het op de zelfde frequentie zit.

Mwa, valt wel mee hoor. Een specificatie is vaak ook een frequentiebereik, niet een enkele vaste frequentie. Je moet je bijvoorbeeld beseffen dat je magnetron ook wel op dezelfde frequentie zit als je wifi. Je accesspoints houden hier ook rekening mee (verschillende kanalen).

Pas als je heel veel apparaten bij elkaar brengt (20 access points in flat bijvoorbeeld) die allemaal op dezelfde kanalen zitten, dan ga je het merken. Zigbee en Thread zijn low-power en laag bereik dus ik verwacht er niet veel problemen mee. Tevens zijn het 'zelfhelende' mesh netwerken. Als een pad onbeschikbaar is, dan neemt de data een ander pad (dan moeten er wel meerdere paden zijn)

Een bridge kan met een software update de achterliggende apparaten Matter compatible maken door te vertalen tussen Matter en ZigBee vergelijkbaar met hoe ze dat niet ZigBee en wifi doen. De fabrikant moet dit wel eerst ontwikkelen en niet toevallig een nieuwe bridge willen verkopen waar de compatibiliteit wel ingebouwd is.

Het idee van Matter (Thread) is dat juist iedereen samen komt. En het is een protocol boven op zigbee/wifi/etc om alles tot 1 netwerk samen te voegen zodat alle, ondersteunende, merken samen kunnen werken.

Vraag me af of dit enige invloed gaat hebben op zigbee. Het kan toch niet zijn dat straks alle apparaten met 1 protocol verkocht aan worden zodat je weer moet overstappen? Dat wordt dan een kostbaar grapje. Nu kan je met home asistant veel natuurlijk, maar het liefst gebruik ik niet allemaal verschillende protocollen.

[Reactie gewijzigd door dutchnltweaker op 6 januari 2022 10:13]

Je kan ook beide gebruiken. Je hebt alleen wel een OpenThread border router nodig. Zelf gebruik ik nu https://slae.sh/projects/cc2652/ voor zigbee maar deze kan je ook flashen voor Thread.

Ik ben benieuwd of ook zowel Zigbee als Thread gaat lukken op 1 stick. Vooralsnog is het Zigbee of Openthread als ik het goed begrijp en heb je dus een tweede stick nodig.

Aqara lukt het in ieder geval wel met 1 device, ook met hun oude hubs. Of zouden daar al voor de zekerheid twee Zigbee-chipsets ingebouwd hebben om zowel Zigbee als Thread te ondersteunen?

[Reactie gewijzigd door Gizz op 6 januari 2022 12:12]

Klopt, je hebt inderdaad 2 sticks nodig.

Vraag me af of dit enige invloed gaat hebben op zigbee.
Ja, velen zullen het zien als de opvolger.

Het kan toch niet zijn dat straks alle apparaten met 1 protocol verkocht aan worden zodat je weer moet overstappen?
Nee, alle Thread apparaten moeten kunnen werken met alle merken Edge routers. Je kan er ook meerdere hebben (van andere merken) zodat er geen SPOF meer is. Gezien Thread apparaten een IPv6 adres hebben zou je ze ook direct moeten kunnen aanspreken.

Hopelijk wordt Thread de standaard. Open-source, veilig, snel en modern. Dan zijn we van al die oude meuk af.

...voor de smarthomestandaard Thread.

...dat gaat werken met Matter, de nieuwe smarthomestandaard die grote bedrijven zoals...

Matter is het protocol, Thread de standaard. Ze worden nu beide als standaard benoemd in het artikel en Thread zowel als standaard, als protocol.

Alleen dan wel net andersom

Matter is de standaard, Thread is een protocol wat werkt met de Matter standaard.

Helemaal gelijk, heb ik het uiteindelijk alsnog omgedraaid

Ik heb best wat spul van Aqara / Xiaomi maar van de Motion Sensors zou ik vandaan blijven en ietsjes meer uitgeven voor Hue Motion Sensors, die werken namelijk op normale AAA-batterijen en zijn derhalve een stuk betrouwbaarder en best of all, de time-out/cooldown is maar 10 secondes zonder hardware hacks. Plus er zit nog een Lux sensor en temperatuur in (alhoewel Aqara dit ook heeft volgens mij).

On: ik begrijp zelf niet waarom er weer een nieuwe standaard komt, maar zoals ik het begrijp is deze standaard eigenlijk wat Home Assistant doet, maar dan zonder het selfhost gedeelte en binnen de apps die je zelf gebruikt (zoals Hue of Aqara?)

Die heeft Aqara inderdaad ook. Heb geen enkel probleem met de Aqaralijn. Tenminste een beetje een fatsoenlijk geprijsde productreeks. Ik heb een allergie voor hubs, dus ik gebruik altijd rechtstreeks de endpoints, dan zit er ook minder foutgevoeligheid tussen.

Volkomen mee eens. Idem de Sonoff Zigbee motion sensors. Dropouts, false positives zijn geen uitzonderingen. Niet alleen bij mij overigens, ook bij mensen in mijn omgeving en de vele users op fora. Ik had dan per kamer 2 sensoren in een groep, zodat de ander dan als backup zou werken. En dan droppen ze beide random.... Stuk of 18 Aqara en Sonoff motion sensoren weggegooid en 9x Philips Hue gehaald.

Goedkoop = duurkoop.

[Reactie gewijzigd door ASNNetworks op 6 januari 2022 11:39]

Voor zover ik het nu begrijp is Matter alleen maar gemaakt zodat apparaten met elkaar zouden kunnen praten. Net zoals dat alles wat op je thuisnetwerk zit ook met elkaar zou kunnen praten. Mijn TV zit namelijk ook op hetzelfde netwerk als mijn printer, toch kan mijn TV daar helemaal niks mee want die heeft geen flauw benul wat een printer is. Maar zou er wel mee kunnen praten, want ze spreken allebei "IP".

Ditzelfde is nu ook met Zigbee aan de hand. Je kunt bijvoorbeeld een slimme strijkijzer uitbrengen met Zigbee-ondersteuning, maar geen bridge op de wereld die weet wat een slimme strijkijzer is en hoe je het moet weergeven in bijv. een app. Ookal spreken de strijkijzer en de bridge "Zigbee".

Verwacht dan ook geen wonderen met Matter. Apparaten zouden met elkaar kunnen praten, ze kunnen elkaar zien en ze kunnen communiceren. Betekent alleen niet dat ze elkaar kunnen begrijpen. Een Hue Bridge met Matter-ondersteuning gaat nog steeds niet de slimme strijkijzer kunnen bedienen. Dan zul je een controller moeten hebben die zowel Hue als de strijkijzer begrijpt.

Dit is althans hoe ik het allemaal zie. Correct me if i'm wrong.

[Reactie gewijzigd door xFeverr op 6 januari 2022 11:19]

Vziw is het voornaamste probleem voornamelijk dat er nu een aantal erg nauw gerelateerde technieken zijn, die door vendor lockins en andere variabelen niet lekker (en/of out of the box) met elkaar samenwerken. Matter zou dat wel moeten doen, mits (uiteraard ) alles matter spreekt. Extra winst pak je dan als alles ook nog eens thread praat.

ZigBee is een protocol zodat verschillende vendors apparaten kunnen maken doe zich gedragen als lamp of sensor. Dit protocol heeft echter wat beperkingen. Zo kan een sensor niet direct met een lamp praten.
In Z-wave kan dit wel maar maar ook daar is de communicatie beperkt en is het best wat werk om alles goed de configureren.

Matter probeert is om los van het protocol ( ZigBee, Z-wave, Wifi of Thread, die onderlinge communicatie te standaardiseren. Een ZigBee sensor kan direct met een Z-wave lamp praten (als ze beide Matter ondersteunen). Je hebt nog steeds een Wifi, ZigBee en Z-wave access point nodig en daar kan eventueel de vertaling/verrijking gemaakt worden van Matter naar ZigBee en terug.

Voorbeeld:
Google hub roept: Wie is een lamp?
Hue Bridge: Ik (lamp 1), Ik (lamp 2)
Shelly lamp: Ik (lamp 3)
Google hub roept: Alle lampen, ga eens aan!
Hue Bridge tegen lamp 1: ga eens aan...
Hue bridge tegen lamp 2: ga eens aan...
Shelly lamp: gaat zelf aan...

Al meer dan 2 jaar verschillende aqara sensoren ( leak detection, 4x door/window sensors , temp sensor, tilt sensor , dubbel schakelrelais en stopcontact ) en nog geen enkel issue mee gehad. De motion sensors daar heb ik echter geen ervaring mee.

Ligt in vele gevallen aan de gebruikte hub ook.
De meeste zitten nu op mijn Homey, en die laat wel regelmatig steken vallen... De eigen Hub van Xiaomi deed het beter, maar werkt enkel met een Chinese server, wat dan weer voor enorme vertraging zorgde.
Ik hoop dan toch ook dat er 1 protocol komt dat voor alles werkt