Nabu Casa neemt ESP-microcontroller-toolontwikkelaar ESPHome over

Nabu Casa heeft ESPHome overgenomen. ESPHome laat IoT-gebruikers custom firmware maken voor de ESP8266- en ESP32-microcontrollers. Nabu Casa, bekend van Home Assistant, belooft dat ESPHome gratis en opensource blijft.

Nabu Casa schrijft niet hoeveel het voor ESPHome heeft betaald. De twee huidige ontwikkelaars blijven betrokken bij het project. Oprichter Otto Winter treedt terug als manager van ESPHome maar blijft de tool ontwikkelen 'wanneer hij er tijd voor heeft'.

Winter startte ESPHome drie jaar geleden. Volgens Nabu Casa-oprichter Paulus Schoutsen groeide het project over de jaren heen, waardoor Winter het niet meer kon combineren met zijn privéleven. Nabu Casa is met de overname ook copyrighteigenaar van Winters code en de ontwikkelaarsaccounts van ESPHome. Winter heeft zijn Patreon-account na de overname gesloten.

Met ESPHome kunnen gebruikers in yaml commando's sturen naar ESP8266- en ESP32-apparaten. De software werkt samen met Home Assistant en laat gebruikers makkelijker de ESP-IoT-microcontrollers integreren in Home Assistant. Volgens Schoutsen is ESPHome een 'belangrijk onderdeel' geworden van het Home Assistant-ecosysteem. Daarom wilde Schoutsen er zeker van zijn dat het project gratis en opensource kon blijven. Tweakers publiceerde eerder een Plus-interview met Paulus Schoutsen.

Reacties (47)

[AJediIAm]

Het is voor mij een verrassing dat open source projecten gekocht kunnen worden.
Op basis van het artikel denk ik dat het ESPhome in goede handen is en samen met Home Assistant verder kan groeien om DIY smart homes voor iedereen toegankelijk te maken.

[TD-er]

Het is voor mij een verrassing dat open source projecten gekocht kunnen worden.
[...]

Het project is "overgenomen". Dat hoeft toch niet meteen te betekenen dat het "gekocht" is?
Ter illustratie, ik heb ESPEasy een paar jaar geleden overgenomen, maar daar is geen euro voor betaald.

Maar in theorie zou je zaken prima kunnen overkopen. Alleen alles wat in het verleden open source is geweest kun je niet zomaar ineens closed source maken.
Naast juridisch "gedoe" (wat je IMHO niet zou moeten willen), help je met een move naar "closed source" ook heel goed je community om zeep en dat is volgens mij het meeste waard van zo'n project.

Ik ken de persoon/personen niet die hierachter zitten, maar het lijkt mij dat dit een overname is om de voortgang van het project veilig te stellen. Om wat voor reden dan ook, is het voor de 'geestelijk vader' van het project niet mogelijk om er de tijd en energie in te steken die het project nodig heeft om verder te gaan (of verder te groeien) en dan is een overname om dat veilig te stellen een logische stap.
En of dat nu een overname is waarmee geld van de ene partij naar de andere partij gaat, of dat er garanties zijn afgesproken om resources vrij te maken om de voortgang veilig te stellen, dat doet er niet zozeer toe. Het belangrijkste is in zo'n geval de continuiteit waarborgen van het project. (althans dat is zoals ik het zie en nee, ik ben zeker niet zoiets van plan voor ESPEasy )

[Niemand_Anders]

Dat kan wel degelijk. De huidige codebase noem je 'community' edition en is altijd voor iedereen gratis beschikbaar. Daarnaast zet je een commerciele variant in de markt als 'enterprise' edition..

Een (zeer) groot deel van de lopende populaire open source projecten worden gemanaged door commerciele bedrijven. Denk hierbij aan Mysql, MongoDB, Docker en Magento om er enkele te noemen. Er zijn ook open source projecten welke niet direct een betaalde versie hebben, maar wel commerciele backing zoals de Linux Kernel, Apache, Mozilla, Digium (Asterisk) en PHP.

En dat is een goed iets, want als een commerciele partij zo'n project adopteert, dan geeft dat een bepaalde garantie dat het project doorontwikkelt blijft worden. Dat is dan weer belangrijk voor veel bedrijven om hun eigen infrastructuur daarop te baseren. Uiteraard vinden ze het prettig dat ze de software gratis mogen gebruiken, maar veel belangrijker is dat als er problemen onstaan, je meer mogelijkheden hebt dan een bericht op een forum plaatsen en hopen/duimen dat iemand snel een bruikbaar antwoord geeft..

