Haier trekt takedownverzoek aan plug-indeveloper in, geeft api-calls de schuld

Haier gaat in gesprek met de ontwikkelaar van Home Assistant-plug-ins naar wie het vorige week een takedownverzoek had gestuurd. In een brief zegt het bedrijf een open api te willen blijven steunen. Het verzoek was verstuurd omdat de plug-in te veel api-calls maakte.

Ontwikkelaar Andre0512 deelt op zijn GitHub-pagina een brief die Haier naar hem heeft gestuurd. Haier kwam vorige week in het nieuws toen het een takedownverzoek stuurde naar Andre0512, die een plug-in voor Home Assistant had ontwikkeld waarmee gebruikers verschillende Haier-apparaten konden aansturen. Haier eiste dat de plug-in offline werd gehaald 'omdat die Haiers diensten op een ongeautoriseerde manier gebruikte'.

Haier heeft nu contact met de ontwikkelaar opgenomen. Het bedrijf zegt daarin waarde te hechten aan open standaarden en verwijst naar het feit dat het veel thirdpartydiensten ondersteunt, net als standaarden als Matter. Het bedrijf zegt ook dat de eerdere brief die het had gestuurd, 'standaard protocol' was binnen het bedrijf. Dat gebeurde omdat het bedrijf een 'substantiële toename' zag van api-calls naar de AWS-omgeving waar Haiers hOn-app mee werkt. Het bedrijf noemt daar geen concrete cijfers bij, maar schrijft die grote toename toe aan de plug-in van de ontwikkelaar. Andre0512 schrijft zelf dat de plug-ins iedere vijf seconden een api-request doen, naast een request bij iedere trigger van een gebruiker. De ontwikkelaar wil van Haier weten wat een realistischer aantal calls zou zijn.

Haier zegt verder samen te willen werken om de plug-in te optimaliseren, zodat die minder geld kost voor het bedrijf. Ook wil Haier 'samenwerken om de community van dienst te zijn'. Het bedrijf wil daarvoor in gesprek met de ontwikkelaar. Haier heeft inmiddels ook een blogpost geschreven met daarin zijn visie op iot-ecosystemen.

Reacties (121)

[D11]

Ik zou liever zien dat er helemaal geen api-calls nodig zijn richting de Haier, maar dat alles op het lokale netwerk afgehandeld wordt.

[dhrto]

Dit dus, snap niet waarom er niet een local api beschikbaar is. Onzinnig om eerst naar buiten te moeten en vervolgens weer terug. Je blijft op deze manier ook nog altijd afhankelijk van (de cloud van) Haier. Wat mij betreft mag de EU hier ook strenger op handhaven, dat alle funtionaliteit van smart apparatuur ook zonder internet / afhankelijkheid van de cloud van de fabrikant beschikbaar moet zijn / blijven.

[SirBlade]

Omdat bijna niemand thuis een server heeft draaien en bijna iedereen internet heeft. Die cloud oplossing moet je anno 2024 toch wel ontwikkelen en onderhouden, het merendeel van de consumenten verwacht/eist dat gewoon. En via een app een apparaat verbinden met je wif netwerk van nog net binnen de technische kennis van de gemiddelde consument. Die paar consumenten die wel de technische kennis en de wil hebben om thuis een server te draaien zijn commercieel gezien niet erg interresant. Ze zijn erg veeleisend, luidruchtig en hebben vaak de vreemdste netwerken. En dan heb je nog de groep die denkt de kennis te hebben en de supportafdeling overbelast. (En die laatste 2 groepen zijn nogal oververtegenwoordigt op tweakers.)

[Rogers]

Je hebt er geen eigen server voor nodig. Mijn Anna thermostaat draait ook lokaal en heeft zo alle features beschikbaar. Het kan gewoon maar de meeste bedrijven vertikken het omdat ze die data van je willen verzamelen.

[rigrig]

Hoe zet je dan je verwarming aan zodra je op weg naar huis gaat? Daarvoor zal er toch ergens een server moeten draaien, en als een fabrikant die toch al neer moet zetten, is het al snel "dubbel werk" om alles ook alleen-lokaal werkend te maken.

[pvcholten]

Het ding kan toch zelf een server draaien?

[Waah]

Is geen dubbel werk hoor. Want die airco zal toch echt zelf de commando's die hij ontvangt afhandelen. Of hij die nu via de cloud krijgt, of via een lokaal wifi... Dat boeit niet.

Maar daar zit geen verdienmodel achter.

Van mij mag de EU hier best naar kijken. En minimaal zorgen dat ALS je servers optuigt, je deze ook online moet houden zonder dat de feature set achteruit gaat. Als dit wel moet, dan de API beschikbaar stellen en lokaal werkbaar laten zijn. Laat de FOSS community maar aan de slag dan.

En als ze toch bezig zijn/meelezen: ook voor games/films/muziek die aangekocht is. Online servers offline? Maak het mogelijk om eigen servers op te zetten.

[SXForce]

Volgens mij werkt het al als je een Apple TV hebt. Die werkt als HomeKit bridge.

Maar klopt idd, lang niet iedereen heeft dat of een server.

[Keneo]

Met Home Assistent

Een server die je draait in je huis.

Waar dit een plug in voor was.

[Rogers]

Dat ding draait zelf een server.

[witchdoc]

Je zet een poort open van internet naar je verwarming met een fatsoenlijke authenticatie erop.
Zie ik het te simpel of ... ?

[erik_t]

Je zet een poort open van internet

Er zijn verschillende mogelijkheden, maar daar komt het wel op neer.

Ik heb in de meterkast op de (OpenWrt) router een OpenVPN server draaien. Al onze smartphones en tablets zijn altijd als client met dit VPN verbonden ("Always-on VPN"). Daarmee is het net alsof je altijd thuis bent.

Maar er zijn ook andere mogelijkheden. Bijv een tunnel over SSH. Of inderdaad, gewoon een poortje openzetten en dan maar hopen dat de server van je verwarmingssysteem. geen zero-day exploits bevat.

[Reactie gewijzigd door erik_t op 22 juli 2024 15:44]

[wild_dog]

ARP call op het locale netwerk om MAC adressen die kunnen toebehoren aan de fabrikant te identificeren en proberen contact te leggen. Dan werkt het in ieder geval lokaal al.

UPnP om een poort te openen op de modem naar de device in kwestie. Paar verschillende methodes om externe IP adress te identificeren, zodat je daar niet van slechts 1 afhankelijk bent, zoals "dig @resolver1.opendns.com myip.opendns.com +short", en die in een configuratie sturen naar de apparaten die je instelt voor afstand besturing. Kan volgens mij zelfs opendns vervangen met het IP adress van de DNS server die DHCP je geeft. En externe verbinding werkt ook.

[Anoniem: 454358]

Data verzamelen hoeft ook niet slecht te zijn, ze kunnen bijvoorbeeld producten en diensten echt beter maken. Zolang die data maar niet wordt verkocht
En zo kunnen ze natuurlijk ook een plus versie verkopen a xx euro per maand.

[Indy81]

Al heb je de allerbeste intenties met die data, dan word je morgen gehackt en ligt die data nog steeds op straat.

[Blinkin]

