Haier stuurt takedownverzoek aan Home Assistant-plug-inontwikkelaar

Haier heeft een takedownverzoek gestuurd naar een ontwikkelaar die plug-ins voor Home Assistant op GitHub had gezet. De ontwikkelaar maakte plug-ins waarmee gebruikers apparaten als airconditioners, ovens en stofzuigers lokaal konden aansturen via het smarthomeplatform.

Ontwikkelaar Andre0512 schrijft op zijn GitHub-pagina dat hij twee populaire integraties moet verwijderen. Het gaat om Haier hOn en pyhOn, die via de Home Assistant Community Store of HACS moeten worden geïnstalleerd. Smarthomeplatform Home Assistant bevat enkele 'officiële' plug-ins die door Home Assistant zijn ontwikkeld of gevalideerd, maar veel diensten moeten worden geïntegreerd via HACS. Andre0512 bouwde de twee plug-ins op basis van de hOn-app van Haier, waarmee het mogelijk is verschillende witgoedapparaten van het bedrijf aan te sturen.

In het takedownverzoek schrijft Haier dat de twee integraties in strijd zijn met de algemene voorwaarden van die van het bedrijf. De plug-ins 'gebruiken onze diensten op een ongeautoriseerde manier die significante economische schade aan ons bedrijf toebrengt', schrijft Haier.

Andre0512 zegt dat hij de tools in de komende dagen offline wil halen, maar het is maar de vraag of dat in de praktijk zin heeft. De plug-ins waren open source beschikbaar onder een MIT-licentie. Inmiddels zijn er al 73 forks gemaakt, een enorme toename van de enkele tientallen forks die de plug-ins eerst hadden.

Haier Home Assistant takedownverzoek

Door Tijs Hofmans

Nieuwscoördinator

19-01-2024 • 09:15

238

Submitter: vlijmen

Reacties (238)

238
237
123
7
0
101
Wijzig sortering
Zou het geen idee zijn dat Tweakers in de Pricewatch zoekcriteria opneemt, waarmee we eenvoudig kunnen filteren op "volledige controle zonder cloud"?
Je kan op de Home Assistant Integration pagina kijken (Als die er is voor dat apparaat / Merk) https://www.home-assistant.io/integrations/ . Daar staat rechtsboven de integration 'class' o.a: 'local', 'cloud-push' en 'cloud-polling'. https://www.home-assistan...et-of-things/#classifiers

Staat dan idd niet direct in de pricewatch maar mocht je de info willen zou je het daar vandaan kunnen halen.
@!GN!T!ON Dank, dat is inderdaad de plek waar ik het nu vandaan haal. Maar ik ben me bewust van dit gegeven en doe eerst die moeite. Ik denk dat het meerwaarde voor de Pricewatch zou hebben als dit erbij zou staan, zeker voor de Tweakers die er in eerste instantie niet bij stilstaan.