[TD-er]

Er zijn ook best wel wat voorbeelden waarbij de community het hier niet mee eens was en verder zijn gegaan op een fork.
Denk bijvoorbeeld aan MariaDB vs MySQL.
Of LibreNMS wat ontstaan is uit Observium nadat Observium de bestaande community best wel grondig gedecimeerd had door het 'open' karakter van het pakken weg te nemen.
Zo zijn er zat voorbeelden van pakketten die op z'n minst hun community behoorlijk wat onrust gaf door de koers drastisch te veranderen naar een betaald (en daarmee closed) business model.

Tuurlijk zijn er ook voorbeelden waarbij het goed gaat, of uiteindelijk goed gekomen is.
Maar als er een groep nogal principieel is, is het wel de fanatieke gebruikers van Open Source.
En als in die groep wantrouwen of onrust ontstaat zit je al heel snel met een afsplitsing en dan ben je meer aan het concurreren dan samenwerken.

Hiermee zeg ik dus niet dat commercie en Open Source onmogelijk is (ik doe het zelf ook), maar wel dat je heel goed in de gaten moet houden met welk doel je dingen commercieel maakt.

Om mijn eigen "commerciele" kant als voorbeeld te noemen.
Ik heb mijn eigen bedrijf waarmee ik hardware ontwikkel voor klanten en daarbij ESPEasy als mijn toolkit gebruik.
PCB design etc. gaat gewoon tegen vol tarief en als er een uitbreiding nodig is in de software is dat tegen half tarief wanneer de software daarna gewoon open source mag worden.
Nadeel van zaken niet open source maken is dat het niet in de standaard ontwikkeling van de software verder gaat en dus al vrij snel extra werk nodig heeft om up-to-date te blijven. Dus dat is veel duurder dan het open source vrijgeven. Dat gebeurt dus ook niet.
Voordeel is dus dat de software verder ontwikkelt wordt, de ontwikkelaar resources heeft om verder te gaan en dat er meer producten op de markt komen gebaseerd op open source
Een nadeel kan zijn dat je niet heel hard kunt schalen als dat nodig mocht zijn.

[Niemand_Anders]

Er zijn ook best wel wat voorbeelden waarbij de community het hier niet mee eens was en verder zijn gegaan op een fork.
Denk bijvoorbeeld aan MariaDB vs MySQL.

De fork van MySQL had niet zozeer te maken met de enterprise edition van Oracle, maar meer met de bezwaren hoe Oracle leiding gaf aan het project. MariaDB heeft ook gewoon een enterprise edition.

Zelf maken wij gebruik van Percona MySQL. Een open source MySQL distributie met enterprise features. Per server waarop wij Percona draaien doneren wij maandelijks 50 dollar aan Percona.

Het is soms moeilijk om open source aan een bedrijf te verkopen als er geen commerciele partij achter zit. Het gaat immers niet alleen om support, maar ook continuïteit van de software. Nu kun je natuurlijk nooit garanties afgeven, maar doorontwikkeling van software ligt meer in de verwachting van een commercieel 'open source' project dan dat van een project dat in de vrije tijd van een ontwikkelaar wordt onderhouden..

En uiteraard zijn er ook voorbeelden waarbij de 'verkoop' van een open source project niet is goed gegaan..

[Anoniem: 1322]

Dat is denk ik inderdaad de reden voor de overname. Op zich bewijst het artikel dit ook wel:
Oprichter Otto Winter treedt terug als manager van ESPHome maar blijft de tool ontwikkelen 'wanneer hij er tijd voor heeft'.

Winter startte ESPHome drie jaar geleden. Volgens Nabu Casa-oprichter Paulus Schoutsen groeide het project over de jaren heen, waardoor Winter het niet meer kon combineren met zijn privéleven.

[84hannes]

Maar in theorie zou je zaken prima kunnen overkopen. Alleen alles wat in het verleden open source is geweest kun je niet zomaar ineens closed source maken.

Dat hangt van de omstandigheden af. Ik kan het zo snel niet vinden, maar ik meen ergens gelezen te hebben dat als je bijdraagt aan Microsoft Visual Studio Code, je Microsoft het recht geeft deze code closed source te gebruiken. Als dat zo is zou Microsoft Visual Studio Code vrij eenvoudig closed-source kunnen uitbrengen omdat iedere committer hier toestemming voor heeft gegeven (nog even afgezien van de open source software war VSCode op gebaseerd is). Is dat niet het geval, zoals bij een puur GPL-project, dan heb je gelijk en kan dat niet.