Als je het goed bouwt heeft je klant geen technische kennis nodig. Alles wat IKEA bijvoorbeeld aan smart home heeft met de hub van hen werkt lokaal en met een gebruiksvriendelijke app. De doelgroep van IKEA is nou niet bepaald de paar consumenten met technische kennis.
Cloud als argument gebruiken voor gebruikersgemak is naar mijn mening niet een heel sterk argument.

[epoman]

Hoewel dat in de basis een vriendelijkere opzet is, zijn die gebruikers in zekere zin nog steeds overgeleverd aan de beschikbaarheid en voorwaarden van een app van Ikea.

Philips Hue werkte aanvankelijk ook prima lokaal, tot ze 'opeens' een account afdwongen.

[Reactie gewijzigd door epoman op 22 juli 2024 15:44]

[Blinkin]

In zekere zin is dat inderdaad een zwak punt. Echter kun je alles ook zonder app gebruiken, dat vergat ik te vermelden.

Dus mocht IKEA ooit failliet gaan en de app verdwijnt dan blijft alles gewoon werken. Je kunt het spul zelfs koppelen aan schakelaars zonder de hub en app te gebruiken. Ook daarvoor is geen technische kennis nodig. Tenzij je een reset knopje 10 seconden indrukken te technisch vind.

Mijn punt is dat volledig lokaal en gebruiksvriendelijk mogelijk is. Mogelijk niet zo interessant als een cloud die data vergaard van je eindgebruikers.

[CAPSLOCK2000]

Omdat bijna niemand thuis een server heeft draaien

Maar iedereen heeft wel het "kastje" van de provider.
Wij noemen dat typisch een router maar uiteindelijk is het gewoon een kleine computer.
Sterker nog, het hele doel van zo'n ding is het lokale netwerk verbinden met het grote internet. Tegenwoordig liefst ook nog een beetje veilig.

Dat apparaat lijkt dus ideaal om dit soort dingen te regelen, geen aparte server nodig.
We hebben alleen aan handige interface nodig om aan te geven wat er aan de buitenkant beschikbaar moet zijn en wat niet mag worden doorgegeven. Eigenlijk dus gewoon een firewall.

Niet iedereen wil die met de hand configureren dus eigenlijk hebben we nog een manier nodig om automatisch toegang te geven voor nieuwe apparaten. Daar is een standaard voor, UPNP, maar eerlijk gezegd is dat nogal een draak en de ontwikkeling nogal stil.

De reden daarachter is ook de reden dat het niet op korte termijn gaat veranderen: zolang we afhankelijk zijn van IPv4 met een dubbele of zelfs driedubbele laag NAT is het erg lastig om van buiten naar binnen te komen. Dit hele probleem zou eigenlijk verdwenen als ieder apparaat een eigen "echte" ip-adres zou hebben, in plaats van dat we een hele woning een enkel adres laten delen.
Misschien dat het allemaal goed komt als de migratie naar IPv6 is afgerond, maar ik denk dat het dan al te laat is en de wereld heeft geaccepteerd dat internet vooral een-richting broadcast geworden is in plaats van peer-to-peer

[BeosBeing]

De reden daarachter is ook de reden dat het niet op korte termijn gaat veranderen: zolang we afhankelijk zijn van IPv4 met een dubbele of zelfs driedubbele laag NAT is het erg lastig om van buiten naar binnen te komen. Dit hele probleem zou eigenlijk verdwenen als ieder apparaat een eigen "echte" ip-adres zou hebben, in plaats van dat we een hele woning een enkel adres laten delen.

Klopt. Als ieder apparaat dat internet-toegang nodig heeft IPv6 zou ondersteunen, dan kon je NAT afschaffen en dan zou je voor intern gebruik binnen de woning nog prima IPv4 kunnen blijven gebruiken.
Uiteraard moet dan de beveiliging door de router op IPv6 goed zijn, maar voor de interne IPv4 zou die dan zelfs wat soepeler kunnen, en iedereen die oude meuk gebruikt die alleen IPv4 ondersteund zou dan automagisch beschermd zijn - uiteraard tot een aanvaller via een IPv6-apparaat op het interne netwerk komt..

[NC83]

Ja maar je zou ook gewoon het docker image dat in de cloud draait beschikbaar kunnen maken met instructies om het zelf te draaien lokaal. Dat zou al een hoop helpen met het niet meer nodig hebben van een cloud.

[kiang]

Dat snap ik wel, maar het is tegelijk ook gewoonweg achterlijk dat men dus een smarthome product bouwt dat ALLEEN via je eigen cloud infra is aan te sturen, en dat je dan gaat klagen als mensen er "te veel" gebruik van maken en dat het je dus geld kost om die infra te onderhouden.

Ja muts: als je zorgt dat alles lokaal werkt heb je dat probleem dus niet.

[jj42]

ik vraag me nu ook af hoeveel meer hun klanten betalen om die dure cloudomgeving te financieren.

[cascer1]

Die paar consumenten die wel de technische kennis en de wil hebben om thuis een server te draaien zijn commercieel gezien niet erg interresant.

En daarom is er wetgeving nodig om het toch te dwingen.

[jayjay_seal]

Een app kan ook gewoon lokaal naar het apparaat verbinden. Het zou pas naar de cloud moeten verbinden als het dit niet kan (omdat je niet thuis bent bijvoorbeeld).

Het is natuurlijk makkelijker programmeren als alles naar 1 doel gaat (de cloud).

Mijn inverter doet dat bijvoorbeeld al... die verbindt ook standaard met de cloud. Maar als je wil kun je in de inverter de API calls lokaal naar je app (of iets anders) sturen (en hem eventueel helemaal afschermen van het internet)

[Reactie gewijzigd door jayjay_seal op 22 juli 2024 15:44]

[jaenster]

Tegenwoordig hebben apps op ios hier wel extra access voor nodig, om ip's aan te spreken op je lokale netwerk.

[jayjay_seal]

Dat ligt dan eerder aan de fabrikant van de hardware die je gebruikt. Dat is geen reden om het niet aan te bieden.

Overigens ben ik nog steeds van mening dat het onderhouden van infra in de cloud waarschijnlijk vele malen duurder is (je moet het online houden en krijgt er eigenlijk niets voor terug).

[Reactie gewijzigd door jayjay_seal op 22 juli 2024 15:44]

[ilaurensnl]

Persoonlijk met je eens, maar er kunnen restricties zijn m.b.t. hardware waarbij b.v. er nog een lokaal API erop aansluiten niet mogelijk is of ter nadeel van de huidige cloud gedeelte.

Ik kan me ook voorstellen dat er meer onderhoud nodig is, ook op lokale gedeelte om; ook om het veilig te houden enzovoort.

Maar inderdaad! Ik wil graag op zijn minst back-up opties zien zodat we een gegarandeerde lange ervan kunnen genieten; leuk die CLOUD maar een airco heeft een levensduur van 15 a 30 jaar (hopelijk) en in de tussentijd kan er veel gebeuren, niet alleen dat hun support droppen maar bedrijven die failliet gaan b.v.

[thomasv]

In mijn ervaring, als het apparaat met een api communiceren kan, kan er ook mee gecommuniceerd worden (ook tegelijkertijd). Het kost nagenoeg niks meer om een embedded systeem (bijvoorbeeld op basis van een esp) te maken wat dit kan qua hardware. Het kost je ontwikkeling qua software, maar dat kan meegenomen worden in het budget van het gehele apparaat.

