Espressif kondigt ESP32-H2-soc met Thread- en Zigbee-ondersteuning aan

Espressif Systems kondigt de ESP32-H2 aan, een system-on-chip met ondersteuning voor IEEE 802.15.4 en daarmee voor Thread en Zigbee. Daarnaast heeft de chip ondersteuning voor Bluetooth 5.2.

De ondersteuning voor 802.15.4 maakt de soc volgens Espressif geschikt voor smarthometoepassingen. Het gaat om een low-powerprotocol voor draadloze meshnetwerken met een rechtstreeks bereik van tien meter. De Zigbee- en Thread-protocollen zijn op 802.15.4 gebaseerd en ook de interoperabele smarthomestandaard Matter kan er mee overweg. De ESP32-H2 ondersteunt Thread-versie 1.x en Zigbee-versie 3.x. Tweakers publiceerde recent een achtergrondartikel over de technologie: IP-netwerken in smarthomes en iot.

De ESP32-H2 ondersteunt daarnaast Bluetooth 5.2 en daarmee LE Audio met functies voor het broadcasten en delen van audio. Ondersteuning voor wifi is er niet. De basis van de soc is een 32 bits Risc-V-controller die tot 96MHz geklokt kan worden en over 256KB sram kan beschikken. Wanneer de soc precies beschikbaar komt en wat de prijs wordt, maakt Espressif nog niet bekend.

Wat vind je van dit artikel?

Geef je mening in het Geachte Redactie-forum.

Reacties (57)

Jammer dat deze versie geen WiFi heeft.

Nu zijn er legio ethernet boards die je aan een ESP32 kunt knopen, maar het leuke van een ESP32 is juist dat je deze overal neer kunt plempen en je alleen maar stroom nodig hebt. Nu moet je kabels trekken of een wifi shield zoeken wil je het de H2 gebruiken als Zigbee bridge.

Ik snap het wel, het gebruikt (grotendeels) dezelfde hardware dus het is een kleine aanpassing om van de ene naar de andere optie te gaan, maar beide tegelijk was leuk geweest

De ESPs ondersteunen alleen wifi op 2,4GHz waardoor het potentieel storing geeft met Zigbee, zeker als deze (zeer) kort bij elkaar zitten. Nu is het advies al dat als je een RPi met wifi hebt en daar een Zigbee stick in doet om de laatste aan te sluiten met een USB verlengkabel om storing te voorkomen.
En de Hue Bridge 2.0 zou ook een wifi chip aan boord hebben, ongebruikt. Ook daarbij hoogstwaarschijnlijk omdat het teveel storing geeft.

Waarschijnlijk dat dat dus ook de reden is dat deze ESP het niet heeft. Naast het mogelijke kostenplaatje. Niet dat het perse "duur-duur" is om beiden te ondersteunen. Maar als het een euro extra kost op een ESP van wat kosten ze, 5 euro? Is dat natuurlijk alsnog een flinke toename.

Het is relatief normaal dat dit op zo'n bordje niet aanwezig is aangezien je normaal, bijvoorbeeld met Thread, een border router opneemt in je systeem die, dan wel een ethernet, dan wel een wifi verbinding mogelijk maakt voor buiten het mesh netwerk.

Je zou dus een ESP-H2 kunnen uitrusten met een ethernet shield zodat die de functie van border router kan opnemen en vervolgens verspreid je de ESP-H2's door je huis welke het mesh netwerk vormen.

Dit lijk een totaal andere chip dan een esp32. Het is erg verwarrend dat ze dat in de naam hebben meegenomen. Andere CPU, geen dual core 240Mhz, geen ULP (misschien niet meer nodig door de nieuwe CPU), geen WiFi.

Dit is ook eigenlijk geen esp32 meer, ik denk dat dit veel verwarring gaat veroorzaken.

De ESP32-C3 is ook al een compleet andere architectuur dan de ESP32 of de ESP32-S2.
Dus die verwarring was er al

De ULP van de ESP32 is op papier op zich wel interessant, maar heb je al een praktisch voorbeeld gezien ervoor?
Zitten best wel wat haken en ogen aan om dat goed werkende te krijgen.