[tomdabom]

Echt top dit! Vergeleken met Domoticz is HA echt een eitje om op te zetten!

[AiR60]

Vind je?

Ik draaide al 8 jaar Domoticz.. met een beetje "vreemd" gevoel afscheid genomen van Domoticz, want daarmee kon ik lezen en schrijven, het voldeed voor mij alleen niet goed meer... mistte toch wel wat zaken en de interface is wat gedateerd, maar het is wel lekker lightweight.

Ik vind trouwens RFXcom op Domoticz superieur boven HA... die integratie vind ik eigenlijk best slecht. Maar ach, ik heb alleen nog maar een afzuigkap en die regel ik nu met Node-RED...

Even terugkomend op HA, vond de leercurve van YAML wat "stijl" maar na een paar uur was dat ook wel onder de knie.

Ik had persoonlijk wat moeite met de overstap naar HA, maar ben nu meer dan blij M'n Home Automation heeft een boost gekregen en heb nog nooit zoveel geautomatiseerd in huis.

Ook met ESPHome trouwens, dat is echt goud!!!

[RogerSch]

De goede integratie van RFXCom is voor mij ook de reden om bij Domoticz te blijven. De 11 Somfy RFX screens is toch wel een belangrijk onderdeel dat moet blijven werken.
Tja en het werkt en en de rest van het gezin kan er ook mee overweg. HA geprobeerd maar het zou mij teveel "tinker tijd" kosten om alles om te zetten naar Home Automation.

[Anoniem: 1322]

Jammer dat er (nog) geen integratie is tussen beide. Ik gebruik Domoticz nog voor de P1 meting (met een offload naar InfluxDB). Het zou fijn zijn als die waarden direct binnen HA beschikbaar zouden zijn.

/Edit: dank voor alle suggesties. Ik moet er maar weer eens mee bezig

[Reactie gewijzigd door Anoniem: 1322 op 22 juli 2024 14:41]

[vosManz]

Home Assistant kan ook de slimme meter via de P1 poort uitlezen, zelf gebruik ik daar de DSMR integratie voor.

[sanderdw]

Of mijn addon https://community.home-as...for-home-assistant/279087 welke de DSMR Reader software gebruikt (beetje verwarrend maar is een wat completere oplossing die ook weer in HA te integreren is, zie daarvoor stap 12)

[Reactie gewijzigd door sanderdw op 22 juli 2024 14:41]

[Anoniem: 1322]

Erg interessant, dank.
Ik had dit al eerder gezien maar verder niets mee gedaan omdat mijn (docker) HA niet in de buurt staat van de meter. Maar ik kan inderdaad DSMR inrichten op mijn meterkast PI en dit remote uitlezen in HA.

[AiR60]

Ik gebruik tegenwoordig DSMRreader en stuur de data naar HA....

[Anoniem: 30722]

Heb een kleine print met een esp01, via esphome naar mqtt. En zo komt het in influxdb/grafana terecht en in HA.

[Krypt]

Heb je daar een schema en esphome code van? Bedenk me dat ik nog een esp01 over heb.

[Anoniem: 30722]

Code zeker wel, schema was een kant en klare print van opencircuit, maar die verkopen deze versie niet meer. Terwijl deze juist gevoed kon worden op de P1 poort zelf.

https://opencircuit.shop/Blog/Slimme-meter-uitlezer <- meen dat het deze versie is! (alleen heb ik een RJ connector op de print, lood om oudijzer als je het mij vraagt

De esphome code is: https://gitlab.com/ivo-tje/p1-dsmr