[Reactie gewijzigd door thomasv op 22 juli 2024 15:44]

[hiostu]

Wanneer de leverancier gebruik maakt van een IoT oplossing van een cloud provider er al ontzettend veel geregeld wordt zonder al te veel development kosten. Heel de infrastructuur inclusief beveiligen van connecties, firmware deployments, certificaat beheer, communicatie tussen devices, portalen, user managment, etc. Wanneer ze dit dan allemaal lokaal ook moeten ondersteunen, inclusief firmware deployments, dan moeten ze ineens extra effort erin stoppen. En dat kost ze uiteindelijk veel meer effort en geld.

[thomasv]

Strategisch slechte keuzes kunnen inderdaad uitgelegd worden door te zeggen dat het "meer effort en geld" kost om het anders/beter te doen.

Nu krijgen ze een hoop negatief daglicht, want dit verschijnt wellicht nu pas op tweakers maar er wordt al een aantal dagen over gebashed op Haier via andere kanalen. Wat kost dat je als bedrijf (lastig harde cijfers aan te koppelen, imago enzo).

[Reactie gewijzigd door thomasv op 22 juli 2024 15:44]

[hiostu]

Dat is niet zo zeer de keuze die ze hebben gemaakt met een eventuele inzet van cloud diensten. Dat heeft meer te maken met de manier waarop ze de communicatie aan hebben gepakt.

Strategisch kan het een hele goede keuze zijn geweest om voor een cloud oplossing te gaan. Veel van deze bedrijven hebben helemaal niet de technische kennis om een dergelijk platform op te zetten. Zeker niet op een veilige en schaalbare manier. Dan kan het bedrijf zich richten op hun core business en kennis. Echter zo maar een seize en desist sturen, was gewoon geen handige move.

[GeroldM]

Die hele gang naar de cloud, als IT toch zo'n moeilijk onderdeel van de bedrijfsvoering is, waarom het dan uitbesteden aan een grote toko als een cloud-boer? Want daar is je bedrijf niets meer dan een nummertje, en zal je ook nooit meer worden dan een nummertje.

Terwijl je je IT ook had kunnen uitbesteden aan een (kleiner) IT bedrijf bij je in de buurt, waar je wel wat in de pap te brokkelen hebt als het gaat over op maat gemaakte oplossingen waar je als bedrijf meer aan hebt.

Maar nee, alles en iedereen maar aan de eenheidsworst wat de cloud is, onder de noemer 'veiligheid'. Of het je opvalt of niet, dat weet ik niet, maar het aantal reportages van hacks/malware/ransomware is nou niet bepaald afgenomen sinds de "cloudgang". Je kan net zo lang blijven goochelen met cijfers en weetjes, maar effectief gezien is de cloud weinig beter.

Wat de cloud wel is, is een computerpark wat snel opschaalt zonder dat je daar meer voor moet dan dan je beurs trekken.De cloud-boer van je keuze is echter minder rap met afschalen, want elke minuut/seconde/verplaatste bit die zij uitvoeren kost jouw geld. De cloud-boer van jouw keuze is ook zwaar geneigd om aan 'vendor lock-in' te doen. Elke omgeving van elke cloud-boer is vooral hun eigen eenheids-worst, waar je niets over te zeggen hebt en zij met heel andere tarieven werken als jij je data uit hun cloud-omgeving transporteert. Het kost erg weinig om je bedrijfsdata bij hen te stallen. Wil je het echter verplaatsen, of in een multi-cloud omgeving onderbrengen (om 'vendor lock-in' tegen te gaan), dan kost die brug tussen omgevingen ineens heel veel meer. Zoveel meer dat cloud-repatriering een ding is geworden. Ken al voorbeelden van bedrijven die jaarlijks zo veel aan cloud-kosten hadden, dat zij hadden doorgerekend dat het uitbreiden van hun kantoor, de aanschaf van extra apparatuur, de extra energie kosten en extra personeelkosten, dat dit minder was dan hun jaarlijkse cloud-kosten.

Nu WFH een ding is, is er wereldwijd veel minder vraag naar kantoorruimte. Er is dus plaats genoeg voor kantoren die er nog wel zijn, om deze uit te breiden voor extra apparatuur. Als je lang genoeg met cloud-oplossingen werkt, dan ben je misschien alweer gewend geraakt aan de lag. Ben je toch weer blij verrast als je op een lokale server (on-premise) werkt. Voelt vele malen meer responsive...omdat het dat ook is.

Mijn on-premise Promox cluster schaalt bijna net zo snel als de cloud-boer doet. En laten we wel wezen, de cloud-boer schaalt maar wat graag voor je bedrijf op, maar zij weten ook dat de financiele afdeling van je bedrijf daarover eerst dagen moet debatteren of die extra kosten wel gedragen kunnen worden. De belofte van op- en afschalen is er wel, maar hoe effectief deze is, dat ligt vooral aan de financiele afdeling, waardoor het alsnog lang duurt voor je iets nieuws uit kan rollen.

Nou ja, iets "nieuws", meer eenheidsworst wat de cloud-boer van jouw keuze maar al te graag aan je maandelijkse abbo-kosten toe wil voegen. Want dat is alsmaar meer 'vendor lock-in'.

De cloud is een mooie belofte, zou zelfs zo ver willen gaan als een mooi concept. Maar het is gevuld met bedrijven die je het vel over de oren willen (en zullen) trekken, zodra je ze een hunt van een kans geeft.
Voorstanders zien niet veel verder dan de mooie beloftes, realisten zien de ware natuur van de bedrijven die de cloud "bevolken". Hun mentaliteit is praktisch hetzelfde als de bedrijven die in de jaren '70, '80 en zelfs in de '90-er jaren main-frame oplossingen bij bedrijven neerzetten. Betalen voor elke computationele 'poep en scheet', niets te zeggen over de hard- en software, onderhoud ervan op het tempo van de uitbater van de main-frame. En elk jaar een vernieuwd contract, wat nooit goedkoper uitviel voor het bedrijf met de nood voor een main-frame.

Een computer thuis en op de bedrijfsvloer kwam toen amper voor, maar die geldwolven-mentaliteit was een van de redenen dat personal computers zo'n vlucht hebben genomen sinds de jaren '90. Net zoals de software-ontwikkeling trouwens. Deze sprong naar 'vrijheid' heeft echter amper 30 jaar volgehouden, want daar was de cloud. Afgestoft en opgedoft, maar nog altijd dezelfde mentaliteit. En iedereen die nog nooit de ellende met main-frames heeft meegemaakt, kan niet wachten om weer in die val te trappen.

[demartijn]

Mooi betoog. Leuk om te lezen. En eens mbt de aversie tegen clouddiensten.

[jayjay_seal]

Ze willen mensen pushen naar de cloud.... Als ze het gewoon ook lokaal ondersteunen... dan moeten ze zich geen zorgen maken over te veel API calls op hun netwerk....

Als ze zowel lokaal en cloud ondersteunen en ze programmeren het een beetje leuk... dan kun je als je thuis bent lokaal het apparaat aanspreken en ben je niet thuis dan de cloud.

Minder API calls in de cloud, Iedereen blij...

[Reactie gewijzigd door jayjay_seal op 22 juli 2024 15:44]