Ik heb 'm zelf eens goed werkend gekregen voor een projectje in 2018. Was een keypad die aan de esp hing, bij het intoetsen van de keys liet ik de ULP deze direct debouncen en opslaan. Tegelijk werdt de main CPU ge-waked die vervolgens de keys via WiFi kon opsturen en na een korte time-out weer in slaap ging. Het idee was om een WiFI afstandsbediening te maken op die manier.

De ESP-32 was alleen langzamer (richting seconde) in het connecten dan de esp8266 (onder 200ms) wat ik irritant vond en het esp-now protocol wat ik als alternatief wou gebruiken had andere problemen.

https://github.com/espressif/arduino-esp32/issues/878

Nooit verder afgemaakt, er kwam weer iets nieuws voorbij en is blijven liggen.

Inderdaad! Ondersteuning voor Wi-Fi (5 of 6Ghz) zou een perfect bordje zijn voor mij.

Je kan natuurlijk deze nieuwe ESP32 en een standaard ESP32 met wifi aan elkaar kunnen knopen

Geeft mogelijk wel problemen met interferentie als ze te dicht op elkaar zitten.

Als de prijs goed is, wat ik zeker verwacht, is dit een directe aanval op Nordic Semiconductor met hun nRF52840 welke ongeveer dezelfde specs heeft. Het gaat hem dan puur in de support en toolchain zitten. De ESP-IDF en nRF Connect IDE zijn dan puur persoonlijke voorkeur maar ik denk dat Espressif dan wel eens sterk onder de prijs van Nordic kan gaan zitten waardoor deze chip ideaal wordt voor smarthome nodes die geen wifi nodig hebben (lampen, schakelaars, sensoren, ...)

Dit ga ik zeker volgen.

Inderdaad erg jammer dat ze wifi hebben laten vallen, maar je kunt er natuurlijk makkelijk een 8-pins ESP-01 op basis van de ESP8266 naast zetten. Die is primair bedoeld als wifi interface voor andere SoCs. Voor mij was het de eerste kennismaking met de ESP8266 De Cortex M3 waarmee ik 'm wilde gebruiken heb ik helemaal achterwege gelaten toen ik ontdekte wat je allemaal met die ESP8266 kunt.

Weet iemand om het mogelijk is om hiermee Arduino de Zigbee standaard te laten volgen, en bijvoorbeeld een eigen custom Zigbee sensor te maken? Ik heb het ooit onderzocht, maar meer dan data transfer tussen twee Arduino's vond ik weinig.

Ik vond wel projecten waarbij men Zigbee powersockets hadden 'gerecycled' om hun arduino creaties aan en uit te zetten, maar het hele radio gedeelte bleef een black box.

Wie bij Zigbee2MQTT (een populair open source zigbee project) in de lijst van ondersteunde apparaten kijkt, die vind daar wel een paar "custom" devices, maar ook die lijken vooral relais te zijn, en geen sensoren.

[Reactie gewijzigd door unfold op 6 augustus 2021 11:39]

Als deze devices de Zigbee ZCL spec volgen kunnen ze makkelijk toegevoegd worden via een external converter: https://www.zigbee2mqtt.i...-converters-configuration

Niet om af te doen aan de awesomeness van Zigbee2MQTT, maar dan moeten alle gebruikers die extensie in Zigbee2MQTT installeren? En uberhaupt zigbee2MQTT gebruiken?

Ik hoop zelf sensoren te kunnen maken die de Zigbee 3.0 specificatie volgen, en zo werkelijk aan een "normaal" zigbee netwerk toegevoegd kunnen worden. Zou dat ooit mogelijk zijn? Of is er een soort certificeringsproces dat DIY dingen tegenhoudt?

Ding is een beetje dat Zigbee meer een protocol is op de link laag en niet de "inhoud" omschrijft, bij mijn weten. Dus Zigbee is meer vergelijkbaar met ethernet + TCP/IP. Maar de daadwerkelijke data die verstuurd wordt (dus zeg bv HTTP vs SMTP vs ...) is niet gestandaardiseerd binnen Zigbee.
Als je dus zelf Zigbee hardware gaat maken moet je of zorgen dat de data die je stuurt identiek is aan een bestaand apparaat waardoor de Zigbee controller denkt dat het dat andere apparaat is, of je moet dus een (open source) controller gebruiken waaraan je zelf ondersteuning voor jouw apparaat toevoegt.