En wellicht is het ook een trigger voor fabrikanten om nog eens goed na te denken waar ze willen staan met hun product.
Ik filter nu op "privacy --> online account vereist" dat komt aardig in de buurt
Zou het geen idee zijn dat Tweakers in de Pricewatch zoekcriteria opneemt, waarmee we eenvoudig kunnen filteren op "volledige controle zonder cloud"?
Het idee dat je op een of andere manier de "goede van de slechte" wilt kunnen onderscheiden is een goede. Maar sommige dingen (zoals Airco's en ventilatiesystemen) zitten helaas niet in de pricewatch.
En daarnaast dit soort evil merken niet meer opnemen. Gewoon boycotten die handel. Bedrijven die menen je de toegang tot je eigen apparatuur te mogen ontnemen mogen wat mij betreft gewoon inpakken.
Het nadeel van veel chinese merken, ze willen controle blijven houden over jouw spullen en jouw data.
Gewoon laten staan op GH.
Laat maar tot een - bv gecrowdfunde - rechtzaak komen met als onderwerp “de consument het recht ontnemen om met gekochte apparaten te doen wat je wil.”
Ik ben een van de mensen die dit item heeft gesubmit want ik ben ook getroffen hierdoor.
Dat het geen officiele plugin is daar was ik mij van bewust, maar ik kocht specifiek de droger die ik nu heb ( 3 maanden geleden) zodat ik via HA hem aan kan zetten als er meer opwek is via de zonnepanelen.

Die app van hun is dramatisch en totaal niet SMART dus daar heb ik helemaal niks aan, dan kan ik hem ook wel vertraagd starten als ik de was er in stop, en dat is nu net niet de bedoeling.

Wat ik vooral jammer vind is dat ze totaal niet de voordelen inzien van deze plugin en het gratis werk dat de developer voor ze doet. Als ik bijvoorbeeld kijk naar Renson (ventilatie) zij geven juist actieve support aan de developer van de niet officiele plugin om alles werkende te hebben. Dat is hoe het zou moeten zijn. Prima dat ze er zelf geen resources voor vrij maken, maar help je klanten zoals zij het willen. De kosten van de API zullen vast wel meevallen, en anders inderdaad lokale toegang geven dan kost het ze niks meer.

Normaal kies ik juist zoveel mogelijk voor lokale toegang, maar helaas kon ik geen geschikte droger vinden met lokale toegang. Dus buiten mijn droger en de oven (die ik nooit smart gebruik) is hier alles lokaal.

Edit: Overigens wel jammer dat Tweakers niet geprobeerd heeft een reactie te krijgen van Haier om de wat en waarom. Dit heb ik zelf geprobeerd maar dat valt als individu helaas niet mee.

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

Even een praktische vraag: Is het een combi van wasmachine en droger?
Als het alleen een droger is, dan kan je de droogbeurt niet lang laten wachten want dan stinkt het binnen no-time.

Ik heb toevallig een (domme) wasmachine van Haier, en die kan ik de stroomonderbreker en later weer verder gaan. Daar maak ik geen gebruik van overigens.
Het is enkel een droger, maar de was laat ik meestal de nacht draaien zodat hij de ochtend klaar is. En dan de droger in met maximale start tijd ergens in de middag. Dan gaat het echt niet stinken hoor, maar een hele dag is niet aan te raden inderdaad.
In het takedownverzoek schrijft Haier dat de twee integraties in strijd zijn met de algemene voorwaarden van die van het bedrijf. De plug-ins 'gebruiken onze diensten op een ongeautoriseerde manier die significante economische schade aan ons bedrijf toedoet', schrijft Haier.
Algemene voorwaarden hebben geen invloed op losstaande opensource code zelf. Immers bestaat de opensource code los van het product/de dienst, en hoeft iemand die code inziet en verspreidt nooit ergens algemene voorwaarden geaccepteerd te hebben van een product dat die niet gebruikt. Er zijn voldoende legitieme redenen om code te distribueren (bijvoorbeeld onderzoeksdoeleinden, educatief, etc.).

Gebruik van de opensource code kan wel tegen algemene voorwaarden ingaan, maar dat doet de gebruiker, niet de ontwikkelaar. Overigens betwijfel ik dit. Als een apparaat lokaal aangestuurd kan worden, dan hoeft de gebruiker nooit algemene voorwaarden van een 'app' of dienst geaccepteerd te hebben.

Al wil je de code veilig stellen voordat deze wordt verwijderd, fork het op GitHub of draai even:

git clone https://github.com/Andre0512/hon.git

En weer door.

[Reactie gewijzigd door The Zep Man op 22 juli 2024 15:44]

Immers bestaat de opensource code los van het product/de dienst
Is dat uiteindelijk ook zo? Het project maakt namelijk gebruik van de servers van Haier, aangezien de connectie niet lokaal verloopt, maar via hun API. Waarbij wellicht de plugin meer/onnodige requests maakt, in vergelijking met hun eigen App, waarbij ze zelf controle hebben over hoe de requests lopen.
maar dat doet de gebruiker, niet de ontwikkelaar
Maar heeft de ontwikkelaar dan geen aandeel hier in? Aangezien hij iets biedt waarmee je 'misbruik' kan maken van een API? (Lees: het gebruiken zoals niet bedoeld)
Als een apparaat lokaal aangestuurd kan worden,
Dat is dus niet het geval, het gaat niet lokaal.
https://github.com/Andre0...n/pyhon/connection/api.py
Dit is de crux van het verhaal. De integratie gebruikt de servers van Haier om verbinding te leggen met de apparaten en gaat dus helemaal niet lokaal zoals het artikel doet vermoeden. Haier betaalt voor die servers en ongeacht of het meer of minder requests oplevert is dat niet waarvoor Haier die servers heeft opgetuigd.

Het zou Haier sieren als ze lokale toegang geven tot hun apparaten. Al dan niet door met hun app deze functionaliteit te ontgrendelen zodat dit niet standaard voor iedereen aanstaat.
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.
Sommige bedrijven moeten dit nog leren. Haier is er daar blijkbaar een van.
Haier betaalt voor die servers en ongeacht of het meer of minder requests oplevert is dat niet waarvoor Haier die servers heeft opgetuigd.
Haier heeft natuurlijk producten verkocht met de belofte dat de producten geconnecteerd zouden zijn, en dus gebruiken de eigenaars van die producten nog steeds dezelfde API, zij het via een andere "ingang". Ik weet niet of je kan stellen dat je dan significant economisch nadeel lijdt, tenzij je natuurlijk met de closed source app geld verdient (bvb door profiling van de gebruikers).
Zouden er ook gebruikers zijn die hebben gevraagd "werkt het met Home Assistant?" en daar "ja" op gekregen hebben door verkopers die refereren aan deze plugin?
Ik denk eerder dat het zo verloopt, dat iemand die home assistent heeft en een nieuw apparaat zoekt, bij haier kan uitkomen. En nu dus met een apparaat zit waar hij niet mee kan automatiseren zoals hij dat wil.

Ze hebben vooral zichzelf ermee, in mijn ogen. Ik koop bijvoorbeeld wel een sonos omdat ik die makkelijk met homey kan besturen, en geen homepod. Ondanks dat ik voor de rest vrijwel alleen Apple heb staan hier.
Precies dat. Voor mij was het uiteindelijk een (van de) belangrijke redenen om na mijn verhuizing een wasmachine en droger van Haier te kopen. De eigen Hon-app van Haier zuigt grote tijd en de HA-plugin werkt heel prima.
Haier schiet zichzelf hiermee flink in de eigen voet. En ze begrijpen duidelijk helemaal niets van Open Source en hoe ze juist zouden kunnen samenwerken met een actieve en blije community. Zonde.
Waarschijnlijk wordt hun API onevenredig bestookt met aanvragen vanuit de HA-plugin, en hebben hun eigen apps daar ook last van doordat de API trager wordt.
Maar los dat dan op door een goede ondersteuning in te bouwen, met een webhook-URL die ingesteld kan worden vanuit de HA-plugin. Iedereen blij!
Het nadeel zit hem er waarschijnlijk in dat de gemiddelde gebruiker maar een beperkt aantal requests doet via de mobiele app en dat daar de server sizing op berekend is. Een HomeAssistant plugin doet waarschijnlijk om de aantal minuten wat checks om te zien of er iets is gewijzigd.

Mijn airco integratie met LG checkt meerdere keren per uur de temperatuur van de ruimte, ook wanneer de airco niet in gebruik is. Een mobiele app zal dat waarschijnlijk niet op de achtergrond doen.

Zo kom je als snel op situaties waar 1% van je gebruikers (die een HA plugin gebruik) zo 90% van je requests veroorzaken. Het zou ze echter wel sieren als ze dan gewoon een rate limiter gebruiken en daarmee HA beperken. Een goede ontwikkelaar zal zich daar waarschijnlijk netjes aan houden.
Ik vraag me af of Home Assistant wel genoeg installaties heeft om een significante impact te hebben op een normale backend, eigenlijk. Ik geloof zeker dat de load hoog is, maar xd install base zal toch niet zo dramatisch laag zijn dat alleen de nerds van het hoogste kaliber hun API gebruiken?

Ik denk meer dat dit een verantwoordelijkheidsprobleem of machtsprobleem is. Ze hebben geen interesse om zelf voor HASS de boel te gaan onderhouden maar ze hebben ook geen zin in problemen als ze hun API aanpassen en honderden gebruikers ineens boos worden op hun.

Een accountgebaseerde ratelimit, bepaald door normaal gebruik van de app, zou dit hele probleem voorkomen. Een lokale API (die je eventueel via de cloud op je account zou moeten activeren) zou natuurlijk ook werken, al moet je je afvragen of zo'n IoT-bedrijf te vertrouwen is natuurlijk; het zal niet de eerste keer zijn dat mensen hun wasmachine per ongeluk aan een botnet hangen.
Ik vraag me af of Home Assistant wel genoeg installaties heeft om een significante impact te hebben op een normale backend, eigenlijk.
Er zijn op dit moment ongeveer 315.000 active installaties, en laat een stevige groei zien.

Met het richting van een minder nerd gehalte dat HA als doel heeft gesteld, hebben ze daar denk ik een gigantische sprong voorwaarts mee gedaan.
Dat zijn home assistant installaties en dus lang niet alle gebruiken deze plugin. Dat aantal zal echt veel lager liggen.
Klopt. Zelfs van Hue zijn er maar 40k. Homekit - als je daarmee AC zou controleren - 47k.
MELcloud wat vergelijkbaar is voor Mitsubishi: 2847

Ik gok dat er maar een aantal duizenden gebruikers zijn.
315.000 is veel, maar ik weet niet of dat ook veel is in een bedrijf met een omzet van 3 miljard. Haier is natuurlijk enorm.

Dat niet-technische heeft zo zijn beperkingen, zo zit deze functionaliteit bijvoorbeeld in HACS, wat toch weer een aantal stappen complexer is dan Home Assistant opzetten. Ook is het maar de vraag of die 315.000 mensen allemaal Haier-cloudspul hebben, natuurlijk; ik kan me voorstellen dat mensen met een voorliefde voor automatisering toch liever een merk zouden kiezen met lokale API's.
Het staat Haier natuurlijk vrij om even een DM naar de developer te sturen met verzoek om de requests te beperken in plaats van een dreigbrief over de schutting te gooien.
Ze kunnen de api vrij eenvoudig rate-limiten, dan krijg je een time-out error wanneer je te snel achtereen, of te vaak per tijdseenheid een request doet.
Het nadeel zit hem er waarschijnlijk in dat de gemiddelde gebruiker maar een beperkt aantal requests doet via de mobiele app en dat daar de server sizing op berekend is. Een HomeAssistant plugin doet waarschijnlijk om de aantal minuten wat checks om te zien of er iets is gewijzigd.
De HA plugin kan gewoon met hetzelfde interval pollen als de apps, en deze kan zich natuurlijk precies zo gedragen dat deze ononderscheidbaar is. Dus dat is niet een heel sterk argument, zeker als je niet weet of dit het geval is of niet. Maar eigenlijk had het gewoon een push-setup moeten zijn natuurlijk. Dat is in dat opzicht een beetje hun eigen schuld als dit een issue zou zijn.
Hadden we daar niet de http-429 voor, om op een nette manier de gebruiker te vertellen dat ie minder requests moet doen?
Dat ligt puur aan de implementatie van de plugin, die van Toshiba werkt met Azure IoT en websockets dus veranderingen worden gepusht.
Misschien heeft Haier hun cloud-omgeving zodanig opgezet dat zij per API-call af moeten rekenen. Dan wil je als fabrikant daar toch paal en perk aan stellen, voordat er een enorme rekening bij hun op de mat valt.

Met hun eigen app kan men aan profilering en andere zaken doen, waaraan het bedrijf waarde hecht. Meer dan de kosten. Zoals @Remz al correct aangaf: het is aannemelijk dat de app een stuk zuiniger is met API-calls dan dat de plug-ins zijn. En als de plug-ins op zich wel zuinig zijn, dan kan de HA-gebruiker een configuratie gebruiken welke alsnog voor heel veel (onnodige) API-calls zorgen.
Misschien heeft Haier hun cloud-omgeving zodanig opgezet dat zij per API-call af moeten rekenen. Dan wil je als fabrikant daar toch paal en perk aan stellen, voordat er een enorme rekening bij hun op de mat valt.
Dat is dan de fout van Haier. Het had evengoed een troll kunnen zijn die een cluster cheapo VMs opzet bij een cloud boer en vrolijk miljoenen requests gaat sturen.
Rate limits zijn niet bepaald een nieuw concept.
Haier belooft van alles, maar ondertussen harvesten ze bakken met userdata via de haier app die ze gebruikers dwingen te gebruiken en verkopen die data aan de hoogste bieder. Het is gewoon een smerig verdienmodel van een smerig bedrijf wat schijt heeft aan hun klanten zoals we al zo vaak gezien hebben.
Uiteindelijk zijn er genoeg alternatieven manieren om samen tot een goede oplossing te komen. En natuurlijk hoeft het niet, het is aan Haier om gewoon botweg een takedown te sturen echter wat er nu gebeurd zou Haier zelf toch ook niet moeten verrassen. Vervolgens doen ze het toch, je mag je dan toch wel afvragen zijn ze nou gewoon zo lomp bij Haier of is hier meer gaande.

Haier zou veel verder komen door samen met de ontwikkelaar een gesprek aan te gaan, wat deze plugin precies doet, werkt deze zoals Haier voor ogen heeft of misschien maakt die inderdaad veel requests. Haier kan ook leren van deze plugin, wat doet die goed en wellicht zou later Haier zelf een nette release kunnen doen.

Maar door zo de deur dicht te gooien heb ik totaal geen respect voor een bedrijf. Persoonlijk heb ik met hun veel van doen zakelijk en eigenlijk verbaast me hun reactie helemaal niet. Hun customer service voor groot formaat klanten (in China of all places) is namelijk net zo waardeloos.
En dat mijns inziens precies het probleem met smart home producten die alleen te benaderen zijn via de servers van de fabrikant. Het maakt niet uit hoe amicaal de fabrikant is tegenover "tweakers" op een gegeven moment kunnen ze de deur gewoon dicht doen (of nooit open zetten).

Ik hoop dan ook dat Matter hier verbetering in aan kan brengen. Het is nog zeker niet perfect, maar als het toch doorkomt op witgoed dan heb je wel meteen een standaard manier van lokale controle op jouw apparaat.
matter of welk ander protocol dan ook zou voor smart(home) producten gewoon verplicht moeten zijn

lokale besturing mag nooit een incompleet of niet werkend product opleveren

denk voor een

wasmachine
start stop en programma keuze
voor een magnetron
start stop vermogen
voor een tv
aan uit zender keuze volume
voor een lamp
aan uit helderheid

etc

natuurlijk mag je extra slimme opties via een cloud aanbieden maar niet de basisfuncties
(Ik heb niet naar de broncode van de HAss plugin gekeken, dus neem deze comment met een korreltje zout)

Normaal gesproken zou een dergelijke plugin vergelijkbaar moeten werken met de applicatie van wie het de API access gebruikt. Als de implementatie op een bepaalde manier foutief is (i.e. onbedoelde DoS of iets dergelijks), zou het een constructievere oplossing zijn om een publieke API op te stellen of om de ontwikkelaar te voorzien van informatie waarmee de implementatie verbetert.

Het zou wat anders zijn als er bijvoorbeeld paywalled features in zouden zitten die worden omzeild door API gebruik. Losstaand van het feit dat er autorisatieproblemen aan de kant van Haier zouden zitten, hebben ze wel meer grondslag om acties zoals Cease and Desist of Copyright Takedown notices te doen.

Uiteindelijk zal het gebruik van de service toch hetzelfde zijn met of zonder app...
Een API publiekelijk beschikbaar maken en documenten en onderhouden (toegegeven, wat je voor je interne teams of externe app-bouwers ook zou moeten doen) kost extra moeite en daarmee geld, tegen geen directe winst. Geen aandeelhouder gaat daarmee akkoord.
Wel indirecte winst. Ik ga er vanuit dat er tweakers zijn die speciaal voor de producten van Haier kiezen omdat ze via HA kunnen beheerd worden.
Duidelijk, maar er blijkt dus wel interesse te zijn vanuit de userbase om het met de niet publiek gedocumenteerde API te doen. Wat is dan de block om dit niet toe te laten en, indien er problemen zijn, te communiceren met de desbetreffende ontwikkelaars?
Dat is dan pech voor de Hayer aandeelhouders, want het eerste wat ik check vooraleer een geconnecteerd apparaat te kopen, is integratiemogelijkheid met domotica, in mijn geval met HA dus.
Als een bepaald merk dat niet kan, en een ander merk wel, zal ik het toestel kopen waarbij die integratie wel mogelijk is.

Ik stel voor dat HA gebruikers een bericht sturen naar Hayer, om hen te laten weten dat deze integratie mogelijkheid een voorwaarde voor aankoop van hun produkten is.
"There are dozens of us. Dozens!"
Klopt, waarom fabrikanten die server optuigen, is om er een extra verdienmodel op te kunnen plakken op een manier die momenteel verrassend maatschappelijk geaccepteerd lijkt. Want laten we wel wezen: dat je via China (o.i.d.) moet om vanuit je eigen huis je eigen koelkast te benaderen, is technisch natuurlijk absurd.

Dus ja, een oplossing die bijv. ervoor zorgt dat de ads in je app minder bekeken worden, levert economische schade. Maar zouden we als EU onderhand niet 'ns flinke beperkingen op moeten gaan leggen over wat terms of service mogen bepalen over de interactie met aangeschafte, fysieke apparatuur?
Het is natuurlijk ook om de gebruiker te ontlasten. Immers welke variant van lokale werking zie je ontstaan die je zonder gehannes met domeinen, ssl-certificaten, ook buitenshuis kan gebruiken. Ik heb zelf sonoff-stekkers meteen geflasht met Tasmota voor lokale bediening in HA, maar heb ze bewust voor leken om mij heen origineel gehouden, omdat je ze anders niet buitenshuis kan schakelen zonder dat je een heel systeem eromheen optuigt. Wellicht dat het met de komst van IPV6 straks makkelijker wordt, als elk random binnenshuis apparaat van buiten benaderbaar wordt, maar voor nu zie ik nog geen eenvoudige manier voor de leek.
Het project maakt namelijk gebruik van de servers van Haier
Dat is niet juist in mijn ogen.
Het project gebruikt de servers niet, dat doen de mensen die het project als plugin in gebruik nemen.
Als het gaat over "violation of terms of service" zal het bedrijf moeten aankloppen bij de gebruikers van de plugin.
De daadwerkelijke mensen die "illegaal" de API gebruiken, en dat doen terwijl ze wel de terms-of-sevice eerder al hebben geaccepteerd bij de installatie van hun product.

Als het gaat over illegaal gekopieerde code, etc, dan kunnen ze mogelijk wel bij het project aankloppen.

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

Het is natuurlijk veel makkelijker om de middle man (de pluginbouwer) aan te pakken dan alle individuele gebruikers daarvan.
Maar dan faciliteer je als ontwikkelaar misbruik wat toch ook niet zou moeten kunnen?
Maar dan zou je als bouwmarkt fietsdiefstal faciliteren door slijptollen te verkopen?
Torrent sites worden ook offline gehaald omdat ze illegaal gebruik faciliteren ondanks dat ze het zelf niet hosten.
Heel zwart/wit bekeken heb je misschien gelijk dat de gebruikers de Haier servers belasten, maar ik denkdat de programmeur niet vrij pleit omdat enerzijds de meeste gebruikers dat niet weten en ze niet worden gewaarschuwd en anderzijds de ontwikkelaar van de plugin dat wel faciliteert.
Is dat uiteindelijk ook zo? Het project maakt namelijk gebruik van de servers van Haier,
Het project bestaat uit opensource code. Die staat enkel op GitHub.
Is dat uiteindelijk ook zo? Het project maakt namelijk gebruik van de servers van Haier, aangezien de connectie niet lokaal verloopt, maar via hun API.
Ja, zie bijvoorbeeld het bestaan van youtube-dl. Dat is zelfs offline geprobeerd te halen met een DMCA request naar Github zelf, in plaats van in essentie een vriendelijk verzoek aan de developer zoals hier.
Lijkt me alsnog een kwestie van: Haier moet dit server-side gaan oplossen. Blijkbaar zijn hun servers open genoeg voor niet-toegestane benadering.
Zeker omdat de broncode van dit project al op straat ligt, maar ook omdat dat dus blijkbaar gewoon kan, gaat depublicatie van de originele repo niks uithalen.
Het doet mij heel erg denken aan het hele Beeper/iMessage-verhaal, en ook daar is het een kat-en-muisspel waarbij de ene partij een niet-detecteerbare benadering probeert te maken en de andere partij de boel probeert te detecteren en weigeren. Voor zover ik weet wordt daar ook geen rechtzaak tegen Beeper over gevoerd door Apple?
De code maakt misschien gebruik van de servers van Haier, maar de ontwikkelaar is niet degene die de code draait en daardoor serverbelasting veroorzaakt. Dat doen de gebruikers. Ik begrijp dan ook niet hoe zoiets zou kunnen standhouden.

En dan nog. Haier heeft hier zelf de oplossing voor: maak de api van het apparaat lokaal toegankelijk, dan hebben we die prutsservers van ze helemaal niet nodig en hoeven die prutsers er ook geen geld in te steken.

Ik zeg het nog een keer (in het zonnepanelentopic werd ik afgefakkeld door Tweakers die het blijkbaar beter weten): Europa, VERPLICHT alle fabrikanten van alle apparatuur boven een bepaald vermogen om een lokaal toegankelijke open API in te bouwen.

Haier gaat hier op de zwarte lijst. Ik heb gelukkig niks van dit merk, en dat blijft ook zo. Weet iemand misschien of Haier een moedermaatschappij heeft of gelieerd is aan andere merken die onder hetzelfde kortzichtige management vallen? Dan gaan die ook op de zwarte lijst.
Is dat uiteindelijk ook zo? Het project maakt namelijk gebruik van de servers van Haier, aangezien de connectie niet lokaal verloopt, maar via hun API. Waarbij wellicht de plugin meer/onnodige requests maakt, in vergelijking met hun eigen App, waarbij ze zelf controle hebben over hoe de requests lopen.
Volgens mij hebben anderen het hier al gepost, maar het begint gewoon al met het feit dat een app op een smartphone of ander device altijd maar een beperkte tijd gebruikt wordt terwijl zo'n HomeAssistant-server 24/7 aan staat. Als een device dus de hele dag elke 5 seconden een request stuurt loopt dat aardig op.
Maar heeft de ontwikkelaar dan geen aandeel hier in?
Waarschijnlijk is die ontwikkelaar gebonden aan de beperkigen van de API en de hardware. Ik ga nu even speculeren, maar de het device geeft waarschijnlijk pas toegang na authenticatie via de AWS-server van Haier, wat gebeurt als je met de app verbind. Die authenticatie vervalt waarschijnlijk als de verbinding langer als 5 seconden weg is. Om het HomeAssistant-systeem verbinding te laten houden moet je dan dus wel iedere 5 seconden en call sturen.
Aangezien hij iets biedt waarmee je 'misbruik' kan maken van een API? (Lees: het gebruiken zoals niet bedoeld)
Misbruik is blijkbaar hier (en trouwens bij een heleboel online diensten) te vaak gebruiken.
Dat was dus exact het punt van mijn reactie :)
En dat dus het aanpakken van de ontwikkelaar een logische stap is, aangezien deze het beschikbaar maakt voor andere gebruikers.