[hiostu]

Nee, ze willen een connected device maken wat makkelijk in gebruik is voor 99% van de klanten. En dan is de cloud heel makkelijk om een infrastructuur neer te zetten die dit ondersteund en tegenwoordig relatief eenvoudig en veilig is neer te zetten, zonder een heel team met specialistische kennis in te huren. Dat is veel lager in kosten uiteindelijk dan ook iets te bouwen wat lokaal werkt.

En als jij je infrastructuur en devices zo bouwt dat ze elke 5 minuten pollen, er komt iemand die elke 5 seconde gaat pollen naar je API dan levert dat ineens wel veel meer kosten op, op je platform.

Waarom zou je ook elke 5 seconde een API call doen voor iets als het aansturen of uitlezen van een airco?

Stel je hebt 25000 devices die je hierop aansluit, dan zit je al op 430 miljoen API calls per dag extra.

[jayjay_seal]

Als ze lokaal ookaangesproken kunnen worden dan leverd dat ook winst op... nl de API calls die niet meer over hun netwerk moeten lopen.

Tevens is er dan snelheidswinst voor de APP zelf :-) die moet dan nl niet eerst naar buiten om vervolgens weer terug binnen te komen om vervolgens weer naar de cloud naar buiten gestuurd te worden waar de klant zijn gegevens kan ophalen.

Ik vraag ook niet om de cloud functie uit te zetten... maar gewoon om hem lokaal ook beschikbaar te maken. het is een WIN/WIN situatie

[Reactie gewijzigd door jayjay_seal op 22 juli 2024 15:44]

[hiostu]

Het is geen win/win situatie voor veel bedrijven. Dat probeer ik juist te zeggen. De kosten en kennis die er mee gemoeid zijn om een platform te bouwen dat lokaal en cloud ondersteund is veel complexer en vereist doorgaans veel meer maatwerk dan een standaard cloud oplossing voor IoT te gebruiken.

En de kosten voor dit specifieke personeel om dit te bouwen zijn veel hoger. Tevens is dat lokaal gebruik voor misschien 1% van de klanten interessant en het levert ze dus uiteindelijk weinig extra business op. Terwijl het wel een hoop extra kosten met zich meebrengt en ook minder flexibiliteit.

[jayjay_seal]

Toch zijn er fabrikanten die dit al (langer) aanbieden (Huawei) bijvoorbeeld.Dus zoveel extra zal dit ook niet kosten.

[hiostu]

Huawei heeft wel een aardig stuk grotere IT afdeling en development capability dan een Airco fabrikant. Die zitten veel meer op embedded van oorsprong. Gewoon hele andere in house kennis en kunde.

[jayjay_seal]

Dus kiezen ze er voor om een cloud service jaren lang in de lucht te houden voor een hoog bedrag waar ze niets voor terug krijgen... Interessante keuze...

Hoe lang blijft dat duren?

[Reactie gewijzigd door jayjay_seal op 22 juli 2024 15:44]

[xFeverr]

Voordeel van alles gewoon lokaal laten draaien is dat je ook veel lagere doorlopende kosten hebt. Die cloud-infrastructuur moet een stuk dikker zijn uitgevoerd als het allemaal daarlangs moet. Maar als ik gewoon op mijn lokale netwerk blijf om te zien hoe lang het duurt voor mijn wasmachineklaar is, dan hebben ze ook een stuk minder te verwerken. Het liefste helemaal niets zelfs.

[vincenttor]

Zijn ook oplossingen met een esp, ik ga daar ook direct gebruik van maken .
Liefste voorkom ik in huis zover mogelijk cloud service based apparatuurgeen internet geen besturing zoals je gewend bent dan .

[BeosBeing]

Maar inderdaad! Ik wil graag op zijn minst back-up opties zien zodat we een gegarandeerde lange ervan kunnen genieten; leuk die CLOUD maar een airco heeft een levensduur van 15 a 30 jaar (hopelijk) en in de tussentijd kan er veel gebeuren, niet alleen dat hun support droppen maar bedrijven die failliet gaan b.v.

De airco bij mijn tante heeft daar zeker 50 jaar gedraaid. Dat ding maakte de laatste 15 jaar een hoop herrie, maar lag achter in te tuin en idereen in de buurt daar heeft airco (ook wel nodig met zomertemperaturen vanaf 40° en een luchtvochtigheidsgraad van >90% in Noord-Oost Texas).

[demartijn]

Haha BeOS, dat is lang geleden. Bestaat dat nog?

[BeosBeing]

Haha BeOS, dat is lang geleden. Bestaat dat nog?

Er is nu een open source opvolger. Aanvankelijk heette het OpenBeOS maar ter vermijding van copyright infringemenr en omdat de foutmeldingen van BeOS werden gegeven als Japanse Haiku, heet de opvolger Haiku.
https://www.haiku-os.org/
https://distrowatch.com/table.php?distribution=haiku
https://en.wikipedia.org/wiki/Haiku_(operating_system)
https://nl.wikipedia.org/wiki/Haiku_(besturingssysteem)
https://www.youtube.com/watch?v=-NMDYT-hCOk

Destijds zijn er diverse projecten geweest om BeOS nieuw leven in te blazen.
1) het Duitse Yellowtab, dat oorspronkelijk een Duitse vertegenwoordiger was van BeOS, verkreeg in 2003 een groot deel van de broncode van BeOS en lanceerde Zeta. In 2006 verkeerde Yellowtab in insolventie, gave de broncode van haar Intel Extreme driver aan het Haiku project en daarna nam Magnusoft de ontwikkeling van Zeta over. De laatste versie van Zeta was een upgrade naar 1.5 sp1 uit 2007 (met rudimentaire multiuser-support) waarna de ontwikkeling is stopgezet vanwege ontbrekende licentierechten. In 2001 had Palm de rechten opgekocht van BeOS en Be Inc.. Palm splitste in 2002 in Palmsource en Palm. PalmSource werd overgenomen door Access. Palm werd overgenomen door HP in 2010. HP verkocht Palm's WebOS door aan LG en van 2014-2015 werd Palm doorgeschoven naar TCL dat o.a. telefoons maakt onder de namen Alcatel en Blackberry.
Review: https://www.osnews.com/story/17518/review-zeta-15/

2) PhosphurOS uit 2004, een andere spin-off van Beos Dan0, uiteraard volledig illegaal, en nergens te vinden maar er is wel een review.
https://www.osnews.com/st...dan0s-unapproved-brother/

3) Blue Eyed OS, gestart in 2001 en gebaseerd op een Linux kernel waarbij men net als bij Wine probeertde de API's te vertalen. Dit is echter nooit goed van de grond gekomen.
https://fr.wikipedia.org/wiki/BlueEyedOS
http://www.blueeyedos.com/about/index.html
http://www.blueeyedos.com/

4) ZevenOS, een Ubuntu-derivaat gestart in 2008 waarmee men de look en feel van BeOS probeerde te recreëren. De eerste versies waren gebaseerd op Ubuntu, versie 2.0 van 2009 was gebaseerd op Xubuntu. In 2010 kwam versie "1.9 Neptune" gebaseerd op Debian en na een paar parallelle releases waren de laatste versies "3.3 Neptune" in 2013 en de Xubuntu-gebaseerde 6.0 in 2015. De huidige Neptune 8.0 is gebaseerd op Debian en KDE maar heeft geen relatie met BeOS.