Ter verduidelijking. Zigbee omschrijft dus bv alleen dat er "velden" zijn die waardes hebben. Maar "veld 10" met waarde "50" is bij een Hue lamp wellicht het dimniveau, bij een Ikea lamp de saturation, en bij een rolluik module hoe ver het rolluik open staat.
Vergelijk dit met ZWave, waarbij wel alles is gestandaardiseerd. Bij ZWave staat in de standaard echt vast "veld 10 is het dimniveau". En of je dan een dimmer van Fibaro en Qubino of Aeotec hebt maakt niet uit "veld 10 is dimniveau". En een rolluik module zal dus ook nooit "veld 10" gebruiken, want een rolluik heeft geen dimniveau.

De Zigbee Cluster Library (ZCL) beschijft de standaard beschikbare commandos binnen Zigbee. De Cluster, Commando en Attribuut waarden/ranges liggen wel degelijk gewoon vast en zijn zeker niet random per fabrikant.

De ZCL spec (samen met wat andere specificaties en certificatie) is nu juist wat er voor zorgt dat apparaten van verschillende fabrikanten samen werken binnen een systeem. Bijv Osram lampen binnen een Hue systeem.

Heel helder, dank je wel.

Zon extensie moet je zelf maken op basis van wat jou device doet.

Ik hoop zelf sensoren te kunnen maken die de Zigbee 3.0 specificatie volgen, en zo werkelijk aan een "normaal" zigbee netwerk toegevoegd kunnen worden. Zou dat ooit mogelijk zijn? Of is er een soort certificeringsproces dat DIY dingen tegenhoudt?

Toevoegen zou geen probleem moeten zijn, of de gateway vervolgens ook iets kan doen met die data hangt natuurlijk erg af van de gateway.

Dat kan. Google maar eens op Xbee... Helaas zijn die modules vrij prijzig, dat je wel een bijzonder project moet hebben wil je dit verkiezen boven een kant en klaar product.

Ik heb deze module gebruikt (in combinatie met een esp32) om 5 hue lampen tegelijk te emuleren. Ik heb hiermee een ledstrip met individueel aanstuurbare leds aangestuurd, met een gradiënt tussen de 5 kleuren. Zo kon ik de Ambilight van m'n TV door laten lopen in de kasten er onder.

Klinkt heel vet

Arduino als apparaat met bijvoorbeeld een Atmel 328 heeft geen radio hardware en geen zigbee chip, je zou dus een ATSAMR2 kunnen aansluiten voor zigbee ondersteuning. Koenkk beschrijft voor Zigbee2MQTT hoe je een goedkope TI CC2530 kunt gebruiken en heeft op zijn github ook de TI Z-Stack software staan.

Het meest tweak vriendelijke is dus deze ESP32-H2 die kun je als apparaat in Arduino IDE of Platform IO kunt programmeren en aansluiten op je eigen projectje

De esp32 heeft toch geen audio functies ingebouwd? dus om audio van goede kwaliteit te produceren heb je dan toch een externe audio chip nodig? Omdat het artikel over LE audio praat.

Klopt, maar de chip ondersteunt I2S —> waar er heel veel dac’s van zijn die dat ondersteunen.

Dat klopt, ESP's doen geen audio.

Interessant! Maar wanneer zou je voor deze nieuwe mcu kiezen over andere Zigbee, Thread & BLE capable mcu's zoals die van Nordic?

[Reactie gewijzigd door diondokter op 6 augustus 2021 10:45]

Misschien wil je zo min mogelijk devices via je WiFi netwerk laten werken maar heb je een prima ZigBee netwerk draaien.

Een voorbeeld zou kunnen zijn dat je er een ledstrip oid mee aanstuurt en die toevoegd aan je Hue installatie.

edit: slaat nergens op, WiFi en ZigBee zitten allebei op 2.4.

[Reactie gewijzigd door shaft8472 op 6 augustus 2021 10:43]

Wifi en Zigbee werken dan wel beiden op de 2,4GHz frequentie, maar de kanalen zijn maar gedeeltelijk overlappend. Daarnaast is Zigbee vele malen zuiniger. Bv een Zigbee knop zal alleen data versturen als de knop wordt ingedrukt, en dit is dan ook een klein pakketje dat snel verstuurd kan worden. Wifi apparaten zullen eerder de verbinding continu open houden en daardoor dan ook veel meer energie verbruiken. Sommige apparaten verbreken de wifi verbinding weer wel, en zetten deze op als data verstuurd moet worden, maar dan heb je ook meteen een flinke vertraging.