En de suggestie van de reden is inmiddels ook al bevestigd;
nieuws: Haier trekt takedownverzoek aan plug-indeveloper in, geeft api-calls ...

En Haier EU zal de zelfde richting opgaan als de US.
https://twitter.com/haier...tatus/1748133624006799570
Waar lees jij iets over open source dan? De Haier app is vermoedelijk closed source. De ontwikkelaar van de HA integratie heeft dan het één en ander moeten reverse engineeren om de communicatie werkend te krijgen. Dat is de basis voor dit takedown request.
Dat de ontwikkelaar voor Haier naast een geclaimd nadeel ook een economisch voordeel oplevert met deze integratie hebben ze duidelijk nog niet begrepen. En dat deze takedown óók een economisch nadeel oplevert ook niet. Ik gok ook dat de route die Haier nu inslaat economisch slechter voor ze is dan als ze de integratie zouden laten bestaan (of zelfs faciliteren / eraan mee ontwikkelen).
In Nederland is reverse engineering om een dergelijke plugin te ontwikkelen volledig legaal. Ik weet niet hoe het in Duitsland (de auteur) zit. In de VS is het volgens mij legaal, maar tegen de gebruiksvoorwaarden in.
Ik weet niet hoe het in Duitsland (de auteur) zit.
IANAL. Van wat ik hier lees mag het:
Reverse engineering (i.e. deconstructing a third-party product to reveal its design or to extract other information from the product) is permitted, except when otherwise contractually agreed. A general freedom to reverse engineer did not exist in the past, and enterprises may want to include clauses against reverse engineering in agreements with third parties such as their suppliers, customers or R&D partners. However, reverse engineering will still be possible for third parties (i.e., competitors which are under no obligation to refrain from reverse engineering). This poses new threats to the secrecy of information. Hence, enterprises may want to adjust their strategies for the protection of proprietary information, seeking a new balance between protecting secrets and obtaining IP rights such as patents.
Een opensource project kan je zien als een concurrent omdat het een alternatief biedt, ook al heeft dat geen commercieel belang.

[Reactie gewijzigd door The Zep Man op 22 juli 2024 15:44]

Volgens mij zijn veel van dat soort dingen Europa-breed legaal. Zaken als VLC en FFmpeg komen uit Frankrijk en zouden in de VS waarschijnlijk niet kunnen omdat je sommige van de benodigde vrijheden daar niet hebt.
Het bedrijf geeft aan hier economische schade aan te ondervinden, dat kan wellicht uitmaken.

Stel bijvoorbeeld dat ze één of andere hypermoderne "cloud" API hebben die een euro kost per duizend calls en hun apps zo hebben gemaakt dat je twee of drie keer per dag een call stuurt (tenzij je je thermostaat toevallig vaker aanstuurt), maar Home Assistant nu die API iedere dertig seconden zit te pollen. Op dat moment stijgen de kosten natuurlijk enorm, tot op het punt dat je je moet afvragen of je geld moet gaan vragen voor de API, het hele ding moet herbouwen zodat dit uit kan, of het afschrikken via een gerechtelijke dreiging uit kan.

Ik durf niet met zekerheid te stellen dat het recht van reverse engineeren hier belangrijker wordt geacht dan de onredelijke cloudkosten die aan zo'n oplossing verbonden zijn.