ZevenOS 2.0 heb ik geprobeerd maar het voelde erg buggy.
Uiteindelijk is een Linux met het uiterlijk van BeOS natuurlijk helemaal niet interessant. Waar het im gin waren het indexing BeFS filesystem en de gigantisch efficiënte kernel, en dat laatste is waar Haiku mee bezig is.

[Reactie gewijzigd door BeosBeing op 22 juli 2024 15:44]

[jayjay_seal]

Hardware restricties zijn tegenwoordig makkelijk op te vangen met een simpel (bijvoorbeeld) ESP bordje van een paar euro. Je zorg er voor dat de data van je apparaat via de ESP naar de cloud gestuurd wordt (daar had je voorheen al hardware voor nodig van een paar euro) en je zorg er voor dat de API ook lokaal kan worden aangesproken (dat is niet het allermoeilijkste gezien je alles al naar de cloud pushed met alle security protocollen er al in.... en OK... dat is misschien extra werk... maar vast niet zoveel als het beveiligen via de cloud en het onderhouden er van. Dat blijven nl kosten die terugkeren en kan in het uiterste geval de terloogang van je bedrijf betekenen).

Je geeft de klant via een (verborgen of goed weggewerkte) optie de mogelijkheid local access aan of uit te zetten (en eventueel cloud in of uit te schakelen). Dan kun je nog altijd cloud pushen als default.....

je gaat waarschijnlijk meer verkopen aan al die homeassistant nerds en consorten die je product willen vanwege deze optie.... Persoonlijk ben ik bij de bouw van ons huis nl. juist naar die producten opzoek geweest.

het feit blijft gewoon eerder......"We want your data!".......

[Reactie gewijzigd door jayjay_seal op 22 juli 2024 15:44]

[dacoon]

Vanuit een technisch perspectief inderdaad niet zinnig, echter vanuit een commercieel vlak wel:

• Fabrikant houdt controle over welke functionaliteit beschikbaar wordt gesteld
• Dienstverlening kan "verbeterd" worden aan de hand van zichtbare trends in API gebruik (veel gebruikte functionaliteit achter paywall, 3rd party functionaliteit aan eigen dienst toevoegen)
• Service kan als abbonement aangeboden worden
• Op basis van jouw API calls kan de leverancier een dataprofiel opstellen wat weer de verkoop in kan

[mjl]

Ik snap het wel want Haier wil de informatie hebben en weten wat er van geconsumeerd wordt.

[bzuidgeest]

De machine krijgt zijn informatie niet magisch. In principe zou je dus een eigen Haiser server kunnen emuleren. Zoals bijvoorbeeld ook gedaan is voor de live services op de originele Xbox. Dat kost echter veel meer moeite dan dezelfde api aanspreken als de app doet.

Als Hauer geen calls naar hun services will, maken ze maar een local api

Maar net als jij vind ik dat de eu een lokale api moet afdwingen en als een apparaat niet meer ondersteund wordt moet de software/protocollen/keys worden vrijgegeven zodat een ander altijd door kan. En er geen brick op de afval hoop komt als het even kan.

[lenwar]

Op de eerste plaats ben ik het helemaal met je eens dat alles lokaal moet ‘kunnen’ en dat via internet een leuk extraatje zou moeten zijn en niet andersom.

In mijn onderstaande verhaal ga ik uit van een fabrikant die gewoon daadwerkelijk een goed product wil maken en niet data wil verzamelen voor discutabele doeleinden. Want dat is even om een andere factor die mee kan spelen.

Echter kan een lokale api natuurlijk ook weer voor z’n eigen problemen zorgen.
Er hoeft maar een klein foutje in te zitten en je apparaat kan op een botnet aangesloten worden of zo. (Dus wel op internet rottigheid uithalen, maar niet naar een cloud)
Uiteraard kan dit ook met cloudverbonden apparaten, maar nu komt er dus weer een factor bij.

Hier komen dan natuurlijk zaken als patchen en zo bij kijken, maar als hij niet met de cloudverbindingen werkt, is dat moeizaam. Dan moet de klant dat zelf doen.
Leuk voor ons, niet voor m’n moeder. (Dit geldt ook voor vlans, firewalls, enz.)

Onder aan de streep is het gewoon makkelijker om alleen een clouddienst te hebben vanuit de fabrikant. Er hoeven geen ingewikkelde mechanismen bedacht te worden over hoe een app weet dat hij lokaal is of juist niet, in alle omstandigheden, enz, enz, enz.

Dit gezegd hebbende zou ik zelf nooit een stuk witgoed op het internet aansluiten. Dan maar geen app voor m’n koelkast/wasmachine/airco.

[Anoniem: 718943]

Ik heb laatst een brennenstuhl 'slimme' stekker gekocht. Om die te gebruiken moet ik een account aanmaken en toestemming geven voor gps gebruik. Enkel om vanuit de bank buiten een streng lichtjes aan te kunnen zetten.

Het is van de zotte.

[johnny2000]

Tja local is een mooi streven het zorgt er ook voor dat bij een faillissement niet met ewaste zit.

Als het dan toch via de cloud moet. Ik vind dat Bosch/Siemens het wel mooi doet met hun Home connect. Je kan developer account aanmaken en dan bijv. met oauth verbinden met Home Assistant. Ze zijn heel transparant met het aantal Requests wat je mag doen en die zijn ook meer dan toereikend.

Ook goed documentatie en ze stimuleren het ook... Ook intern.

[Anoniem: 454358]

Faillissement? Eerder dat ze over gaan op een nieuwe versie, en de oude api gewoon offline gaat.

[Dennahz]

Dat zou bij wet verboden moeten zijn. Als je een product uitbrengt moeten de services die eraan verbonden zitten gewoon blijven werken. Oftewel moet je een firmware update uitrollen zodat het apparaat lokaal te benaderen is via een API.

[Waah]

Zou moeten maar is niet zo. Zeker bij een airco die toch wel 20+ jaar moet draaien.

Welke app ken jij die al 20 jaar bestaat? Ik geen, en zeker niet van een hardwarefabrikant die software "erbij" doet.

Daarom hier een MHI die (via een ESP) lokaal aan te sturen is.

[Anoniem: 454358]

winrar
btw, zie gta 5 daar zijn de ps3/xbox360 servers ook gewoon al offline en kun je het niet meer 100% spelen zoals de bedoeling was.

[BeosBeing]

Zou moeten maar is niet zo. Zeker bij een airco die toch wel 20+ jaar moet draaien.

De airco bij mijn tante heeft daar zeker 50 jaar gedraaid. Dat ding maakte de laatste 15 jaar een hoop herrie, maar lag achter in te tuin en idereen in de buurt daar heeft airco (ook wel nodig met zomertemperaturen vanaf 40° en een luchtvochtigheidsgraad van >90% in Noord-Oost Texas).

[FrankHe]

Bedrijven laten ondersteuning voor 'oude' producten geregeld snel vallen waarbij 'oud' nog weleens een rekbaar begrip lijkt te zijn. Het laten vallen van ondersteuning komt vaker voor dan dat een bedrijf om economische redenen ophoudt te bestaan.

[CorbataGames]