(Even alles goed doorlezen qua hostnames, ssid's en passwords enzo)

[ballo50]

Dat doe ik ook, maar stuur de data via mqtt vanuit Domoticz door naar HA. Ik blijf op Domoticz voor p1 meting vanwege de historie en de betere grafieken. Het is me nog niet gelukt om vergelijkbare overzichten vanuit grafana te maken om daarmee Domoticz geheel te vervangen.

[Anoniem: 1322]

Het is me nog niet gelukt om vergelijkbare overzichten vanuit grafana te maken om daarmee Domoticz geheel te vervangen.
Gedeeltelijk is mij dat gelukt maar het is inderdaad lastig en ik ben er niet geheel tevreden over. Maar inderdaad is dat ook nog een reden om Domoticz te blijven draaien.

[Milmoor]

Het is wat gedoe, maar ik verwacht dat je ze via MQTT aan elkaar kan knopen. Ik had Node-Red en Domoticz op die manier verbonden.

[Joydashy]

Kan direct in HA met bijv. : https://smartgateways.nl/product/slimme-meter-wifi-gateway/

[AiR60]

Dat probleem had ik met Z-wave... iets van 12 Z-wave devices in huis... de 2 na laatste poging gooide al m'n apparatuur in de war, als ik lamp in de gang aanzette, ging de buiten verlichting aan. Spontaan ging verlichting branden of het werkte gewoon niet meer...

De 1 na laatste poging ging beter, maar toen had ik Z-wave nog niet eens over, maar draaide ik in een VM om e.e.a. te testen. Dat deed ik dus met USB Passthrough....tot ik een keer een usb kabel eruit trok en m;n installatie corrupt was, toen was ik er klaar mee... maar het bleef toch jeuken en heb vorige maand een oDroid N2+ gekocht om mezelf toch richting HA te pushen Bleef het n.l. toch een mooi product vinden en wilde het toch een kans geven. Nu wil ik niet meer terug

Owja, wat me over de streep heeft getrokken...ook ESPHome, maar ook dat de integratie met Z-Wave nu een stuk beter is! Ik had een controller voor mn zonnescherm die deed het als enige niet. Een ticket geopend en 2 dagen later kwam er een update met de fix! Nu werkt echt alles in huis zoals bedoeld.

Ik vind (zeker op gebied van Z-wave) dat met HA alles veel vlotter reageert. Ik had met Domoticz op het laatst dat statussen van devices niet werden bijgewerkt in Domoticz, en dat gaat bij HA des te beter.

Maar... ik heb m'n Domoticz instance nog steeds draaien, gewoon omdat het kan kan ik er af en toe even nog mee spelen (nee, ik ben en blijf wel nieuwsgierig naar de ontwikkeling van Domoticz, en kan zo de updates nog een beetje volgen )

[Anoniem: 30722]

Tahoma er tussen?

[WhiteDog]

Wat werkt er dan anders aan in Domoticz? Het gaat naar boven, het gaat naar beneden en hij onthoudt de status (want feedback is er niet). Enige wat ik mis is ze ergens halfweg zetten maar dat zou toch al gokken zijn op basis van looptijd.

Ik weet niet hoeveel beter je dit kan implementeren... Heb ook Somfy RFX (gordijnen) maar HA is bij mij gewoon de hub, bedienen doe ik via HomeKit en wat automatisaties.

Eigenlijk gewoon beter om RFX te vermijden, mijn ZWave rolluiken heb ik veel meer vertrouwen in.

[tomdabom]

Ja zekers! Als je net begint met home automation is Domoticz best wel overweldigend, dit heb ik met HA bijv niet gehad.

[AiR60]

Zit je dan nu op HA of Domoticz?

[tomdabom]

Zit op HA! Ben wel van de fancy GUIs helaasch.

[spank_mojoo]

als dit nu maar niet betekend dat de ontwikkeling van EspHome achter gaat lopen, of dat deze integratie uiteindelijk een betaalde feature gaat worden.

[overhyped]

Volgens mij hoeven we daar niet bang voor te zijn. Home assistant is vrij duidelijk in hun beleid voor wat betaald is en wat niet.

[mbbs1024]

Beleid kan makkelijk gewijzigd worden.
Nabu Casa heeft een aantal betaalde ontwikkelaars in dienst, zodra de inkomsten van het bedrijf wat naar beneden gaan, moet er een keuze gemaakt worden, mensen ontslaan of meer dingen betalend maken.

[Polderdijk]

Werkt dit nu nog steeds op basis van http-requests? Ik heb zelf eigen projecten met ESP32 via MQTT, en dan heb je zeer snelle response tijden.

Paar maanden geleden een keertje getest met ESPHome, draaide zowel instabiel en response tijden van seconden. Niet echt wenselijk voor de meeste zaken.

[FlowinG]

Je kan inderdaad een API (webserver component) aanzetten om via HTTP requests te werken. Ook kan het via MQTT. Maar de integratie tussen ESPHome en Home Assistant gaat via een 'native api'. Die laatste optie gebruikt een "highly-optimized network protocol".

[Reactie gewijzigd door FlowinG op 22 juli 2024 14:41]

[Polderdijk]

Dan ga ik toch nog eens testen met MQTT. Als het aan de HA kant api is, lijkt me geen probleem natuurlijk.

Ben wel benieuwd wat de performance dan zal zijn.

Voor simpelere projecten kan je hier immers heel snel wat opzetten zonder zelf weer code te moeten kloppen.

[dingo35]

Klinkt erg interessant! Ik gebruik nu Tasmota, wat ik daar fijn aan vind is dat ik rules en of tijd schema's kan definiëren die in het device opgeslagen worden, zodat ze zelfs bij uitval van wifi/MQTT/Homeassistant uitgevoerd worden.
Is dat bij ESPHome ook mogelijk?

[FlowinG]

Met ESPhome kan je met behulp van yaml hele uitgebreide automations maken: https://www.esphome.io/guides/automations.html
Deze automations worden op het device zelf uitgevoerd.

Met behulp van lambda's zijn weer zaken mogelijk waar je met de gewone Yaml niet uitkomt, bijvoorbeeld complexe formules.

Oh en als je VScode gebruikt, heb je zelfs intellisense met een plugin!

[Reactie gewijzigd door FlowinG op 22 juli 2024 14:41]

[AJediIAm]

In theory zou http sneller moeten kunnen zijn dan MQTT omdat je de MQTT broker over slaat.
Uiteindelijk komt het allemaal neer op de implementatie.

Ik heb zelf 1 ESPhome apparaatje met een paar sensoren verbonden met http en die draaien al maanden zonder problemen. Response tijd is hier niet merkbaar. Volgens deze review is ESPhome beter voor sensoren en Tasmota beter voor actoren en daar ben ik het wel mee eens.

Voor verreweg de meeste gebruikers lijk ESPhome erg stabiel en betrouwbaar.

[Anoniem: 30722]

Esphome kan over http, api of mqtt. 👍

[jelle2503]

Gaat echt de goede kant op met HA. Gebruik het nu al dik 4 jaar en het blijft maar beter worden. Ik gebruik nog hoofdzakelijk YAML omdat dat voor mij ook prima werkt, maar ik hoop dat het straks voor de gemiddelde gebruiker ook makkelijk instappen is.

Dat HA maar mag groeien totdat er in iedere huishouden een easy to use domotica systeem is met seamless integratie van allerlei apparaten van verschillende makelij.

[langestefan]

Dit is echt super. Ik ben al twee jaar heel tevreden gebruiker van zowel ESPHome als Home Assistant dus dit is wel goed nieuws. De integratie van de twee platformen is nu al vlekkeloos, dat kan alleen maar beter worden met de nieuwe development ondersteuning van Nabu Casa.

[Frankster]

Wow, enigszins onverwacht maar Homeassistant en ESPHome zijn wel een onlosmakelijk verbonden steengoed duo!

[OMEGA_ReD]

Als ik het niet mis heb is onlangs de release cycle van ESPHome gewijzigd, wellicht had deze toen aanstaande overname er mee te maken?!

Verder een goede ontwikkeling, ESPHome is echt de beste custom firmware voor ESP's. Tasmota begint steeds meer bloated te worden en al die SetOptions maken het ook niet overzichtelijk.

[whiner]

Het is alleen jammer dat bijna alle stekkers en lampen niet meer te flashen zijn met tuyaconvert. Hierdoor is esphome alleen nog handig voor de losse ESP chipjes.

Of zijn er nieuwe ontwikkelingen die ik niet weet?
ZigBee is verre van betrouwbaar. Het is altijd duimpje draaien of je conbee alles weer vindt na een herstart. Met esphome devices heb ik dat nog niet gehad.

[arniejj]

Shelly is ook flashbaar met ESPHome. Geeft mij meer mogelijkheden dan de standaard Shelly integratie. Zo kun je ook een flow meegeven in de firmware voor het geval de shelly niet verbonden is met HA. Stuur mijn hue lampen aan via zigbee2mqtt, maar als HA niet verbonden is, dan schakel ik het relais zodat de lampen toch aan/uit gezet kunnen worden.

[whiner]

Bedankt. Nu nog een een lamp .
De filament lampen van de action waren echt prima. Helaas zijn ze niet meer te flashen.

[Niemand_Anders]

Dat kan ook gewoon met de standaard Shelly firmware. Als jij een scheduled inzet dan draait deze 'parallel' van de mqtt/rest api koppeling.

Maar ik heb via de Conbee ook een Zigbee netwerk. Ik heb een aantal lampen als hubs, maar ik gebruik zigbee vooral voor de schakelaars/sensoren van Ikea..

[Anoniem: 30722]

Hopen dat dit de ontwikkeling in esphome wat op gang krijgt. Zit nu vaak lang tussen de releases. Koppeling tussen HA en Esphome was al prima 👌 gebruik beide veel en graag, dus zie het als een goede ontwikkeling 😉