Nu hebben we het ook nog eens over Duitsland (het land waar een bedrijf een rechtzaak heeft gewonnen tegen iemand die rapporteerde dat hun software een mysql-wachtwoord bevat waarmee iedere klant de gegevens van alle andere klanten kan inzien, gedeeltelijk vanwege de reverse engineering). Duits gerecht lijkt zich wel vaker achter bedrijven te scharen bij dit soort conflicten. Plus, zelfs dan gewonnen rechtzaak kost tijd en geld, natuurlijk.
Nu hebben we het ook nog eens over Duitsland (het land waar een bedrijf een rechtzaak heeft gewonnen tegen iemand die rapporteerde dat hun software een mysql-wachtwoord bevat waarmee iedere klant de gegevens van alle andere klanten kan inzien, gedeeltelijk vanwege de reverse engineering). Duits gerecht lijkt zich wel vaker achter bedrijven te scharen bij dit soort conflicten. Plus, zelfs dan gewonnen rechtzaak kost tijd en geld, natuurlijk.
Dit is appels en peren vergelijken. Allereerst is die persoon veroordeeld omdat hij de gevonden MySQL credentials had gebruikt om te verbinden met de database. Dat zou in Nederland waarschijnlijk ook verboden zijn. De Home Assistant ontwikkelaar gebruikt gewoon zijn eigen inloggegevens.
Het bedrijf geeft aan hier economische schade aan te ondervinden, dat kan wellicht uitmaken.

[...]

Ik durf niet met zekerheid te stellen dat het recht van reverse engineeren hier belangrijker wordt geacht dan de onredelijke cloudkosten die aan zo'n oplossing verbonden zijn.
Dan moet Haier haar dienstverlening beter beveiligen, zoals MyQ dat in de Verenigde Staten heeft gedaan. Dat Haier dan roept, zonder enige basis, dat ze economische schade ondervinden is nogal makkelijk. Want het tegenovergestelde kun je ook stellen, mensen kopen Haier apparatuur omdat het werkt met Home Assistant.

Het is conform Nederlandse, en naar wat ik lees ook Europese wetgeving, legaal om programma's te reverse engineeren voor interoperabiliteit. Ook om bijvoorbeeld bugs te fixen in software. Ik denk daarom ook dat dit vooral als blafbrief bedoeld is. Het is ook wachten wat Andre0512 gaat doen of dat iemand anders het stokje simpelweg overneemt.
Ja, die man gebruike inderdaad credentials die hij had gevonden, maar dat doet deze API toch ook? De API key die in de Python API zit gebakken is net zo goed een credential. Je username en wachtwoord zijn maar twee van de vier credentials die je bij de typische OAuth-flow gebruikt. Het verschil is dat Haier niet zo incompetent is als Modern Solution GmbH en niet iedereen toegang geeft tot alle data van alle klantencmet één credential.

De Duitse man heeft de rechtzaak verloren nadat hij is gaan kijken wat de oorzaak was van alle logmeldingen, dat lijkt mij toch ook logisch vooronderzoek voor bugs fixen? Hij zag een probleem, ging onderzoeken waardoor dat kwam, en maakte de fout de fabrikant op een datalek te wijzen.

Ik ben het niet eens met Haier, en ik ben blij dat de de al heeft aangegeven een rechtsbijstandverzekering te hebben en bereid is het gevecht aan te gaan, maar de principes achter de Europese wetgeving zie in de praktijk lang niet altijd terug in lagere rechtbanken. Wellicht dat de MySQL-zaak in hoger beroep gaat en de IT'er gelijk krijgt, maar dat is natuurlijk nog maar de vraag.

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

Waar lees jij iets over open source dan? De Haier app is vermoedelijk closed source.
De Haier app hoef je juist niet te gebruiken met deze opensource code.
De ontwikkelaar van de HA integratie heeft dan het één en ander moeten reverse engineeren om de communicatie werkend te krijgen. Dat is de basis voor dit takedown request.
Daarvoor zijn takedown verzoeken niet bedoeld. Verder is reverse-engineering voor bepaalde doeleinden (zoals onderzoek, maar ook ontwikkeling van opensource alternatieven) toegestaan binnen veel landen.

Wine is ook ontwikkeld d.m.v. reverse engineering van veel ongedocumenteerde Windows API calls. Het zou een mooie wereld zijn als Microsoft zegt dat dat tegen de algemene voorwaarden van Windows ingaat, en daarnaar handelt. :+

Mogelijk is dit niet toegestaan in de VS, gezien Blizzard v. BnetD. Wel zijn er veel verschillen tussen dit en dat. Als GitHub daarmee problemen heeft: overzetten naar (een eigen) GitLab (instance) buiten de VS en weer door.

[Reactie gewijzigd door The Zep Man op 22 juli 2024 15:44]

Wine is niet ontwikkelt d.m.v. reverse engineering, maar d.m.v. "Black Box Testing Reverse Engineering" om copyright claims te voorkomen. Zie o.a.: https://en.wikipedia.org/wiki/Wine_(software) voor meer informatie. Daarnaast maken ze gebruik van de publieke documentatie die Microsoft in hun library, welke functies omschrijven voor programmeurs.
Wine is niet ontwikkelt d.m.v. reverse engineering, maar d.m.v. "Black Box Testing Reverse Engineering" om copyright claims te voorkomen.
Black Box Testing Reverse Engineering = reverse engineering van Windows door Windows te gebruiken, wat nog steeds tegen de algemene voorwaarden van Windows in zou kunnen gaan. Waar ze op doelen met "Black Box Testing Reverse Engineering" is dat ze geen code van Windows inzien. Daardoor zou je risico kunnen hebben dat je het auteursrecht raakt, doordat je onbewust code overneemt. Let op dat de situatie met Haier niets te maken heeft met auteursrecht.

De vergelijking klopt nog steeds, ook al is de manier van reverse engineering mogelijk anders. Je kan namelijk in algemene voorwaarden iedere vorm van reverse engineering 'verbieden'.

[Reactie gewijzigd door The Zep Man op 22 juli 2024 15:44]

Wines gebruikt windows niet draait er los van, deze plugins werken samen met hun software. Is dus iets anders.
Sterker nog, zonder everse engineering hadden we de PC zoals die nu bestaat niet gekend. Er ontstonden clone's naast de IBM Personal Computer omdat slimmeriken het gesloten BIOS reverse engineerden en zelf een BIOS-chip maakten. De rest van de hardware waren gewoon openbaar te koop en dus kon men een IBM PC-clone in elkaar schroeven.
Op een zelfde manier is AMD groot geworden: eerst door chips van Fairchild etc te reverse engineeren en later de PC-chips van Intel. Daar zijn vele rechtszaken over gevoerd en AMD heeft ze zo goed als allemaal gewonnen. Ze gingen zelfs zo ver dat ze gewoon dezelfde nummering gebruikten, dus een Intel 80286 werd een Am286. Om die reden is Intel na de 496 overgestapt op de Pentium-merknaam, zodat ze die beter intellectueel konden beschermen.
Kortom, reverse engineering is van alle tijden en mag meestal gewoon. En een openbare API reverse engineren mag zeker, en ook zeker in de EU. De roep van Haier is dus ook vooral bluf, ze hebben juridisch geen poot om op te staan. Helaas kan het wel zo zijn dat de bluf werkt, simpelweg omdat een enkele developer niet het risico van gigantische claims wil lopen en niet de middelen heeft om die aan te vechten. Ik hoop dan ook dat een grotere organisatie, zoals de Free Software Foundation Europe, dit oppakt en hem ondersteunt.
Verrassend is dat Haier in de VS dit gebruik voor home assistant expliciet toestaat
https://x.com/HaierApplia.../1748133624006799570?s=20
De plug in is open source. Daar zal op gedoeld worden. Niet op de app van Haier zelf, die closed source zal zijn. En reverse engineering is niet altijd het open breken van een app en daar spullen uithalen. Plug ins kunnen ook prima ontwikkeld worden zonder een app van de fabrikant te gebruiken.
Bedrijven denken vaak alleen maar aan economische nadelen.
Ze hebben hun producten als closed enviroment ontwikkeld en daar een verdienmodel op gebaseerd. Dat verdienmodel wordt inderdaad onder druk gezet. De plugins maken een aansturing via Home assitent mogelijk en daarmee wordt de bediening van de apparaten via een andere manier mogelijk en Haier heeft daar geen controle over. Tegelijkertijd worden de producten juist door de toevoeging van Home assitent voor een grotere groep juist aantrekkelijk.
Als fabrikant moet je tegenwoordig eigenlijk blij zijn dat iemand een plugin voor Home assistent maakt, want dat kan de verkoop een flinke boost geven. Veel fabrikanten werken juist mee.
Forken op github zal niet heel veel nut hebben, als Haier een echte takedown naar github stuurt, worden ook alle forks (op github) gewiped. Als je wil forken, maak dan vooral een lokale fork/checkout... en upload die eventueel weer naar een (losse) github/gitlab/whatever. Maar forks via de 'fork' knop op github worden net zo snel gewiped als de originele versie.

Ik heb gisteren dit bericht ook op hackernews gepost, en natuurlijk meteen een mirror gemaakt van de 2 genoemde repos... Streisand effect in full swing ;)
Maar die firma kan nu iets aanpassen in hun code of hun server waardoor dit niet meer werkt.
En daarom zou ik zelf nooit gehoor hebben gegeven aan dit verzoek. Kom maar op met je gang naar de rechter, als ze uberhaupt al je NAW gegevens kunnen achterhalen.
Oliedom, Haier verkoopt enkel meer devices OMDAT er Home Assistant ondersteuning is.

Niemand zegt oh deze heeft HA support, die hoef ik niet.

Maar ze kunnen blijkbaar hun datahonger niet stillen vanwege een paar tweakers die buiten hun cloud om e.e.a aansturen.

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

Maar ze kunnen blijkbaar hun datahonger niet stillen vanwege een paar tweakers die buiten hun cloud om e.e.a aansturen.
En daarom zeg ik telkens als ik een nieuw apparaat koop en over een of andere gore cloud verbinding moet maken: "Die hoef ik niet." :P

Je kan best gelijk hebben dat voor velen Home Assistant ondersteuning een pluspunt is, maar er zijn nog steeds mensen die aan het hele IOT-ding niet mee willen doen.
Ik doe er aan mee als het geen negatieve effecten heeft, als de cloud verplicht is of je moet er extra voor betalen ben ik zeer zeker tegen. Maar als ik hierdoor kan zien of de was klaar is op mijn telefoon of de airco kan aanzetten heb ik er niks op tegen.