En als ze dat niet willen, next best thing: webhooks in laten stellen, dan ben je er ook voor 99% vanaf.

[xleeuwx]

In mijn optiek hoe dan ook een betere variant. Nadeel is echter dat veel HA oplossingen achter een NAT/Firewall staan.

[Svrooij86]

Beetje dit https://svrooij.io/2024/01/21/local-api-appliances/

En bijvoorbeeld Thermosmart die failliet gaan, dan een doorstart maken en een half jaar later alsnog alle “servers” uitzetten zodat iedereen met een domme thermostaat zit die ineens niet meer smart is.

[LauLaman]

Ik deel deze mening en ben daarom een petitie gestart welke vraagt om wetgeving die lokale APIs voor smarthome verplicht maakt voor fabrikanten.

Tekenen kan hier

Graag zou ik dit op Europees niveau geregeld zien maar dat heeft iets meer voeten in de aarden.
Meer info hier

[mbbs1024]

Inderdaad, als een fabrikant een storing heeft op de server, of gehacked wordt, wordt het zogenaamde slimme apparaat in het beste geval een dom apparaat, of erger, klaar voor de vuilnisbelt, of een ingang voor hackers tot je interne netwerk.

[GranCanaria]

Waarom stuurt dat ding elke 5 seconden en request die kant op? weet iemand dat? Het lijkt wel om een token of iets in leven te houden.

Ik kan overigens wel begrijpen dat er limieten op api's zitten. Sterker nog er zijn zat bedrijven die een x aantal requests gratis aanbieden en daarna kosten in rekening brengen voor meer dan de normale toegastane hoeveelheid calls.

Denk dat Haier zicht rotgeschrokken heeft van de toename van call richting hun api. Die dachten waarschlijnlijk dat ze gehacked zouden worden of iets. Naast de oplopende kosten bij AWS.

[ronaldmathies]

Kan ook een status update request zijn. Als ze zelf alleen een app hebben dan zal die alleen requests sturen wanneer de app actief is en dus veel minder requests sturen.

[dasiro]

5 seconden is imho wel héél vaak, dat zijn 7200 requests per dag per device. Zelfs UPS'en ga ik niet zo vaak pollen om te zien wat er allemaal loopt

[GranCanaria]

ah ik lees het een stukje hierboven inderdaad. Dat zou goed daarvoor kunnen zijn. Ik ken de apparaten verder helaas niet dus daar kan ik niet over meepraten maar denk wel dat er makkelijkere manieren te verzinnen zijn om dit probleem op te lossen. Misschien moet er dan ook wat bij haier aangepast worden in de webservice.

[Soldaatje]

Ze hadden ook gewoon het aantal calls kunnen limiteren per dag of uur of zo, lijkt me effectiever dan een takedown-verzoek.

[GranCanaria]

Ja ik begrijp inderdaad ook niet waarom ze er geen limiet op hebben zitten. Maar nogmaals, ik begrijp het wel van Haier. De kosten kunnen namelijk flink oplopen.

[laurens0619]

Die 5sec was puur een status update.
Bv: Staat de wasmachine aan? 5sec wachten. ennu? 5 sec. ennu? etc etc..

Komt uiteindeijk neer op belang.
Het belang van de developer is dat de plugin zo accuraat mogelijke informatie geeft.
Developer heeft geen belang bij de load op de server van de leverancier.
Waarom zou de developer niet iedere 5 sec pollen?
Tot nu toe dan

[latka]

Omdat bij het idee van een webservice pollen je als ontwikkelaar direkt vlekken in je nek zou moeten krijgen... Zowel bij het ontwerp (Haier) als de plugin-developer. Alhoewel die laatste niet echt een keus heeft als er al zo'n brak ontwerp staat.

[GranCanaria]

Ben ik het volledig mee eens. Wij moeten daar ook dagelijks over nadenken en slimme dingen voor verzinnen.

Maar kort samengevat , bij ons zal een developer niet zo snel zo’n call doen omdat hij / zij weet dat je daarmee een backend over de zeik kunt krijgen.

[arnoud_h]

Reken maar dat de finance afdeling van Haier rode vlekken zijn nek kreeg toen het aantal API calls verviervoudigde de afgelopen dagen (fictief aantal van mijn kant).

De kosten daarvan kunnen er op jaarbasis enorm inhakken.

En dan krijg je intern de discussie: "hoeveel extra airco's gaan we dit jaar hierdoor verkopen? Ook vier keer zoveel?"

[laurens0619]

Eens, Maar dat is dus belang van Haier

de homeassistant ontwikkelaar boeit dat minder, die wil vooral werkende en actuele data.

Als bedrijf moet je met dat belang rekening houden. Zet je er bv rate limiters of extra kosten na x calls op dan is het opeens wel belang van HA ontwikkelaar om niet zo vaak te pollen

[arnoud_h]

Ja natuurlijk, maar dan zal toch echt de finance afdeling weer om de hoek komen kijken. Stel ze hebben zelf een service zo ingericht dat het met minimale aantal API calls een eigen service gebouwd kan worden, en dan ineens een hobbyist die kosten laten exploderen?

De HA ontwikkelaar heeft naar mijn mening ook een bepaalde verantwoordelijkheid om na te denken wat zijn acties voor feitelijke en financiële gevolgen heeft voor de service waar hij inhaakt. Het is geen recht om van een bestaande cloud service gebruik te maken.

Om een idee te geven: bij mijn werkgever hadden ze een bepaalde bandbreedte aan cloud calls ingekocht voor een wireless management systeem. Daarop een schatting gemaakt van de kosten. Na een jaar bleek dat ze echt een heeeeel veelvoud van de verwachte API calls genereerden. De AWS rekening kan dan ineens bijzonder rauw op je dak vallen. Geloof me, dat levert heel wat hooggespannen meetings op.

[GeroldM]

Snap je punt, maar als uitgaves je (als bedrijf zijnde) toch zo hoog zitten, dan kun je bij de gemiddelde cloud-boer ook aangeven: tot bedrag x en niet meer. Dan creeer je een misschien een situatie "aan het eind van mijn geld is nog zoveel maand over", maar dat lijkt me meer wenselijk dan een (te) hoge rekening.

Het had dan ook meteen aangegeven dat de inschatting er compleet langs zat en dat deze dus moeten worden besproken. Dan was er misschien ook wel een inzicht bij de beslissingnemers ontstaan dat die bepaalde service veel kost en er voor andere (technische) oplossingen gekozen dient te worden.

Beter dat schip ten halve gekeerd, dan ten hele gedwaald. Dat die keuze om het bedrag vast te leggen niet is gemaakt, dat kan je het bedrijf kwalijk nemen. Je hoeft in elk geval niet te rekenen op alteveel medewerking van de gemiddelde cloud-boer. Deze leveren en rekenen maar al te graag voor geleverde diensten. En zij zitten in de situatie dat jij als bedrijf van hen afhankelijk bent (gemaakt), dus dat geld word hoe dan ook wel binnengeharkt.

En nee, de gemiddelde cloud-boer ligt er helemaal niet wakker van als zij jouw business verliezen. Want als jij (als bedrijf) denkt dat je een grote klant bent, dan laat de gemiddelde cloud-boer je graag in die waan. Want er is altijd wel een grotere klant, waar de gemiddelde cloud-boer harder voor loopt dan voor jou (als bedrijf zijnde). Voor jou 10 anderen.