Dat wil je qua security sowieso.

Interferentie hou je altijd

Hoezo zo is zigbee beter beveiligd? Als je er op doelt dat je iot niet op je ‘normale’ netwerk wil zijn daar prima oplossingen voor.

Niet zien op je normale netwerk betekend natuurlijk niet dat ze wel veilig zijn. Uiteindelijk hangt ook zo'n ESP aan je wifi netwerk en kan dus met apparaten babbelen. In mijn geval is het wel een gescheiden IoT-VLAN waarbij de apparaten standaard niet met internet (noch andere VLANs) kunnen communiceren, maar communicatie binnen hetzelfde VLAN blijft natuurlijk wel mogelijk, tenzij de andere kant in het verhaal zelf een firewall heeft. Maar niks weerhoud een ESP ervan om bv met mijn Hue-bridge te babbelen die zich in hetzelfde VLAN bevind.
En bij mijn weten moeten bv de Xiaomi Roborock stofzuigers perse verbinding met internet hebben. Ook dan weer: ja, je kunt ze in een apart VLAN plaatsen waardoor ze niet met je PCs, NAS, ... kunnen verbinden, maar ze kunnen wel heel wat data naar Xiaomi over de lijn gooien.
Bij een apparaat zonder internet verbinding weet je gewoon 100% zeker dat het niet "iets" het internet op kan sturen of met andere apparaten in hetzelfde VLAN kan babbelen.

Naast dat er dus ook nog andere voordelen zijn aan "niet via wifi".
IoT apparaten op wifi zullen altijd een gedeelte van de timeslots wegsnoepen en dus zullen andere apparaten "langzamer worden" (tijd dat het access point babbelt met de slimme thermostaat op wifi kan die niet babbelen met een telefoon die Netflix wil streamen om maar wat te noemen).
(Veel) wifi apparaten zullen ervoor zorgen dat je sneller door je beschikbare IP-adressen / DHCP pool heen gaat.
Scheiding in VLANs voor beveiliging en/of voorkomen van "lege" DHCP pool kan niet met bv een modem/router van de provider en waarschijnlijk ook nog niet met "simpelere" consumenten routers.
Veel wifi apparaten kan ervoor zorgen dat een modem/router van de provider of simpelere consumenten router sneller "plat gaat".

bij mijn weten moeten bv de Xiaomi Roborock stofzuigers perse verbinding met internet hebben

Ik gebruik die van mij (de "Mi robot") al jaren zonder 'm ooit verbonden te hebben. Ik druk gewoon het knopje in als ik wil dat ie stofzuigt.

Het betekent wel dat ie na een reboot (wat kan gebeuren als ie ergens vastloopt en daardoor een lege accu krijgt) altijd weer opnieuw de onbeveiligde hotspot opzet waarmee je 'm aan het internet hoort te koppelen. Na een half uurtje verdwijnt die hotspot gelukkig weer. Vooralsnog hebben mijn buren daar in dat half uurtje nooit misbruik van gemaakt :-)

Ze zitten dan wel beide op 2.4Ghz, je wifi zit als het goed is ook op 5Ghz én als je een wifi router van je provider hebt en 50 lampen wil aansturen dan gaat dat ding over zijn nek, terwijl de Hue Bridge (of een andere Zigbee / Thread / ... bridge) er prima mee overweg kan.

Verder is Zigbee en Thread P2P mesh wat wil zeggen dat als je in elke kamer van je huis lampen hebt, maar je wifi normaal niet tot in de badkamer op de bovenverdieping geraakt, je lampen het alsnog zullen doen.

Natuurlijk is dat ook niet de vraag, de vraag is, waarom deze en niet van fabrikant XYZ?

[Reactie gewijzigd door bramvandeperre op 6 augustus 2021 16:17]

Esp werkt alleen op 2, 4 Ghz wifi niet op de 5ghz.yrouwens met al die nieuwe modellen die ze de laatste tijd aan kondigen. Maar de 8266 en de32 ondersteunen alleen single band wifi.