Probleem is als het verplicht is en het apparaat niet zonder werkt, dan heb je een potentieel stuk ewaste.
Yep, laatst had mijn zwager een nieuwe vaatwasser gekocht. Die deed het dus niet want dat ding moest eerst via een app en het internet geconfigureerd worden. Vervolgens zou hij het zonder internetverbinding ook niet doen, maar het bleek dat hij 'gewoon' een wifi verbinding moest hebben. Dus nu heeft hij netwerk zonder internet. Een vaatwasser... serieus.
voor de grap: stel de kuisvrouw 'eist' WiFi zodat ze Spotify kan gebruiken tijdens haar werk (o.a. de vaat wassen).
Dat is inmiddels al zo hoor! Huishoudelijke klusjes zijn een stuk dragelijker met een fijn (zelfgekozen) muziekje of filmpje erbij. Los van wie die klusjes doet natuurlijk ;)
Ik denk dat een betaalde cloud nog niet eens zo'n hele slechte oplossing is. Eén keer betalen en dan tien jaar de servers gebruiken is lastig te financieren voor dit soort bedrijven, een klein bedrag voor API-toegang geeft op zijn minst de illusie dat het spul uit kan.

Daar moet dan wel een minimumtermijn aan gekoppeld zijn ("neem een cloudabonnement en wij zorgen dat de API tien jaar werkt"), je als bedrijf Google-stijl de API en apps afsluit na twee jaar omdat het toch niet genoeg opleverde, kun je de boom in.

Dat er geen lokale API is, is wellicht het stomste. Ik snap bedrijven niet die wel gratis via de cloud diensten aanbieden, moeilijk gaan doen als apps als Home Assistant daar gebruik van gaan maken, en weigeren met een alternatief te komen. Waarom zou je je eigen klanten in de weg zitten?
Als ze een lokale api beschikbaar maken kost het hen niets.
En daarom zeg ik telkens als ik een nieuw apparaat koop en over een of andere gore cloud verbinding moet maken: "Die hoef ik niet." :P
Dit geldt dus voor mij ook. Heeft een of ander apparaat een internetverbinding nodig om te functioneren? Dan zou ik zo'n apparaat bij voorbaat al nooit kopen. Ik wil niet afhankelijk zijn van SaaS, want als ze de stekker er uit trekken, dan zit ik met een apparaat waar ik niets mee kan..
Ik kan er met mijn verstand niet bij dat mensen hun hele huis IOT-'fyen zonder enige garantie van levensduur en software updates van de fabrikant.

Kan ik mijn lampen morgen nog aanzetten?
Geen idee, dat hangt af van een KPI-manager die geen enkel verstand heeft van de materie; die rapporteert aan een even-clueless board of directors in een bedrijf dat over lijken gaat om iets meer winst uit te kunnen keren aan hun aandeelhouders. De aandeelhouders op hun beurt hebben geen benul wat het bedrijf doet waar ze in investeren want "To ThE mOoN!".

Sorry, dat klinkt gewoon als een heel slecht plan.
Dat geloof ik direct, ik denk dat men op een site als Tweakers verdeeld is over die twee uitersten. Juist wel omdat, of juist niet omdat.

Maar dat maakt hier geen verschil. Wat Haier doet is het dwarsbomen van het gebruik van externe software. Haier heeft nog wel zijn eigen app, die wasmachines blijven gewoon hun smart functionaliteit houden. Het is niet alsof ze de netwerk chips eruit slopen, ze willen alleen van de koppeling met HomeAssistant af.

En zo blijft het nadeel van verbonden wasmachines bestaan voor mensen die dat niet in huis willen hebben, terwijl mensen die een Haier machine willen vanwege de HomeAssistant support nu verder zullen kijken.

Ze schieten zichzelf alleen maar in de voet.

Persoonlijk heb ik het liefste dergelijke apparaten met gewone lokale API's, zodat ik ze in de router van het internet kan afschermen maar ze wel veilig kan integreren in mijn smarthome.
Volledig eens; en met de komst van Matter gaan we ook meer en meer die richting uit dat er standaarden zijn voor dergelijke zaken. In theorie had je dat met bvb Zigbee ook, maar daar zien we toch ook dat er custom quirks nodig zijn om dingen te doen draaien omdat sommige firma's (kuch, Tuya, kuch) het toch net even anders willen doen.

Ik had overlaatst een Fujisu warmtewisselaar gekocht en viel van m'n stoel. Wifi instellen en een gewone lokale API met het serienummer als token. Alles netjes en super responsive te bedienen. Ik heb die afstandsbediening dus letterlijk nog maar 1x aangeraakt gezien mensen hier al veel integraties rond gemaakt hebben.

Langs de andere kant kan ik wel begrijpen dat sommige integraties niet netjes om gaan met de API in de cloud en bvb veel meer requests doen dan wat de fabrikant verwachtte. Het verschil tussen "er gebeurt een request als een smartphone app open staat" of "100.000 installaties pollen elke minuut" is natuurlijk erg groot qua opzet van je infrastructuur. En dan kan dit financiële schade opleveren voor de firma.
Ze zeggen namelijk nergens de exacte reden of oorzaak en zeggen ook nergens dat ze wel of niet de wil van de mensen horen en een lokale api in de toekomst gaan maken. Het is niet omdat ze het niet zeggen, dat ze het niet gaan doen. Gezien het effect op hun servers (ga ik van uit), is de vraag toch groot.
Klopt, maar dan kun je er ook voor kiezen om de samenwerking aan te gaan. Het staat notabene op GitHub dus je kunt er zelf nog aan bijdragen ook. Daar kun je prima een disclaimer bij zetten dat je je het recht voorbehoud om de samenwerking eenzijdig op te breken. Maar dan boor je wel een flinke nieuwe potentiële user base aan.

Als ik dergelijk witgoed aanschaf is de mate waarin ik dat (bij hele grote voorkeur lokaal) in mijn smarthome kan integreren echt een grote factor.

Nou ja, geeft een een inkijkje zo in welke bedrijfsonderdelen het meeste te zeggen hebben.
Je weet dat IoT niet gelijk staat aan cloud, en niet gelijk staat aan data honger door grote bedrijven?
Theoretisch heb je gelijk, in de praktijk echter is dat precies waar het gelijk aan staat.
Het staat er helemaal niet precies gelijk aan. Ik schat dat ik pakweg rond de 100 devices in huis heb (grove schatting) die in de categorie IoT vallen, zoals allerlei sensoren, lampen, camera's, luchtreinigers, etc, en slechts enkelen daarvan hebben een afhankelijkheid van een cloud. De enige die ik nu kan bedenken zijn mijn kookplaat, de thermostaat , een Netatmo-sensor die ik alleen nog maar in de logeerkamer gebruik en de gateway voor de zonnepanelen. Die apparaten heb ik dan ook in een eigen vlan gezet die niet kan communiceren met de rest van het lokale netwerk.

Natuurlijk hangt het ook af van de keuze die men maakt bij aanschaf dus bij veel mensen zal het inderdaad zo zijn dat ze de lamp niet aankrijgen als hun internet eruit ligt. Ik let er tegenwoordig ook op of iets lokaal aanstuurbaar is en heb ook plannen om datgene dat nog op een cloud zit op termijn te vervangen.

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

De vraag is of je het dan nog over het traditionele IoT hebt. Internet-of-Things zonder internet, dat is meer een Intranet-of-Things. Nog steeds IoT, maar niet wat @familyman bedoelde... :+
Gebruik makend van internet om je eigen spullen met je eigen afstandbediening te bedienen.

Gewoon internet of things, dus
Zoals op Wikipedia ook benoemd wordt is de term Internet of Things een misnomer:
Internet of things has been considered a misnomer because devices do not need to be connected to the public internet, they only need to be connected to a network,[6] and be individually addressable.[7][8]

6 Beal, Vangie (2 March 2022) [1996-09-01]. "What is a Network?". Webopedia. Archived from the original on 22 November 2022. Retrieved 22 November 2022.
7 Dey, Nilanjan; Hassanien, Aboul Ella; Bhatt, Chintan; Ashour, Amira; Satapathy, Suresh Chandra, eds. (2018). Internet of things and big data analytics toward next-generation intelligence. Cham, Switzerland: Springer. p. 440. ISBN 978-3-319-60435-0. OCLC 1001327784.
8 "Forecast: The Internet of Things, Worldwide, 2013". Gartner. 18 November 2013. Retrieved 3 March 2022.
Kortom: als een apparaat adresseerbaar is, valt het in die categorie.
Afhankelijk van een cloud, maakt het internet of things. Andersom is niet per se geldig.

Je kan prima iot zonder cloud hebben.
Op een kleine minderheid die alles zelf bouwt na is het absoluut wel zo.
Nee hoor. Zat manieren om zonder klussen via internet je eigen meuk te bedienen, homey bijvoorbeeld.
Daar gaat het vaak niet om, helaas. Het is meer een soort 'indekken'.

Als er over 5 jaar een concurrent iets uitbrengt dat ze wél economische schade aanbrengt hebben ze dan, juridisch gezien, minder om op te staan: er is namelijk al 5 jaar een plug-in voor Home Assistant, en dat vonden ze prima.

Daarnaast is er ook nog de mogelijkheid dat er iets mis gaat met de plugins. Voor hetzelfde geld worden de airco's via home assistant gehackt. Dan kun je zeggen dat zij dat niet schuld zijn. Maar als op de voorpagina van CNN staat "HAIER HACKED". Wat maakt het dan nog uit?

Om deze redenen kiezen bedrijven - helaas - vaak voor wat zij zien als de veiligste optie.
Goed punt, maar z ekunnen ook een contract afspreken met de ontwikkelaar van de plugin. Zo hebben ze expliciet toestemming gegeven voor de plug in en met de juiste voorwaarden in het contract kunnen ze concurrenten wél tegenhouden.

Wat betreft het hacken: als de plugin er voor kan zorgen dat hun hele systeem gehackt wordt, is dat niet de fout van de plug in. Die gebruikt nl publieke APIs.

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

Open source makers staan vaak niet echt te springen om contracten met fabrikanten. En zelfs als het wel gaat dan brengt dat óók weer problemen met zich mee. Gaat de open source ontwikkelaar er voor zorgen dat niemand in Iran de plugin gebruikt? Ivm amerikaanse sancties?