Dat SLA contract dat je met de gemiddelde cloud-boer bent aangegaan? Als het goedkoper blijkt om niet aan 99.9% of 99.99% of 99.999% uptime te voldoen, dan zal men daar eerder voor gaan dan jou (als bedrijf zijnde) de afgesproken uptime te leveren. Dat is geen goede reclame, dus men zal er wel moeite voor doen, maar hun dienst is een keiharde business en leuke winsten zijn te halen, maar ook veel kosten aan zijn verbonden.

Een accountant een middag verschillende scenarios door laten rekenen om daarmee te bepalen wanneer het goedkoper is om niet je SLA te voldoen, daar kun je zeker van zijn dat je cloud-boer dat gedaan heeft.

Nu heb jij (als bedrijf dat cloud-diensten via je produkt aanbiedt aan je klanten) daar niets mee te schaften. Totdat je 'nee' moet verkopen aan je clientele. want dat loopt op in kosten. Kosten die hoger liggen dan een lokale API aan te maken en te onderhouden.

[jayjay_seal]

Misschien krijgen ze minder rode vlekken als ze beide opties aanbieden... lokaal en cloud.

Ben je thuis lokaal connect (geen cloud API calls = gratis voor hun)
Ben je onderweg dan naar de cloud...

wat ook het logischer is...

[slijkie]

Ergens wel logisch, als een plugin jou open API ineens veel meer kosten laat maken (dus niet enkele dollars per maand), snap ik wel dat men actie onderneemt.

[jaapzb]

Het had natuurlijk andersom gemoeten. Eerst met de developer in gesprek gaan, en dan pas cease and desist brieven gaan sturen als je er niet uit komt.

Ze trekken nu gewoon de keutel in omdat er ze er nu achter komen dat dit toch net een iets te groot PR-probleem aan het worden was.

[Dennism]