Verder is Zigbee en Thread P2P

Met zoiets wordt gewoonlijk juist aangeduid als een mesh netwerk. P2P impliceert niet dat de pakketten via een ander bij het uiteindelijke apparaat geraakt. P2P is vaak beperkt tot connecties tussen 2 pcs. En dus niet A->B->C, waarbij B echt actief helpt.

Home automation dus. Zowel thread als zigbee zijn daar beter voor geschikt dan WiFi in heel veel gevallen.

Dat is een reden om zigbee te kiezen. Niet zoals de vraagstelling is, om specifiek voor esp32 te kiezen.

Ik denk vooral energiegebruik en prijs. Maar dat valt nog te bezien

Esp32 zijn supergoedkoop. En ze hebben prima Arduino support waardoor ze eenvoudig door hobbyisten kunnen worden ingezet. Maar ook in apparatuur kan het worden toegepast aangezien de radios gecertificeerd zijn.

[Reactie gewijzigd door Ablaze op 6 augustus 2021 10:45]

Ik gok op prijs aangezien ESP daarvoor bekend is; jammer dat juist die nog niet is gegeven.

Heb hier een tijdje op zitten wachten, en ben erg blij dat er een esp32 met zigbee komt. Nu nog op een microcontroller plaatsen en je hebt mn geld

Wat dacht je van de RISC-V processor die op het bordje zit, beter lezen!!!

Ik weet niet wat dat is

De ESP32 is een microcontroller, dus waarom je hem pas zou kopen als de ESP32 weer op een andere microcontroller geplakt wordt snap ik niet helemaal

Bedoel je niet dat je deze ESP32-H2 op een printplaatje wilt hebben zodat je makkelijk de GPIO's kunt aansluiten, een usb-connector hebt, een power converter etc.? Dat noemen we meestal een development bordje. De microcontroller is echt de ESP32 zelf.

[Reactie gewijzigd door Gizz op 6 augustus 2021 16:07]

Bedoel je niet dat je deze ESP32-H2 op een printplaatje wilt hebben zodat je makkelijk de GPIO's kunt aansluiten, een usb-connector hebt, een power converter etc.?

Ja inderdaad

Dat noemen we meestal een development bordje. De microcontroller is echt de ESP32 zelf.

Ah zie je had zon gevoel dat ik wat verkeerds zei Bedankt!

DIY componenten voor Zigbee waren tot nog toe erg schaars, dus mooie ontwikkeling!

Niet alleen schaars, ook enorm duur. Daar waar een ESP maar 5 Euro kost kan een zigbee module die je daar op kan gebruiker al snel 15 euro waardoor de hele package al snel 20 euro kost. Als deze ESP op modules gemaakt gaan worden dan kan dit zo 13 euro schelen.

Zelf heb ik toentertijd nog zitten spelen met XBee dingetjes.

Wat een drama; zelfs een beetje fatsoenlijk aansluiten om een bordje was een karwei omdat die dingen zo nodig een eigen setje headers met eigen spacing hebben. Want waarom makkelijk maken door standaard spacing te gebruiken als je ook iedereen gruwelijk kan irriteren door nodeloos af te wijken?

Natuurlijk zijn er manieren om die dingen alsnog bruikbaar te maken, maar niemand heeft zin om een breakouttoren van Pisa in elkaar te drukken puur omdat een bedrijf denkt dat standaard spacing niet goed genoeg is voor ze...

Cool, dus hiermee kan je zelf een zigbee lamp maken bijvoorbeeld?

Dat zou kunnen.

Mooi spul. Ik denk dat dit ESP op accu een stuk makkelijker maakt. Nadeel van die "oude" ESPs is dat wifi erg veel stroom slurpt waardoor battery powered altijd uitdaging was. En wifi is natuurlijk compleet overkill voorde meeste ESP toepassingen.

Hiermee lossen ze het grote probleem op van de ESP, stroomverbruik.
Nu wordt het leuk om ESP projectjes met batterijen te maken.

Kwestie van tijd en alle conbee usb sticks + software kunnen met deze chips werken.

Leuk alternatief voor de E18-MS1PA/CC2530
https://ptvo.info/zigbee-...-features/e18-ms1pa2-ipx/