Is maar een simpel voorbeeld, maar helaas zijn dit soort vragen de reden waarom de juridische afdelingen van dit soort bedrijven altijd neigen naar de simpelste oplossing.

Voor je tweede punt: het gaat er niet om dat hún systeem gehackt wordt. Wat als home assistant morgen een CVS 10 heeft, en het eerste script dat het misbruikt stuurt toevallig AIRCO's aan. Dan staat hun bedrijfsnaam, volledig buiten hun schuld om, op de voorpagina van kranten en nieuwssites.

Ik zeg niet dat dit de juiste oplossing is, maar helaas worden dit soort beslissingen nou eenmaal genomen door de advocaten, niet de IT'ers bij een bedrijf.
Als de api waarop de plugin gebaseerd is niet bereikbaar is vanuit Iran, dan zal de plugin daar geen verandering in brengen
Als ik Haier was had ik het concept omarmt en het juist gesponserd door het actief te ondersteunen. Dan had je controle gehad over het gebruik en een extra reden om je spul verkocht te krijgen. Dit is iets dat door legal wordt gedaan. Een slimme marketingclub had het anders gespind.

Het is overigens sowieso vervelend dat veel apparatuur een cloud-only verbinding heeft. Mijjn Solax omvormer is ook zoiets. Had vroeger een prima werkende interface via LAN. Na een firmware update is het cloud-only. Zeer verwerpelijk. Als China wil, dan zetten ze 90% van de Sloax omvormers op afstand uit. Bizar dat het mag. Daarmee zou je onze energievoorziening best in de soep kunnen laten draaien.
"That's not how it works; that's not how any of this works."
Als er over 5 jaar een concurrent iets uitbrengt dat ze wél economische schade aanbrengt hebben ze dan, juridisch gezien, minder om op te staan: er is namelijk al 5 jaar een plug-in voor Home Assistant, en dat vonden ze prima.
Het is mijn inziens hoog tijd voor een soort "reductio ad juridium" internet wet zoals reductio ad hitlerum.
Het moet eens klaar zijn met onzinnig geneuzel over "oh mAAR alS Ze IEmAnD AndERs x latEn DOeN dAn MoETEN ZE iEDEReEn ToElaTeN Om X onEinDIg Te LATen DOEn". Het argument sluit op geen enkele manier aan op de daadwerkelijke wet.

Het is perfect mogelijk voor een fabrikant om iets in de voorwaarden op te nemen over (mis)bruik van hun API dienst. Dat je toelaat dat Henk z'n nieuwe product een paar keer per dag aanstuurt buiten jouw app om betekent niet opeens dat een concurrent dan maar je API mag ddosen en je er niets aan kunt doen.
Daarnaast is er ook nog de mogelijkheid dat er iets mis gaat met de plugins. Voor hetzelfde geld worden de airco's via home assistant gehackt. Dan kun je zeggen dat zij dat niet schuld zijn. Maar als op de voorpagina van CNN staat "HAIER HACKED". Wat maakt het dan nog uit?
Er zijn theoretisch 3 ingangen om een fysiek product te hacken.
1. Via locaal netwerk, een kwaadwillende heeft directe toegang tot het netwerk waarop het product zich bevind en weet een gat in de FIRMWARE VAN HAIER te vinden.
2. Fysiek verbinding maken met het product via eventueel anwezige debug poorten en een gat in de FIRMWARE VAN HAIER vinden.
3. Via de API VAN HAIER een gat vinden om ondeugelijke data naar het product sturen en daarme de FIRMWARE VAN HAIER te misbruiken.

De plugin "doet" niets anders dan de app van Haier zelf al doet. Als je wasmachine, airco of weet ik wat gehackt word dan ligt de schuld daarvoor geheel en enkel bij Haier.
4. Home Assistant wordt gehackt en de plugin wordt misbruikt om de airco the hacken.

Je hebt gelijk dat HA niks anders doet dan hun app. Maar dat is het punt, het is HUN APP. Over HA hebben ze geen controle.

Het feit dat jij denkt dat ook als Home Assistant gehackt wordt de schuld alsnog bij HAIER ligt is denk ik ongeveer precies de argumentatie die hun adviseurs zal hebben gebruikt om hier tegen te zijn.
Nogmaals, zo werkt het niet.

Home Assistant (of de plugins) bied hier geen magisch achterdeurtje waardoor een hacker "opeens" naar binnen kan.
Als jij de plugin installeert zal je die toch eerst moeten authen, niet? Of is de API naar jouw eigen airco open voor de hele wereld?
De plugin praat met Haiers publieke API.
Oliedom, Haier verkoopt enkel meer devices OMDAT er Home Assistant ondersteuning is.
Voor mij is het een hele bewuste beslissing om geen devices meer te kopen die voor de "Smart" functionaliteit van een cloud-oplossing van de fabrikant afhankelijk zijn. Gaat gewoon niet meer gebeuren. De vele security issues kan ik nog wel managen door die troep op een dedicated en zeer geisoleerd WiFi-netwerkje te knallen, maar de ellende die je hebt als de fabrikant de cloud platgooit is gewoon niet waar ik op zit te wachten. Intussen al teveel ellende gehad en gezien met thermostaten, omvormers en andere meuk die in praktijk een groot deel van haar functionaliteit verloor omdat de fabrikant er klaar mee was of failliet ging. Als het smart is koop ik het voor de functionaliteit die ik zelf kan garanderen, op mijn eigen netwerk (in isolatie) met mijn domotica-oplossingen. De rest is gewoon te onbetrouwbaar.

Haier kan dus inderdaad van het lijstje af. Misschien tijd voor een lijstje van partijen die wel "local domotica" vriendelijk zijn?

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

De hoop is wat dat betreft natuurlijk enigszins gevestigd op Matter. Ook niet bepaald open natuurlijk, maar wel per definitie lokaal.

Maar ik doe vooralsnog hetzelfde. Al die rare cloud meuk komt er hier niet meer nieuw in, en het handjevol TuYa apparaatjes wat hier nog draait zit stevig geïsoleerd, wachtende op vervanging.

Lijkt mij overigens wel een mooie voor de EU om zich hard voor te maken. Smartmeuk verplicht ook via lokale API aan te sturen. Zou een hoop e-waste schelen.

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

Je geeft aan dat Matter een en ander op zou moeten lossen, maar wat is precies het voordeel boven bijvoorbeeld Zigbee? Dat is een protocol dat al een hele tijd bestaat, veel (relatief goedkope) producten kent en lokaal werkt zonder afhankelijkheid van externe servers.

Ik ben nog niet 100% thuis in deze verschillende protocollen, dus ik ben gewoon even benieuwd.
Zigbee is twee in één: de communicatie techniek én het protocol. Zigbee draait volledig lokaal en op zich is er absoluut niets mis mee.

Matter is alleen een protocol, een soort API. Die is bedoeld als allesomvattende standaard en wordt gesteund door Google en Apple, dus de kans lijkt groot dat ie aanslaat. Jammer wel dat de grote bekende techreuzen er achter zitten, maar Matter is wel ook per definitie lokaal aan te sturen en bijvoorbeeld HomeAssistant ondersteund het ook. Als Matter nou eens breed geaccepteerd wordt, dan zouden in theorie veel meer smart devices ook lokaal en dus los van de cloud bruikbaar moeten worden.

Niet zozeer beter dan Zigbee wat betreft openheid dus, maar wel een kans voor betere lokale mogelijkheden.
Okee, thanks voor de uitleg!
De hoop is wat dat betreft natuurlijk enigszins gevestigd op Matter. Ook niet bepaald open natuurlijk, maar wel per definitie lokaal.
Zelf werk ik nog met Z-Wave, en ik heb sommige devices gewoon electrisch zelf geschakeld. Mijn huis-ventilatie heb ik met behulp van Daaldrop en mijn instalateur gewoon electrisch via een Fibaro-schakelaar (met twee uitgangen) geschakeld. Daarmee ben je af van al het gezeur over API's en de ellende van DuCo die destijds wel Z-Wave ondersteunden maar alleen met hun eigen equipment. Alleen mijn controller moest even gaan snappen welke patronen hij wanneer op de schakelaar moest zetten.
Lijkt mij overigens wel een mooie voor de EU om zich hard voor te maken. Smartmeuk verplicht ook via lokale API aan te sturen. Zou een hoop e-waste schelen.
De EU moet gewoon aan gaan sturen op interoperabiliteit op Home Automation gebied. Eerlijk gezegd boeit mij het niet of het nu Z-Wave, Zigbee of Matter wordt, maar het wordt tijd dat we met zijn allen gewoon naar een Europese standaard gaan en dingen gewoon lokaal gaan laten werken.

Domotica gaat de komende tijd erg belangrijk zijn in het beheersen van de energievraag: idialiter gaan we als consumenten onze koelkasten hard laten koelen als de stroom overtollig is, en minder hard als stroom schaars is, etc.. Het kunnen sturen van die energievraag kan allemaal lokaal zonder clouddiensten (vanuit security en privacy eigenlijk de preferred oplossing), maar dan moet je wel spullen hebben die dit kunnen en die kunnen samenwerken. Dit is een belangrijk onderdeel van de energie-transitie, maar dan moet je de consument niet confronteren met het extreem gefragmenteerde landschap wat het nu is. Het moet voor de normale consument zo eenvoudig zijn als nu het koppelen van je BT headset aan je telefoon is.

Partijen die denken dat je consumenten kunt "opsluiten" in hun ecosysteem passen daar echt niet meer in. Als je haast wilt maken met de energie transitie dan kunnen we niet gaan zitten wachten op een partij die de standaard op basis van marktwerking dominant weet te krijgen.

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

localTuya geprobeerd? gebruik ik hier ook, werkt prima :)
Weet overigens niet of het device zelf nog het web op wil, dat mogen ze van mij (zitten in apart VLAN), maar aansturing gaat direct op local IP van het apparaat.

Hoop overigens niet dat Tuya hier moeilijk over doet zoals de vendor uit het bericht.
If so, dan is het zo afgelopen met die producten voor mij ;)

[Reactie gewijzigd door ctrl-tab op 22 juli 2024 15:44]

Er is geen HA ondersteuning. Mocht die er wel officieel zijn zou ik je gelijk geven. Maar iemand die een niet officiele plugin ziet en speciaal daarom een product koopt maakt sowieso al een grote fout want een onofficiele plugin kan er elk moment mee ophouden.