Wat ik me in dit soort gevallen dan afvraag, waarom gaat de developer van zo'n plugin niet eerst in gesprek, dan heel zo'n dansje niet nodig omdat die dan vooraf kennis heeft gegeven van wat zijn bedoelingen zijn en eventuele vragen, bijvoorbeeld over het aantal API Calls, kan stellen voor ontwikkeling van de plugin (of general release van de plugin, als je toch eerst een PoC wil maken.

[bjp]

omdat ze er wss eerst niet op reageren?

omdat de developer niet weet dat het een probleem is?

[djwice]

Er zijn hele nette HTTP status codes waarmee Haier had kunnen laten weten dat er te weinig tijd tussen de verzoeken zit.

Ook de OpenAPI standaard (voorheen Swagger) heeft een definitie waarmee netjes per API kan worden aangegeven hoeveel requests je als platform eigenaar maximaal toe wil staan.

Als ontwikkelaar kun je daar dan rekening mee houden, vaak genereren tools je cliënt op basis van de OpenAPI definitie. Dus als daar een limiet in staat, is honoreren eerder regel dan uitzondering.

En typisch gebruikt ook de API Gateway of Firewall die de API host ook de OpenAPI definitie om de rate limiter in te stellen. Zo zijn de ook de HTTP status codes netjes op op de afspraak afgestemd.

Zelf kies ik altijd 1/3 ofzo van de max, zodat ik zeker weet dat mijn app niet tot last zal zijn van de server. En in m'n code meet ik de response snelheid, neem die af en wijkt relatief veel af van de normaal, dan is de server of het netwerk blijkbaar onder zwaardere belasting en gaat mijn app automatisch grotere tussentijden kiezen tot de boel weer op de normaal draait.
Zo help je elkaar een beetje, ik heb er als app ontwikkelaar immers ook niets aan als de bron door overbelasting down gaat. Dus dan ff de eerlijk delen modus aan: ff pas op de plaats totdat er weer meer capaciteit is.

Nu is het lastiger met AWS als bron server natuurlijk dat het "oneindig"-schaalt, zelfs bij duizenden concurrent gaat de boel niet langzamer worden. Maar ze betalen gelukkig dan ook per request i.p.v. per beschikbare capaciteit.
Maar goed 17.500 requests per dag per gebruiker is wel veel ineens denk ik.

[Reactie gewijzigd door djwice op 22 juli 2024 15:44]

[zenlord]

Wat ik me in dit soort gevallen dan afvraag, waarom gaat de developer van zo'n plugin niet eerst in gesprek, dan heel zo'n dansje niet nodig omdat die dan vooraf kennis heeft gegeven van wat zijn bedoelingen zijn en eventuele vragen, bijvoorbeeld over het aantal API Calls, kan stellen voor ontwikkeling van de plugin (of general release van de plugin, als je toch eerst een PoC wil maken.

Allemaal mooi en wel, maar:
1. Je weet niet of Andre0512 dit niet heeft gedaan - wie weet heeft Haier in het verleden niet willen antwoorden op zijn vragen
2. Je vergeet dat dit vaak hobby-projecten zijn - ik kan mij inbeelden dat als je een beetje handig bent met python, dat je dan misschien wel veel sneller dan verwacht tot een POC komt dan dat je zou komen met support requests uit te sturen.

[FvdM]

Ik heb de officiële Haier hOn app even door mijn decrypt proxy gehaald en wat mij opvalt is dat de API geen X-RateLimit-* response headers teruggeeft. Een script kan die informatie gebruiken om de API calls te plannen binnen het gewenste beleid. Als ze rate limiting echt belangrijk zouden vinden dan hadden ze daar al moeten beginnen.

[bilgy_no1]

Kennelijk leest Haier mee op Tweakers en volgen ze mijn advies ook bijna letterlijk op:

bilgy_no1 in 'Haier stuurt takedownverzoek aan Home Assistant-plug-inontwikkelaar'

"Haier kan het ook omkeren: wow, wat fantastisch dat mensen in hun vrije tijd een oplossing maken die onze klanten nog blijer maken. En dan in plaats van een take-down verzoek sturen, een mailtje met het voorstel om verder samen te werken en er een nog betere oplossing van te maken."

Ik zal ze een factuurtje sturen...

[jayjay_seal]

Kan Dedietrich ook meelezen AUB

Zei hebben het afgelopen jaar, de hele API op de schop gegooid en zijn opnieuw begonnen zonder dat er externe API calls mogelijk zijn.

[zenlord]

Ze trekken nu gewoon de keutel in omdat er ze er nu achter komen dat dit toch net een iets te groot PR-probleem aan het worden was.

Daar heeft het alle schijn van weg: Andre0512 's repo op Github is intussen ~2100 keer geforked.

[BeosBeing]

Daar heeft het alle schijn van weg: Andre0512 's repo op Github is intussen ~2100 keer geforked.

Het zou kunnen zijn dat dat ~2100 gebruikers zijn die met HomeAssistant (of HA-development) bezig zijn.
Nu nog forken naar GitLab, Git, Gitea, SourceForge, Launchpad, Ourproject.org, ...(en dan met name de varianten die het toestaan een eigen server te draaien, die kun je ook ofline onderhouden en updaten via Sneakernet.

[laurens0619]

Ik vind dit heel dubbel.
Iedere 5 sec een status update opvragen is voor een witgoed apparaat vrij lomp
Het is 2024, ik had gehoopt dat het aantal poll mechanismes afgenomen zou zijn en zaken nu event based zouden zijn.

Zoiets hierboven genoemd is een callback url al een goede maar dat is wat lastig te gebruiken vanuit thuis/achter nat.

Alternatief is een streaming api. Dan wordt een connectie opengezet en krijg je direct data als er iets nieuws is. Actuelere, minder load voor de leverancier etc.

Dus ja beetje beide schuld. Iedere 5 sec is lomp maar de API leveranciers zouden ook wel wat modernere API methodes mogen aanbieden dan dit.
Als dat te complex is, gooi er als Haier een rate limiter op of slimme caching laag op die je laat invalidaten na x minuten. Is de load van je API infra iig een stuk lager

[Reactie gewijzigd door laurens0619 op 22 juli 2024 15:44]

[GeroldM]

Speel eens met de NTFY software. Er is een betaalde en open-source variant van te krijgen en kan op zoveel verschillende manieren notificaties genereren almede verwerken. dat zou de fabrikant met gemak kunnen laten draaien in het product en dan krijgen zij per event een notificatie, i.p.v. te moeten 'pollen' of iets dergelijks.

Scheelt enorm in het aantal API calls en het betreft meteen dat die van belang is voor de fabrikant.

Een maat van me heeft een antiekwinkel en daar kwam een luie ligstoel binnen, waarvan de massage onderdelen niet meer werkten, dus was het erg goedkoop. Daarna is hij gaan "spelen" met een ESP32, heeft wat onderdelen/electronica vervangen en nu werkt de stoel beter als vanouds, en kan hij of zijn vrouw de stoel bedienen via Home-Assistant en/of via zijn/haar telefoon. Heeft hem een ruime middag gekost (en heel wat pluspunten bij moeders de vrouw opgelevert).

Wat ik aan wil geven is dat je handig genoeg bent, je niet zo heel veel rekening hoeft te houden met de wensen en/of garantie-voorwaarden van de fabrikant van je produkt. Als zij het niet doen, dan bouw je zelf wel een systeem dat je aan je Home-Assistant (of CasaOS) koppelt en kunt genieten van een geautomatiseerd huis/produkt zonder dat daar de cloud (van de fabrikant) aan te pas hoeft te komen.

Het gaat tenslotte om verkoop van een produkt. Als ik het koop, dan is het van mij en heeft de fabrikant er geen bal meer mee te maken. Nou leef ik in Zuid-Amerika, waar er zowiezo een cultuur heerst van repareren, gebruik makend van onderdelen van de fabrikant. En als dat niet mogelijk is, dan onderdelen van een soortgelijk ander produkt, wat dan wordt aangepast naar het benodigde formaat/afmetingen/enz.

Niet ideaal, en je moet moeite doen om een goede "fabrikator" te vinden. Een voorbeeld: op het eind zaten er meer Toyota onderdelen in mijn Skoda dan originele onderdelen. Voor een goede prijs verkocht om een grotere auto aan te kunnen schaffen waar mijn destijds vriendin en haar kroost in pasten.

Slechtste beslissing ooit. Die grotere auto ligt op de sloop, de vriendin werd mijn vrouw en mijn ex. En de Skoda? Die puft nog altijd door.

Sorry voor het afdwalen.

[Sebazzz]

Als de airco’s Matter ondersteunen, dan moeten ze dus lokaal te besturen zijn, niet?

[Aardedraadje]

Ok, een positieve draai aan het verhaal en ik verwachte al zoiets na de reactie van de US-tak.

Lokale API is de oplossing voor iedereen, lijkt me.

[Reactie gewijzigd door Aardedraadje op 22 juli 2024 15:44]

[langestefan]

Ook de beste oplossing voor iedereen. Maar wellicht wilt haier de toegang tot data van gebruikers niet verliezen.

[mutsje]

Goed van deze fabrikant dat ze in gesprek met de ontwikkelaar gaan, kunnen leuke zaken uitkomen denk ik. Wou dat Daikin hun closed api ook weer open source zouden maken. Je moet nu via hun wolkje alles regelen.

[CyBeRSPiN]

Heel goed, en mooi om te zien dat de Home Assistant community serieus wordt genomen. Blijkbaar zoveel stennis geschopt dat ze zich snel realiseerden dat ze iets moesten doen

[NeFoRcE]

Mooi dit. Nu Daikin nog. Heb thuis een airco die direct koppelde met HA. M'n schoonouders hebben 2 toplijn producten van Daikin laten installeren, maar kreeg ze niet gekoppeld. Wat blijkt? Die toplijn producten werken niet lokaal, alleen via de cloud. En dat is closed. Mooi hoor. A merk producten en dan geen lokale bediening...

[GORby]

Hm, welke lijn is dat dan?
Zowel de Stylish (design model) als de Ururu Sarara (top rendement) kunnen lokaal uitgelezen en aangestuurd worden. De Perfera's bijvoorbeeld niet (vanaf modeljaar 2020 of zo).

[NeFoRcE]

Zeker weten? M'n schoonouders hebben de perfera voor wat ik weet. Dus dat zou dan kloppen. Volgens de doc van HA; https://www.home-assistant.io/integrations/daikin/ gaat het om de module BRP069C4x. Maar voor wat ik wist zat dit ook in de ururu en de stylisch, maar dat is dus niet zo?

[GORby]

Ik weet niet zeker welke module er in de Stylish zit, maar ik lees die gewoon uit via HTTP requests op het lokale IP. De Ururu Sarara heeft standaard geen WiFi aan boord, en moet daarvoor een extra module hebben. Die werkt ook lokaal. Beide types hangen hier ook aan Onecta trouwens, aangezien we ook wat Perfera's hebben hangen, die niet lokaal te benaderen zijn.

Je kan naar het schijnt ook op de Perfera zo'n extra module aansluiten, waardoor die wel lokaal aan te spreken zijn, maar dat heb ik hier niet gedaan, aangezien de cloud integratie met Home Assistant ook gewoon doet wat het moet doen.

[Sepio]

Ik vermoed dat het elke 5 seconden aanroepen van de Haier webservice de controle van de actuele status betreft. Zouden ze in plaats van het pollen niet beter een Callback URL kunnen gebruiken. Dat is gewoon onderdeel van de OpenApi 3.0 standaard.

De home assistent plug-in geeft dan een adres door die Haier kan aanroepen als er de status veranderd.
Daarnaast zal de home assistant plug-in dan alleen nog de status aanpassingen op aanvraag van de eindgebruiker moeten doorsturen.

[Vorlon]

Hoe werkt dat achter een NAT? Dan moet je je HA-instance openzetten voor de cloud van Haier? Of houd je standaard die verbinding actief?
Met een lokale API is dit idd wel netter, maar ga je bij een pollrate van 5sec er ook niks van merken.

[Sepio]

In het geval van Home Assistant Cloud of de Duck DNS variant lijkt me dat eenvoudig. In de andere gevallen wordt het lastiger en ontkom je er volgens mij niet aan een poort open te zetten.

[laurens0619]

Dat of gebruik maken van Streaming/Websocket API. Dat werkt ook prima achter NAT en is prima kanaal om notificaties/status update te ontvangen.

Ik kan alleen niets terugvinden in de OpenAPI 3.0 standaard mbt streaming API's/websocket.