En als het dan gebeurd dat zo een product stopt met werken, wie krijgt er dan de slechte reclame? HA of de fabrikant van het product die HA nooit officieel ondersteund heeft? Juist ja, die fabrikant.

Het is ook niet dat ze geen data krijgen, in tegendeel. De plugin spreekt nog altijd tegen die cloud API omdat er geen lokale communicatie mogelijk is. Maar wie zegt dat die plugin dat op een correcte manier doet? Daarnaast dwingt die plugin de fabrikant nu ook om een API in leven te houden die men mogelijks wenst uit te faseren, of wenst aan te passen. Maar pas je hem aan of faseer je hem uit kom je terug bij het eerdere probleem van niet langer werkende HA integratie.
op zich mee eens. heb een jaar geleden een Haier wasmachine gekocht. heb wel bewust een IoT capabele gekozen,maar dat stond niet bovenaan de eisen. wist toen nog niet of HA werkte en de app is verre van verschrikkelijk. maar nu ik eenmaal gewend ben aan de HA intergratie zou ik hem niet graag meer missen.
Een officiële plugin kan er ook zomaar ineens mee ophouden (of vanwege security issues praktisch onbruikbaar worden). Dat is nou eigenlijk het echte probleem van die cloud oplossingen.
Je spreekt jezelf wel tegen; ze verkopen meer door HA maar het aantal extra gebruikers daardoor is 'een paar'. Los van dat vind ik hun verzoek ook onnodig, maar ik snap ook wel weer dat ze controle willen houden over hun diensten.
Wat ik lees in de comments op Github issues, is dat het Haier waarschijnlijk gaat om het gebruik van hun API voor alle requests. Kans zit er best in dat de HA integratie onnodig veel requests doet en dat dit de 'economische schade' is.

Volgende stap is om de apparaten gewoon te voorzien van nieuwe firmware zodat je lokale requests kan doen (rechtstreeks naar HA), ofwel op DNS niveau de requests lokaal afvangen.
Dat kan 1 verklaring zijn, maar aan de andere kant heeft Haier ook geen controle over deze code en integratie in HA wat betekend dat op de dag dat zij hun API aanpassen en de integratie met HA door deze plugin breken, dat zij wel de reputatieschade gaan krijgen alsook de klachten van klanten.

Het lokaal afvangen van requests op DNS niveau is een heel stuk complexer om op te zetten en gaan vele gebruikers niet kunnen of willen doen. En voor het rechtstreeks spreken met de toestellen ben je dus opnieuw afhankelijk van de fabrikant die het mogelijk maakt.
reputatieklachten valt wel mee, de HA community is tov hun totale userbase volgens mij niet zo groot :)
Dat klopt: /pyhOn/blob/main/pyhon/const.py hierin staan API urls van HA. Er worden geen aanroepen rechtstreeks naar het apparaat gedaan, maar naar de API van HA.
Begrijpelijk, maar het is wel ook de keuze om alles via verplichte online platformen te laten verlopen (en het dus ook niet meer werkt als de fabrikant er mee stopt).

Hopelijk komt er ooit een verplichting om het inderdaad lokaal mogelijk te maken, of op zijn minst dat het mogelijk moet zijn om dat te doen als de fabrikant met de ondersteuning stopt.
na het faillissement van een e-bike maker (VanMoof), was het kort een drama om deze fiets nog te kunnen unlocken.

Toen waren er mensen die zich afvroegen, of er een verplichting moet zijn om de server-code te 'open-sourcen' indien ze failliet gaan. Zodat er op zijn minst een alternatief kan starten. Nuja, het blijft niet perfect, want je e-device zal wel naar een specifieke URL willen gaan... Dus... hoe los je dat op?
Een publieke API zonder rate limiting is vragen om problemen. Het maakt je dienst namelijk kwetsbare voor DOS attacks. Het is heel redelijk om het aantal requests per minuut/uur/dag te beperken.
Bizarre zet van de fabrikant. Je maakt je product onaantrekkelijker en dat alleen maar om een handvol hobbyisten te stoppen en te dwingen je app te gebruiken. Waarom? Puur voor de tracking?
Het zou kunnen dat Haier dit moet doen omdat ze bv. contractueel iets hebben vastgelegd met een partij die hen betaald voor de data.

Dat ze zichzelf hier onnodig impopulair mee maken zal iedereen duidelijk zijn, dus er zal een financiële beweegreden achter zitten. Geeft ook meteen heel duidelijk aan dat er "big money" zit in dit soort data.

Het bizarre is dat het netto geen enkel effect zal hebben voor (bestaande) gebruikers: Niemand kan mij verbieden om tegen gebruikersvoorwaarden in te gaan van een bedrijf waar ik helemaal geen contract en/of dienst afneem. En het feit dat het open-source is met 100+ forks zegt al genoeg, gelukkig :)
meeste van de 1000+ forks zijn door mensen die een punt willen bewijzen. mede doordat Haier nu niet achter 1 persoon aan moet gaan maar 1000+, om de addon compleet te verwijderen van "github/ het internet"

En dan heb je ook nog de ontelbare downloads/backups die mensen hebben gemaakt van de plugin.
Nee hoor, zij kunnen evengoed een verzoek direct naar Github sturen welke dan alle forks in 1 keer kan neerhalen.
Nee dat mogen ze niet, dat zou weer een probleem voor Github geven voor landen waar het wel is toegestaan.
Daarbij zal Github echt z'n vingers daar niet aan branden zonder tussenkomst van een rechter, dat zou ze onderdeel van het conflict maken
Ik heb een fork online van iets wat door een C&D offline moest worden gehaald, het is aan de ontwikkelaar om het te verwijderen, niet aan github.

Github krijgt geen verzoek van de politie ofzo he. Met een C&D stuurt een bedrijf gewoon een dreigbrief met joh haal je meuk offline of we klagen je aan
Dat er een financiele beweegreden achter zit, lijkt me nogal wiedes, gezien de zin
De plug-ins 'gebruiken onze diensten op een ongeautoriseerde manier die significante economische schade aan ons bedrijf toedoet', schrijft Haier.
uit het nieuwsbericht.
Ik denk dat veel HA mensen nu geen Haier producten meer gaan kopen. Haier is immers een onbetrouwbare partner.

Het is niet uitgesloten dat ze hun cloudomgeving en toegang tot hun producten verder gaan dichttimmeren.,

Ik zou een open API beleid opzetten met goede documentatie. Desnoods help je de community om ook lokaal services te draaien. Zo worden je producten populair bij installateurs, HA community etc.
Dit begint te komen, enkele Main contributors voor HASS, hebben op reddit all een POLL gemaakt of hier vraag naar is, van wat wel open/supported is, en welke devices zijn dichtgetimmerd
Tja ik heb hier 5 en split 3x2.5 je staan doe zomer het dak op gaan.
Zal wel weer hoop gedoe worden om aan te sturen mochten ze iets dicht timmeren.

Jammer weer
De airco's zijn ook direct via modbus aan te sturen. Van niemand afhankelijk en werkt altijd.
ik was al aan het kijken of infrarood of een ESP er aan hangen en dat gedoe vervangen dan zit het lokaal ook.
in ieder geval bedankt voor de tip.
Als je meer info nodig hebt stuur maar een PB als het zover is. Ik heb het op die manier draaien en het werkt perfect.
Ik denk echt dat dit gewoon advocaten zijn die denken: "Ah, iets te doen! We kunnen laten zien dat we nuttig zijn!" Verder zijn het complete digibeten.

Net als bij Mazda en TP-Link. Signify begin ik me ook aan te irriteren, ineens heb ik een cloud account nodig (en krijg ik elke dat een reclame in mn gezicht in de app!). Maar gelukkig werken de lampen aardig met een eigen ZigBee netwerk (met de Home Assistant SKy Connect dongle, kan je straks ook gelijk over op Matter).

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

Reclame in de Hue app? Dat heb ik nou echt nog nooit gezien.
Ik wil een automatisering uitzetten en bam: "Laat je goede voornemens shinen met 15% korting!", over het hele scherm heen.

In de Sonos app is het nog erger, mijn vrouw wilde laatst iets luisteren (op een systeem waar we voor betaald hebben, met een service waarvoor we betalen...) en het lukt niet want ze kreeg de reclame niet weg. Uiteindelijke kwam ze naar mij en ik zag wel het minuscule kruisje rechts bovenaan. Ik ben er zo klaar mee.
Ik wil een automatisering uitzetten en bam: "Laat je goede voornemens shinen met 15% korting!", over het hele scherm heen.
Dat heb ik nu echt nooit in de Hue app. Nu gebruik ik de app ook zo heel vaak, maar reclame heb ik echt nog niet gezien daarin. Zeker niet in de gewone delen van de app zoals verlichting of automations aanpassen.
Inmiddels zijn er , een enorme toename van de enkele tientallen forks die de plug-ins eerst hadden.
Dit zijn wel forks op GitHub gemaakt via de "Fork" knop van GitHub. In iedee geval bij een takedown verzoek worden deze allemaal in een keer verwijderd.

Betere manier van preserveren is uberhaupt zelf lokaal de repository clonen, en dan of naar een nieuwe GitHub repository pushen (nog steeds tricky, omdat de commit hashes overeen komen) of bij een alternatieve dienst (GitLab, BitBucket, ...) of een selfhosted omgeving die niet publiekelijk toegankelijk is.

Maar GitHub Forks, gewoon via de knob, zijn absoluut niet "veilig", gezien dus in ieder geval GitHub ze in een keer mee-wiped. En wellicht geldt dat ook wel op het moment dat de originele repositoy wordt verwijderd door de eigenaar.
(nog steeds tricky, omdat de commit hashes overeen komen)
Niet als je het gewoon commit, ipv direct pushed.
Je zou zelfs kunnen rebasen. Dan worden de bestaande commits (dacht ik) nieuwe commits met nieuwe hashes.

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

Alleen als je de code download (ZIP) of de bestanden lokaal kopieert en dan een nieuwe repository aanmaakt ja. Als je op een fork een nieuwe commit pusht heeft die ene commit wel een onbekende commit hash, maar de voorgaande commits matchen nog steeds met de originele repository en kan dus ook eenvoudig gedetecteerd worden.

En een bestand heeft ook weer een hash. En een map met bestanden, of submappen, wordt gerepresenteerd door een tekst bestand met een lijst bestandsnamen met hun respectievelijke hash, en dit bestand heeft ook weer een hash. En een commit verwijst vervolgens naar de hash van de root directory zeg maar. Dus een een-op-een kopie van de bestanden committen levert nog steeds dezelfde hash van de directory tree (+ daarmee bestanden in die tree) op, ondanks dat de commit hash natuurlijk wel anders is.
Dus je moet dan wel echt de kleine moeite nemen om op zijn minst bv ook een leeg bestand toe te voegen zodat de hash van de tree anders is. Hashes van individuele blobs zal GitHub waarschijnlijk veel minder snel gebruiken, en doordat Git sha1 gebruikt zullen er ook wel collissions voor komen waarbij twee verschillende blobs dezelfde hash hebben (kans is extreem minuscuul dat het gebeurt in één repository / project, maar met de grote van GitHub en de vele individuele projecten natuurlijk wel groter).
Er zijn 984 forks. De kans dat iemand de repo gekloond heeft, is dan significant. Zeker omdat dat nodig is om er iets mee te doen. M.a.w., een repo die alléén maar op de remote staat, kun je bijna niets mee. Waarom zou je een repo forken en er dan vervolgens niets mee doen?...

Dus vermoedelijk het enige dat iemand met een gekloonde repo hoeft te doen, is een `git push`, en het staat er weer. Hooguit eerst nog ff een repo aanmaken.

Dus het enige resultaat is dat die 984 forks nu niet meer aan elkaar gerelateerd zijn en feitelijk losse repo's worden. Dus wat heeft Haier dan bereikt? Nog 984 extra takedowns?
Zeker omdat dat nodig is om er iets mee te doen
Je kunt gewoon de originele repository gewoon clonen. Alleen kun je niet terug pushen als je dat zou willen.

Als het puur gaat om het hebben van de code voordat de ontwikkelaar de repo uit de lucht haalt (of het via een GitHub DMCA verzoek gebeurt) is er dus geen enkele reden om die fork aan te maken.

Terwijl die 900+ forks waarschijnlijk echt een reactie is op deze mededeling, en er vooraf misschien een paar honderd forks waren. En al die forks waren dus niet nodig geweest. En als Haier de route bewandelt van een DMCA claim bij GitHub (dat juridisch twijfelachtig is maar normaliter wel wordt uitgevoerd) zijn ze alle 900+ in een keer weg. Dus Haier hoeft hiervoor dan helemaal geen 900+ individuele takedown verzoeken te doen.
Dus Haier hoeft hiervoor dan helemaal geen 900+ individuele takedown verzoeken te doen.
Dat denk ik dus wel, want een repo die geforkt wordt, wordt ook gekloond, en kan dus gewoon gepushed worden. Evt naar een nieuwe repo die geen relatie heeft met de orginele. Misschien niet alle 900, maar zeker wel een paar honderd, lijkt me.

Ik weet niet waarom je anders een repo zou klonen?
weet niet waarom je anders een repo zou klonen?
Normaal gesproken dus omdat je geen push toegang hebt tot de originele repo. In dit geval denk ik dat er vele onwetenden zijn die niet weten dat GitHub alles down kan halen.

Dit is wat GitHub er zelf over schrijft: https://docs.github.com/e...out-forks-or-whats-a-fork
In addition, if the reported network that contains the allegedly infringing content is larger than one hundred (100) repositories and thus would be difficult to review in its entirety, we may consider disabling the entire network if you state in your notice that, "Based on the representative number of forks I have reviewed, I believe that all or most of the forks are infringing to the same extent as the parent repository."
Dus een claimer kan aangeven dat het hele "netwerk" in overtreding is waarna GitHub ook nieuwe forks offline haalt, na handmatige validatie dat alle gemelde forks / repositories ook inbreuk maken. En in het geval van 100+ forks gaat GitHub niet eens valideren en is een statement van "op basis van onze controle blijkt dat alle gecontroleerde forks inbreuk maken en daarmee doen we de aanname dat ook de niet gecontroleerde forks inbreuk maken".

En alle forks waarop geen nieuwe commits zijn gedaan zijn dus per definitie vatbaar voor deze claim. Want geen commits betekent ook dat er geen wijzigingen zijn waardoor de claim niet meer relevant is. Wat GitHub dus ook omschrijft: standaard halen ze forks niet offline omdat ze niet weten of de fork wijzigingen bevat waardoor de claim niet geldig is (een stuk copyrighted code kan in een fork herschreven zijn bv). Maar een beetje juridisch team (ingeschakeld door Haier) prikt hier dus zo doorheen door bij alle forks te controleren of ze uberhaupt additionele commits bevatten die niet in de origineel zitten.

En blijkbaar heeft GitHub in het verleden zelfs aangegeven dat ze users zouden bannen die een fork van een verwijderde repo opnieuw online zouden zetten: https://www.theregister.c...ithub_youtubedl_deletion/
Waarom zou je een repo forken en er dan vervolgens niets mee doen?...
Omdat in dit geval de meeste forks zullen zijn gemaakt als statements. Even op de fork knop drukken is makkelijk. Werkelijk clonen en terugzetten is meer werk (maar niet veel). En github kan alle forks met een druk op de knop verwijderen waarschijnlijk.

Ik denk dat minder dan 1% de code werkelijk lokaal gehaald zal hebben. Maar 1 is genoeg en de dag daarna staat het weer online. Haiber had zich beter in kunnen lezen in het "streisand" effect voor ze deze super domme brief de deur uit deden.
Het gaat om publieke API's morgen is er een nieuwe plugin...

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

Gebruikers onvriendelijker kan het niet...
Ga dit jaar twee airco's ophangen en Haier wort het dus zeker niet!!!

https://www.youtube.com/watch?v=RcSnd3cyti0&t=23s
Tip van flip:
sla Daikin ook maar over. Hebben recent de integratie van homeassistant gebombardeerd. Werkt nu heel brakkig (ondanks dat ik de officiele retrofit-wifi dongel ervoor gekocht heb).
Airco zat in het huis dat ik kocht en Daikin leek best soepel om te gaan met HA dus ik was blij maar helaas.. Doodzonde en compleet mesjogge dat we straks met gebeunde ir-blaster oplossingen onze apparatuur moeten gaan aansturen terwijl het technisch gewoon keurig via een open API zou moeten kunnen.
Bij mij werkt Daikin nog prima lokaal, wat is er veranderd?
Van: https://www.home-assistant.io/integrations/daikin
Daikin has removed their local API in newer products. They offer a cloud API accessible only under NDA, which is incompatible with open source. This affects units fitted with the BRP069C4x wifi adapter. Units listed under Supported Hardware below continue to have access to local control. Additionally the older but commonly available BRP072A42 adapter can be fitted to most if not all newer units for access to local control.
Ik zie nu dat het zou kunnen dat het niet zo erg is als het lijkt:
Daikin has removed their local API in newer products. They offer a cloud API accessible only under NDA, which is incompatible with open source. This affects units fitted with the BRP069C4x wifi adapter. Units listed under Supported Hardware below continue to have access to local control. Additionally the older but commonly available BRP072A42 adapter can be fitted to most if not all newer units for access to local control.
Ik heb even niet paraat welke wifi unit ik heb maar bij mij crasht de wifi unit als ik 'm uitzet via HA. (lijkt alsof de gehele unit power down gaat en daarmee dus ook de wifi unit stroomloos raakt)
ok, dankjewel! En vervelend dat hij crasht bij uitzetten. Dat is nou ook niet echt wat je mag verwachten van lokale controle :/
bedankt voor info. zag deze ook langs komen:
Vorige maand airco laten installeren en hierbij gekozen voor Mitsubishi Heavy Industries vanwege de mogelijkheid om hem compleet lokaal te integreren. Als het via een ander z'n computer gaat heb je uiteindelijk niet de controle over je eigen apparatuur blijkt ook deze keer weer

het wordt dus een Mitsubishi Heavy Industries :-)
Met ir zal niet nodig zijn. Zowel Haier als Daikin zijn via modbus aan te sturen, sowieso de enige manier als je echt onafhankelijk wilt zijn...
Ik heb ze van Mitsubishi, heel tevreden mee en integratie met HA werkt perfect.
De eigen app is wel wat ouderwets, maar die gebruik ik toch niet.
which is causing significant economic harm to our Company
Ja, zal best. Je wilt gewoon dat iedereen jouw app gebruikt waarbij je waarschijnlijk lekker zit te smullen van user data en die waarschijnlijk alleen werkt via de cloud.

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

Een uitspraak die ik niet echt snap. Het is niet omdat je die lokaal bedient, dat het apparaat geen data meer doorstuurt.
Ik ben het niet zeker maar ik dacht dat dit project gebruik maakt van de api van Haier. Dus of je nu een airco instelt via Home Assistant of via hun app, de data krijgen ze toch.
Het is niet omdat je die lokaal bedient, dat het apparaat geen data meer doorstuurt.
Je vergeet denk dat als hun cloud uit de lucht valt of, nog erger, het bedrijf onder gaat, dat je het apparaat niet meer kan bedienen. Daarnaast is het soms ook langzamer, beveiliging problemen, etc. Er zit meer achter lokale bediening dan alleen gebruikersdata.
daar ging je post ook helemaal niet over. Je zei dat firma's willen dat je hun app gebruikt voor de user data. Nu kom je af met de nadelen van cloud gebruik. Dat zijn volledig terechte punten. Ik gebruik zelf ook geen toestellen die cloud gebaseerd zijn behalve Honeywell. Op dat moment was dat precies de enigste mogelijkheid. Ik had zelfs nog nooit gehoord van Home Assistant, Zigbee, ... op dat moment.

Dus de punten, die je nu aanhaalt, kloppen volledig maar het was daar niet op dat ik reageerde ;)
Oh excuses haha dacht dat je daar op inging. Was me niet helemaal duidelijk.
Wat dom van Haier. In plaats van te omarmen zorgt Haier ervoor dat gebruikers van HA wel andere apparatuur kiezen die wel een (HACS) integratie hebben met HA. Nu kunnen zo bijna 1000 takedown verzoeken sturen én ze verliezen potentiele omzet.
Niet te vergegen dat die "tweakers/HA gebruikers" Familie en vrienden HAIER compleet afraden.

Waardoor ze ook nog eens een grote portie mond op mond reclame mislopen.

Op dit item kan niet meer gereageerd worden.