[Philips Hue] Ervaringen & discussie - Deel 2

[meesje]

Verwijderd schreef op donderdag 4 januari 2018 @ 20:36:
[...]


Niet meer, want ik staak de discussie. Het is zinloos, Erik verzint gewoon nieuwe dingen waar je bij staat, en blijft beleren. Als je hem wijst op een fout, praat ie er gewoon overheen of herhaalt ie zelfs een paar postings later wat je net gezegd hebt en waar hij het eerst mee oneens is. Dr. Klavan. Daar ga ik verder geen tijd in investeren, het blijft het herhalen van argumenten zo. Mijn 2ct staat er nu vrij duidelijk, en is onderbouwd.

Ik ben zelf bezig met een kickstarter voor een device wat wél open is en niet vendor locked, en ook werkt met de philips spullen (allemaal), ondersteuning heeft voor 433Mhz, 866 en 2,4 (wifi/zigbee) én onder de 100 euro blijft (consumentenprijs).

Dus ik vind het helemaal niet erg dat Philips de boel vendor locked heeft. Sterker nog, ik hoop er geld mee te gaan verdienen.

(en verdien nu mijn geld al met home automation development)

Een RPI met domoticz...?
Zonder gekheid, als het zo ver is, post je dan hier even een berichtje?

[Ino Dekker]

Een control device stuurt light commando's naar de devices (lampen) waarmee het is gepaired, ipv sensor waarden of button events zoals bij de tap, dimmer switch of motion sensor. Het sturen van licht commando's naar de bridge heeft geen zin, want het heeft die capabilities niet.

Vwb vendor lock: zolang er nog geen voorbeelden bestaan van niet-Philips sensoren/switches die toegevoegd kunnen worden aan de bridge (dus niet alleen aan het ZigBee netwerk), dan kan ik mij voorstellen dat dit wordt gezien als een vendor lock.
Zoals aangegeven zijn er 3rd party ZGP switches, maar sturen deze (gegarandeerd) dezelfde button event waarden zodat de Hue App er chocola van kan maken? Waarschijnlijk niet, want dat staat nergens in een specificatie. Datzelfde zal ook gelden voor een ZLL switch, de specificatie laat nogal vrij hoe dat allemaal zou moeten werken.
De API van de bridge is open, dus een applicatie maken die wel chocola kan maken van die onbekende devices is mogelijk.

Dat je trouwens geen andere sensor types (dan waarvan een Philips sensor beschikbaar is) aan de bridge kunt toevoegen kan natuurlijk ook komen omdat dit simpelweg niet geïmplementeerd is.

[Verwijderd]

meesje schreef op donderdag 4 januari 2018 @ 20:40:
Een RPI met domoticz...?
Zonder gekheid, als het zo ver is, post je dan hier even een berichtje?

Nee, een custom PCB, geen home hacked iets. Verder klopt wat je zegt; zoiets is zelf al te maken nu op basis van een RPI. Dus voor echte tweakers is wat ik maak niet interessant. Voor het gros der thuisgebruikers echter wél. Want voor jij jouw RPI voorzien hebt van alle benodigde dongles, software, en instellingen, ben je wel een paar avonden zuchten en vloeken verder

@Ino Dekker : thx. Ik ben het 100% met je eens. Ik stel het alleen iets harder.

Je kunt zelf een app ontwikkelen die met de hue bridge praat, en daarmee wordt het wel mogelijk om ook echt devices via de hue bridge te laten werken (en bv. gebruik te maken van een bridge-based timer, oid).

Je kunt ook 3rd party schakelaars koppelen aan hue lampen (buiten de bridge om).

Dat kan allemaal wél. Maar een 3rd party schakelaar via de app op de hub werkende krijgen? vergeet het maar. Dát is de vendor lock.

[ Voor 30% gewijzigd door Verwijderd op 04-01-2018 20:47 ]

[Erik1971]

meesje schreef op donderdag 4 januari 2018 @ 20:34:
[...]

Maar los van de techniek, is de betekenis van een vendor lock in toch dat de leverancier er alles aan doet om er voor te zorgen dat je aan hun produkten gebonden bent?

Zo lees ik het ook en dan gaat dat niet helmaal op voor Hue eco systeem, je kunt gewoon via standaard app lampen van derden toevoegen.

Voor remotes en controllers ligt dat technisch wat lastiger, je zou het als een Vendor Lock kunnen beschouwen zoals @Verwijderd dat stellig probeert uit te leggen, maar probleem voor remote controls specifiek is dat deze vrij zijn in hoeveel knoppen er bijvoorbeeld opzitten, dat maakt integratie met andere partijen gewoon lastig, je kunt namelijk geen rekening houden met alle mogelijke combinaties.

Op deze manier beschouwt zul je altijd "Vendor Lock" hebben wanneer je een remote van een derde aan je systeem toevoegt via je bridge ongeacht het Philips, Ikea of wat ever merk het is.

Is misschien iets waar een partij als Homey op kan in spelen, maar kost wel tijd en dus geld om zoiets te maken en onderhouden.

[meesje]

Verwijderd schreef op donderdag 4 januari 2018 @ 20:43:
[...]


Nee, een custom PCB, geen home hacked iets. Verder klopt wat je zegt; zoiets is zelf al te maken nu op basis van een RPI. Dus voor echte tweakers is wat ik maak niet interessant. Voor het gros der thuisgebruikers echter wél. Want voor jij jouw RPI voorzien hebt van alle benodigde dongles, software, en instellingen, ben je wel een paar avonden zuchten en vloeken verder

Daarom doe ik niks meer met rpi en domoticz. Ik heb geen zin in knutselen. Ik wil dat het gewoon werkt (hue/homekit). Natuurlijk zijn er beperkingen. Die accepteer ik en soms worden ze in een volgende update opgelost/functionaliteit uitgebreid.

Ik ben dan ook geen ‘echte’ tweaker...

[8-Track]

Verwijderd schreef op donderdag 4 januari 2018 @ 20:28:
[...]


= vendor lock.

Volgens jouw definitie misschien wel, volgens de mijne niet. Want ik ervaar vendor-lock in een situatie waar ik alleen Philips hardware (volledig) kan gebruiken. Er wordt mij een (triviaal) stukje gebruiksgemak ontnomen, maar geen functionaliteit en daarin ligt in mijn ogen de crux.

Beschrijf eens HOE je hem gebruikt? En wat je moest doen om hem te kunnen gebruiken?

Ik moest alle lampen die ik in de scene wilde aanzetten, de rest uit. Daarna de wandzender in de programmeerstand, dan de lampen in de gewenste kleur/dimstand, scene vastleggen met een druk op de knop en klaar. Klusje van niks, en in vergelijking met de hopeloze user experience van de Hue app waarin ik bijvoorbeeld niet eens drie lampen in één armatuur kan groeperen valt het me alles mee.

Maar nogmaals, er wordt mij geen functionaliteit ontnomen.

Nogmaals, het gaat niet over 'ervaren' of meningen.

Puur kijkend naar de feiten vind ik het geen vendor lock-in. Overigens vind ik het wél bloedirritant dat ik bijvoorbeeld mijn Busch-Jaeger dimmer wel in de Hue app zie maar niet in Apple Homekit, en dat ik iets als homebridge moet gebruiken om alles naadloos te laten werken.

Maar ik betwijfel of dat Philips aan te rekenen is, het kan heel goed een licentie-restrictie zijn van Apple...

[Xander]

zeef schreef op donderdag 4 januari 2018 @ 15:48:
Ik krijg buiten eigen netwerk geen verbinding meer met mijn Hue bridge. Niet op android, niet op iOS. Het heeft een half jaar probleemloos gewerkt, maar nu niet meer. Moet ik een poort opengooien in Ziggo modem?

Communicatie gaat via Hue servers, je hebt er geen port forwarding voor nodig.

Is je bridge nog wel gekoppeld aan je Hue account? Op https://account.meethue.com/bridge

Kun je op https://my.meethue.com/ de boel wel bedienen?

Anders zou ik eerst de bridge eens een reboot geven als je dat nog niet geprobeerd hebt.

[Verwijderd]

8-Track schreef op donderdag 4 januari 2018 @ 20:51:
Ik moest alle lampen die ik in de scene wilde aanzetten, de rest uit. Daarna de wandzender in de programmeerstand, dan de lampen in de gewenste kleur/dimstand, scene vastleggen met een druk op de knop en klaar. Klusje van niks, en in vergelijking met de hopeloze user experience van de Hue app waarin ik bijvoorbeeld niet eens drie lampen in één armatuur kan groeperen valt het me alles mee.

Dan heb je dus niet je schakelaar via de hub bruikbaar gemaakt.

Je kunt bij zigbee lampen en schakelaars aan elkaar koppelen zonder hub. Dat werkt inderdaad wel met de philips lampen en spullen van derde. Eigenlijk gebruik je dan het systeem van de derde, en voeg je daar de philips endpoints aan toe. Niet andersom.

[Erik1971]

Ino Dekker schreef op donderdag 4 januari 2018 @ 20:43:
Een control device stuurt light commando's naar de devices (lampen) waarmee het is gepaired, ipv sensor waarden of button events zoals bij de tap, dimmer switch of motion sensor. Het sturen van licht commando's naar de bridge heeft geen zin, want het heeft die capabilities niet.

Vwb vendor lock: zolang er nog geen voorbeelden bestaan van niet-Philips sensoren/switches die toegevoegd kunnen worden aan de bridge (dus niet alleen aan het ZigBee netwerk), dan kan ik mij voorstellen dat dit wordt gezien als een vendor lock.
Zoals aangegeven zijn er 3rd party ZGP switches, maar sturen deze (gegarandeerd) dezelfde button event waarden zodat de Hue App er chocola van kan maken? Waarschijnlijk niet, want dat staat nergens in een specificatie. Datzelfde zal ook gelden voor een ZLL switch, de specificatie laat nogal vrij hoe dat allemaal zou moeten werken.
De API van de bridge is open, dus een applicatie maken die wel chocola kan maken van die onbekende devices is mogelijk.

Dat je trouwens geen andere sensor types (dan waarvan een Philips sensor beschikbaar is) aan de bridge kunt toevoegen kan natuurlijk ook komen omdat dit simpelweg niet geïmplementeerd is.

Hoi Ino, goed verhaal

[8-Track]

Verwijderd schreef op donderdag 4 januari 2018 @ 20:54:
[...]


Dan heb je dus niet je schakelaar via de hub bruikbaar gemaakt.

Je kunt bij zigbee lampen en schakelaars aan elkaar koppelen zonder hub. Dat werkt inderdaad wel met de philips lampen en spullen van derde. Eigenlijk gebruik je dan het systeem van de derde, en voeg je daar de philips endpoints aan toe. Niet andersom.

Ik heb de wandzender in mijn Zigbee netwerk gehangen via Touchlink. Ik heb hem op mijn bridge gelegd om te pairen. Dat was de eerste stap die ik er voor de volledigheid bij had moeten zetten. Voor alle duidelijkheid, ik hoef niet iedere lamp individueel te pairen met de wandzender, dus ook dit was weer een klusje van niks en heb ik geen verlies aan functionaliteit, alleen een triviaal stukje gebruiksgemak.

Als ik kijk hoeveel tijd en moeite ik kwijt was aan het inregelen van een Hue Tap en een Busch-Jaeger wandzender, maakt het al met al niks uit en kunnen ze uiteindelijk in dagelijks gebruik precies hetzelfde.

[Ino Dekker]

Verwijderd schreef op donderdag 4 januari 2018 @ 20:43:
[...]
Maar een 3rd party schakelaar via de app op de hub werkende krijgen? vergeet het maar. Dát is de vendor lock.

Zou jij als ontwikkelaar resources (tijd en geld) willen inzetten om app ondersteuning voor devices waarvan je niet kan garanderen dat je ze goed werkend kan krijgen? Zoals het geval bij een switch waarvan de button events af kunnen wijken van je eigen devices?
Zodra het maar een paar devices zijn ben je misschien nog wel geneigd dit te doen, maar wat als het een significant aantal wordt? Dit moet je dan allemaal (blijven) testen.
Kan een fabrikant van zo'n 3rd party switch dat voor hun product niet beter doen? Daar is het systeem toch ook 'open' voor?

Ik wil niet zeggen dat dit geen vendor locking is (da's mi een mening), maar er is een keerzijde aan een 'open' systeem op basis van enkele standaarden die nogal wat ruimte laten voor eigen interpretatie... helaas zelfs met certificering eromheen.

[Grvy]

Erik1971 schreef op donderdag 4 januari 2018 @ 20:56:
[...]

Hoi Ino, goed verhaal

"Goed verhaal" want ik ben het met je eens. Dat is nog eens knap.

Philips en het hele hue systeem is gewoon een vendor lock-in.

Vendor lock-in is het verschijnsel dat een klant zo zeer afhankelijk raakt van een leverancier dat afscheid nemen of overstappen niet langer mogelijk is zonder grote (financiële) gevolgen.

Dus. Kijk naar wat het betekent. Kan je overstappen van HUE zonder financiële gevolgen? nee. Want de philips hue lampen doen het niet op een andere bridge etc; dus die zul je allemaal moeten vervangen.

[Erik1971]

Ino Dekker schreef op donderdag 4 januari 2018 @ 21:07:
[...]


Zou jij als ontwikkelaar resources (tijd en geld) willen inzetten om app ondersteuning voor devices waarvan je niet kan garanderen dat je ze goed werkend kan krijgen? Zoals het geval bij een switch waarvan de button events af kunnen wijken van je eigen devices?
Zodra het maar een paar devices zijn ben je misschien nog wel geneigd dit te doen, maar wat als het een significant aantal wordt? Dit moet je dan allemaal (blijven) testen.
Kan een fabrikant van zo'n 3rd party switch dat voor hun product niet beter doen? Daar is het systeem toch ook 'open' voor?

Ik wil niet zeggen dat dit geen vendor locking is (da's mi een mening), maar er is een keerzijde aan een 'open' systeem op basis van enkele standaarden die nogal wat ruimte laten voor eigen interpretatie... helaas zelfs met certificering eromheen.

Hopelijk wordt dit in de toekomst opgelost met een standaard opgelegd door de grote spelers als Apple, Google en Amazon, waarin de interoperability beter is vast gelegd, maar dat zal dan wel gaan ten koste van inovatie.... (zoals in het verleden ook met de verschillende video standaarden is gebeurt).

[Xander]

Verwijderd schreef op donderdag 4 januari 2018 @ 20:07:
Thx, Meesje. En dan de volgende casus:

Je koopt een philips hue bridge en philips lampen en schakelaars. Dat werkt allemaal goed. Nu koop je een trust ZLL Zigbee magnetische schakelaar. En die werkt NIET.

Ik heb ook een casus voor je:

Ik heb een ouderwetse Philips TV met daarbij een infrarood afstandsbediening. Dat werkt allemaal goed. Nu koop ik een infraroodafstandsbediening van Sony. En die werkt NIET.

Vendor Lock-In!!!!!111

Ja? Of nee? Dat mijn Philips TV niet naar die Sony afstandsbediening luistert, wil toch nog niet zeggen dat Philips bewust andere merken uit sluit? Dat is namelijk pertinent niet waar, genoeg universele afstandsbedieningen (zoals Logitech Harmony) die mijn TV wel prima kunnen bedienen.

Is die "trust ZLL Zigbee magnetische schakelaar" wel gemaakt om universeel met allerlei soorten Hubs te kunnen babbelen? Wie zegt dat het stukje Vendor Lock-In niet aan de kant van Trust zit?

En is er daadwerkelijk een standaard voor dergelijke accessoires ja? Ik ben eerlijk gezegd niet overtuigd. Ja ik heb jouw voorbeelden gezien van NXP met daarin een beschrijving voor bijvoorbeeld een "Controller_ColorScene_Controller", maar betreft dit dan niet een standaard voor een controller die rechtstreeks de lamp aanstuurt, zoals bijvoorbeeld de producten van Busch Jaeger?

Ik ben niet op de hoogte van alle ZLL specificaties maar ik dacht dat het zat zoals @Erik1971 omschrijft:

Erik1971 schreef op donderdag 4 januari 2018 @ 19:30:
• ZLL Remote Controls/Dimmers en Sensoren, kunnen volgens ZLL specificatie alleen rechtstreeks met lampen communiceren, communicatie via Bridge is niet gespecificeerd
• Philips heeft naast standaard ZLL implementatie (anders zouden ze nooit zijn gecertificeerd) een uitbreiding gemaakt op ZigBee zodat Remotes en Sensors ook via de bridge kunnen werken, dit is inderdaad Philips specifiek, maar om dit Vendor lock te noemen is onzin, dan zou Philips niet mogen innoveren volgens jou

Erik1971 schreef op donderdag 4 januari 2018 @ 19:48:
ZLL ondersteund communicatie van Remotes/Switches/Sensoren via een bridge niet vanuit de specificatie, is een tekortkoming van ZLL specificatie en niet een Vendor Lock.

---

Grvy schreef op donderdag 4 januari 2018 @ 21:12:
Dus. Kijk naar wat het betekent. Kan je overstappen van HUE zonder financiële gevolgen? nee. Want de philips hue lampen doen het niet op een andere bridge etc; dus die zul je allemaal moeten vervangen.

Lampen kunnen juist prima door 3rd party hardware aangestuurd worden.

Andersom werken 3rd party lampen ook prima op de Hue bridge.

Het probleem hier betreft puur de accessoires. Doen andere merken het daar wel zoveel beter? Werkt een Trust schakelaar op een Tradfri hub?

[Erik1971]

Grvy schreef op donderdag 4 januari 2018 @ 21:12:
[...]


"Goed verhaal" want ik ben het met je eens. Dat is nog eens knap.

Philips en het hele hue systeem is gewoon een vendor lock-in.

[...]


Dus. Kijk naar wat het betekent. Kan je overstappen van HUE zonder financiële gevolgen? nee. Want de philips hue lampen doen het niet op een andere bridge etc; dus die zul je allemaal moeten vervangen.

Hu, hoe kom je daar nu bij? Dat Philips Hue lampen het alleen met een Hue bridge doen, zover ik weet doen ze het ook met onder andere Tradfri bridge?

Ja knap he dat ik het ook eens ben met mensen die wel weten waar ze het over hebben

[Grvy]

Ik weet niet hoor jongens, maar mijn lampen (van Philips ja) doen het niet op een Ikea bridge. EN daarnaast, okay dan doe ik dat misschien verkeerd; werken mijn Philips dimmers er dan op?

Er zijn financiële gevolgen, en dat is het enigste kenmerk voor een vendor lock in. Hoe je het dan ook draait.

[Xander]

Grvy schreef op donderdag 4 januari 2018 @ 21:19:
Ik weet niet hoor jongens, maar mijn lampen (van Philips ja) doen het niet op een Ikea bridge.

Ik kan het niet controleren (heb geen Ikea bridge), maar bij mijn weten zou dit gewoon moeten werken.

https://www.reddit.com/r/...also_be_paired_with_ikea/

EN daarnaast, okay dan doe ik dat misschien verkeerd; werken mijn Philips dimmers er dan op?

Nee. De Ikea bridge ondersteunt geen Philips accessoires. Vendor Lock-In! (van de Ikea bridge dan, als je het echt zo wilt noemen)

Volgens mij zou het wel mogelijk moeten zijn om een Philips dimmer te touchlinken rechtstreeks aan een Ikea lamp.

[Grvy]

Xander schreef op donderdag 4 januari 2018 @ 21:24:
[...]


Ik kan het niet controleren (heb geen Ikea bridge), maar bij mijn weten zou dit gewoon moeten werken.

https://www.reddit.com/r/...also_be_paired_with_ikea/
[afbeelding]


[...]

Nee. De Ikea bridge ondersteunt geen Philips accessoires. Vendor Lock-In! (van de Ikea bridge dan, als je het echt zo wilt noemen)

Volgens mij zou het wel mogelijk moeten zijn om een Philips dimmer te touchlinken rechtstreeks aan een Ikea lamp.

Ik zal eens kijken. of het lukt.

Maar, dus mijn dimmers doen het niet op een IKEA bridge? dus ik heb een "incentive" om bij Philips te blijven? of ik moet alle dimmers vervangen voor IKEA switches.. hmm.. kost wel geld.. dus ik denk dat ik dan maar bij Philips blijf.



Punt is; je kan het omdraaien hoe je wilt; als Philips echt een open systeem zou zijn, zouden IKEA die dimmers makkelijk integreren.

[ Voor 6% gewijzigd door Grvy op 04-01-2018 21:27 ]

[Erik1971]

Grvy schreef op donderdag 4 januari 2018 @ 21:19:
Ik weet niet hoor jongens, maar mijn lampen (van Philips ja) doen het niet op een Ikea bridge. EN daarnaast, okay dan doe ik dat misschien verkeerd; werken mijn Philips dimmers er dan op?

Er zijn financiële gevolgen, en dat is het enigste kenmerk voor een vendor lock in. Hoe je het dan ook draait.

Okay vervelend heb je al een keer op Tradfi forum gekeken voor een oplossing?

Zover ik weet kun je dezelfde methode gebruiken zoals je een Tradfri Lamp toevoegt en nu ik dit typ heb ik een vermoeden waarom het niet werkt....

Sinds de laatste sofware update van de Philips Hue lampen, van 14 november volgens de release notes, is er een security improvement uitgebracht en deze houd in dat je de lampen alleen de eerste 30 minuten na inschakelen kan touchlinken, wellicht heb je hier last van. Dus even spanning van de lampen af halen en dan touchlinken met Tradfri remote control om deze aan je Tradfri bridge toe te voegen.

Ik hoop dat het nu wel werkt.

Update: Zie dat je ook je Hue Dimmer Switches wilt toevoegen aan Tradfri, heb het zelf nog niet geprobeerd, maar je zou kunnen proberen om Hue Dimmer Switch te resetten, door reset knop achter op 10 seconden in gedrukt te houden, en vervolgens de Hue Dimmer Switch met je Tradfri Remote te touchlinken (I-knop Philips Hue Dimmer Switch ingedrukt houden, touchlinken begint pas na 10 seconden ).

[ Voor 16% gewijzigd door Erik1971 op 04-01-2018 21:35 ]

[Verwijderd]

Xander schreef op donderdag 4 januari 2018 @ 21:16:
Ik heb een ouderwetse Philips TV met daarbij een infrarood afstandsbediening. Dat werkt allemaal goed. Nu koop ik een infraroodafstandsbediening van Sony. En die werkt NIET.

Vendor Lock-In!!!!!111

Komop kerel. Verzin eens een realistisch voorbeeld. Dit is kinderachtig geneuzel, en dat weet je zelf ook wel.

Het juiste voorbeeld is: je koopt een philips TV en vervolgens een Sony 'videorecorder'. Beiden gebruiken ze de SCART standaard voor aansluiten. Toch werkt het niet. Om het wel te laten werken, moet je de scart kabel openmaken en er een stuk electronica in solderen.

JA. Dan is het een vendor lock.

Is die "trust ZLL Zigbee magnetische schakelaar" wel gemaakt om universeel met allerlei soorten Hubs te kunnen babbelen? Wie zegt dat het stukje Vendor Lock-In niet aan de kant van Trust zit?

Ja. Die gebruikt de ZLL standaard.

En is er daadwerkelijk een standaard voor dergelijke accessoires ja? Ik ben eerlijk gezegd niet overtuigd. Ja ik heb jouw voorbeelden gezien van NXP met daarin een beschrijving voor bijvoorbeeld een "Controller_ColorScene_Controller", maar betreft dit dan niet een standaard voor een controller die rechtstreeks de lamp aanstuurt, zoals bijvoorbeeld de producten van Busch Jaeger?

Nee. Dat is gewoon een generiek ZLL voorbeelddevice.

Lampen kunnen juist prima door 3rd party hardware aangestuurd worden.

Andersom werken 3rd party lampen ook prima op de Hue bridge.

Het probleem hier betreft puur de accessoires. Doen andere merken het daar wel zoveel beter? Werkt een Trust schakelaar op een Tradfri hub?

Klopt. Voor lampen is er geen vendor lock, zoals al herhaaldelijk aangegeven. Philips heeft wél getracht ook daar een vendor lock op te zetten (sterker nog, dat hebben ze zelfs gedaan), maar kreeg daar ZOVEEL kritiek op dat ze het er bij de volgende update weer uit gehaald hebben.

De Trust schakelaar werkt niet op een Tadfri hub, want die is óók vendor locked.

Daarom dat er een markt is voor een niet-vendor locked apparaat met een redelijke prijs. Ze zijn er wel al, maar dan betaal je al snel 400+ euro.

[meesje]

Negeren we nu bewust mijn Homekit opmerking? Tradfri, hue, en steeds meer andere produkten (het komt nu pas echt op gang) ondersteunen HomeKit. Je kunt dan toch niet meer spreken van een vendor lock-in?

Ik kan bijvoorbeeld met mijn Hue Tap middels Homekit een Elgato Eve Energy stekker direct aansturen?

Als we dus Homekit er bij betrekken dan is het toch einde discussie? Of zie ik nu nog wat over het hoofd? Dat kan hoor. Ik ben maar een eindgebruiker, jullie techneuten...

[Xander]

Verwijderd schreef op donderdag 4 januari 2018 @ 21:38:
[...]


Komop kerel. Verzin eens een realistisch voorbeeld. Dit is kinderachtig geneuzel, en dat weet je zelf ook wel.

Het juiste voorbeeld is: je koopt een philips TV en vervolgens een Sony 'videorecorder'. Beiden gebruiken ze de SCART standaard voor aansluiten.

Ja ehm, ik ben er dus niet van overtuigd dat er een standaard is voor schakelaars/sensors die met een bridge moeten communiceren. Ik ken de ZLL specificaties ook niet dus zelf kan ik er niet over oordelen.

Jij roept dat het bestaat, @Erik1971 roept van niet, beide zonder enige tastbare bron of bewijs. Maar jouw claim dat er een open standaard bestaat moet toch simpel te staven zijn met een linkje of...?

[Verwijderd]

Xander schreef op donderdag 4 januari 2018 @ 21:41:
[...]


Ja ehm, ik ben er dus niet van overtuigd dat er een standaard is voor schakelaars/sensors die met een bridge moeten communiceren. Ik ken de ZLL specificaties ook niet dus zelf kan ik er niet over oordelen.

Jij roept dat het bestaat, @Erik1971 roept van niet, beide zonder enige tastbare bron of bewijs. Maar jouw claim dat er een open standaard bestaat moet toch simpel te staven zijn met een linkje of...?

Die link had ik al lang gegeven? En ook Erik1971 betwist niet dat er een open standaard is, hoor.

Kunnen we verder gaan? Wat jullie nu doen, heet stoken. En daar leen ik mij niet voor. Lees maar eens terug als je wil zien waar het over gaat, want het staat er allemaal al, inclusief linkjes.

[Erik1971]

meesje schreef op donderdag 4 januari 2018 @ 21:41:
Negeren we nu bewust mijn Homekit opmerking? Tradfri, hue, en steeds meer andere produkten (het komt nu pas echt op gang) ondersteunen HomeKit. Je kunt dan toch niet meer spreken van een vendor lock-in?

Ik kan bijvoorbeeld met mijn Hue Tap middels Homekit een Elgato Eve Energy stekker direct aansturen?

Als we dus Homekit er bij betrekken dan is het toch einde discussie? Of zie ik nu nog wat over het hoofd? Dat kan hoor. Ik ben maar een eindgebruiker, jullie techneuten...

Je hebt een goed punt te pakken, maar je hebt ingeval van HomeKit nog wel een Tradfri bridge voor alle Tradfri producten nodig en een Philips Hue bridge nodig voor alle Hue producten.

Nu is dat zowel een nadeel, je hebt namelijk twee bridges nodig, maar ook een voordeel, Tradfri kan heel specifiek problemen voor Tradfri eco systeem oplossen en hetzelfde voor Philips.

Ik hoop/vermoed/staar in een glazen bol dat dit over een x aantal jaren door maar 1 bridge opgelost gaat worden, maar daar moeten de verschillende eco-systemen eerst nog een paar jaar maturen

[Hooglander1]

zeef schreef op donderdag 4 januari 2018 @ 15:48:
Ik krijg buiten eigen netwerk geen verbinding meer met mijn Hue bridge. Niet op android, niet op iOS. Het heeft een half jaar probleemloos gewerkt, maar nu niet meer. Moet ik een poort opengooien in Ziggo modem?

Nee, werkt hier prima op Ziggo.

[meesje]

Erik1971 schreef op donderdag 4 januari 2018 @ 21:47:
[...]

Je hebt een goed punt te pakken, maar je hebt ingeval van HomeKit nog wel een Tradfri bridge voor alle Tradfri producten nodig en een Philips Hue bridge nodig voor alle Hue producten.

Nu is dat zowel een nadeel, je hebt namelijk twee bridges nodig, maar ook een voordeel, Tradfri kan heel specifiek problemen voor Tradfri eco systeem oplossen en hetzelfde voor Philips.

Ik hoop/vermoed/staar in een glazen bol dat dit over een x aantal jaren door maar 1 bridge opgelost gaat worden, maar daar moeten de verschillende eco-systemen eerst nog een paar jaar maturen

Je hebt inderdaad wel altijd losse bridges nodig. Zelf lijkt me dat wel handig voor eventuele toekomstige firmware updates. Ik zie niet gebeuren dat mijn Hue lampen middels de Ikea bridge worden bijgewerkt....

Weer terug op de discussie (nogmaals zonder diepgaande technische kennis te hebben) over vendor lock-in. Dat past Philips dus eigenlijk niet (meer) toe. Ze maken het je middels homekit mogelijk om als b.v. 1 of 2 Hue lampen (van de tig anderen die je al hebt) stuk gaan om deze te vervangen door die van bijvoorbeeld Ikea. Je kunt vrij makkelijk en zonder extra kosten (de lamp moet je toch vervangen, of het nu hue of ikea is) je bestaande thuisautomatisering in stand houden.

Nu voor eens en altijd discussie gesloten? Laten we weer lekker over Hue praten. Of anders een vendor lock-in topic starten. Ik kan me voorstellen dat het niet plezierig is voor anderen om door veel discussie te bladeren voordat er weer leuke vragen, antwoorden, berichten, etc. te voorschijn komen.

Ik wil trouwens niet belerend overkomen, maar zelf vond ik het vervelend toen ik hier veel berichten over xiaomi of homebridge voorbij zag komen. Daar hebben we nu afzonderlijke topics voor.

[8-Track]

Erik1971 schreef op donderdag 4 januari 2018 @ 21:47:
[...]

Je hebt een goed punt te pakken, maar je hebt ingeval van HomeKit nog wel een Tradfri bridge voor alle Tradfri producten nodig en een Philips Hue bridge nodig voor alle Hue producten.

Nu is dat zowel een nadeel, je hebt namelijk twee bridges nodig, maar ook een voordeel, Tradfri kan heel specifiek problemen voor Tradfri eco systeem oplossen en hetzelfde voor Philips.

Ik hoop/vermoed/staar in een glazen bol dat dit over een x aantal jaren door maar 1 bridge opgelost gaat worden, maar daar moeten de verschillende eco-systemen eerst nog een paar jaar maturen

Het zet me wel aan het denken. Als Zigbee een open standaard zou zijn, zou in principe iedereen een generieke bridge moeten kunnen maken, zelfs als een stuk software dat ik op een Raspberry Pi zou moeten kunnen installeren. Vervolgens zou ieder apparaat dat zich aan de standaard houdt moeten kunnen praten met de bridge.

In plaats van een televisie/afstandbedinging/videorecorder vergelijking misschien een andere proberen: HTTP? Iedereen kan een webserver maken. Iedereen kan een browser maken. Het is bijvoorbeeld niet zo dat alleen browser X werkt met webserver Y. Of wat dacht je van 802.11a/b/n/ac: ieder client apparaat dat Wifi doet kan praten met router/base station XYZ. Misschien betere vergelijkingen?

[Erik1971]

Xander schreef op donderdag 4 januari 2018 @ 21:41:
[...]


Ja ehm, ik ben er dus niet van overtuigd dat er een standaard is voor schakelaars/sensors die met een bridge moeten communiceren. Ik ken de ZLL specificaties ook niet dus zelf kan ik er niet over oordelen.

Jij roept dat het bestaat, @Erik1971 roept van niet, beide zonder enige tastbare bron of bewijs. Maar jouw claim dat er een open standaard bestaat moet toch simpel te staven zijn met een linkje of...?

ZLL standaard beschrijft bijvoorbeeld hoe een remote zich dient te gedragen binnen ZigBee, dat wil zegen welke ZigBee commando's die moet ondersteunen.

Wat ZLL standaard niet beschrijft is hoe een ZLL remote via een bridge met je lampen moet communiceren, alleen maar hoe je rechtstreeks met een remote met een lamp kunt communiceren. Net zo goed als de specificatie ook niet beschrijft hoeveel knoppen je remote moet hebben, wat het ook lastig maakt om een standaard oplossing aan te bieden voor een bridge.

Vandaar de discussie over Vendor Lock of niet, en dat is maar net hoe je er naar kijkt.

Overigens zou je in theorie wel via je bridge een remote control of sensor kunnen toevoegen die vervolgens rechtstreeks met je lampen praat (na touch linken van de lampen met remote, vermoed dat Tradfri zoiets doet), maar dan zie deze normaal gesproken niet terug in de bridge of je moet de bridge naar de zelfde ZigBee group moeten laten luisteren waar de remote mee werkt, maar dit is allemaal niet beschreven binnen de standaard.

Als je een vergelijk zou moeten maken met een TV en afstandbediening, dan zou je moeten zien als Sony en Philips ondersteunen zelfde implementatie maar Philips heeft een extra knop toe gevoegd die rechtstreeks NetFlix applicatie start, maar met een Sony TV werkt deze knop niet, maar je kunt nog wel met Philips remote naar settings menu om daar op Sony TV NetFlix applicaite te starten.

[ Voor 12% gewijzigd door Erik1971 op 04-01-2018 22:43 ]

[Xander]

Verwijderd schreef op donderdag 4 januari 2018 @ 21:43:
[...]


Die link had ik al lang gegeven? En ook Erik1971 betwist niet dat er een open standaard is, hoor.

Ik moet blijkbaar wat uitgebreider opschrijven wat ik bedoel hier...

Natuurlijk betwist Erik1971 ook niet dat er een open standaard voor ZLL is. Ik bedoel: Een open standaard die beschrijft hoe een controller met een bridge zou moeten praten (i.t.t. een controller met een lamp).

Dat betwist hij wel:

Erik1971 schreef op donderdag 4 januari 2018 @ 19:30:
• ZLL Remote Controls/Dimmers en Sensoren, kunnen volgens ZLL specificatie alleen rechtstreeks met lampen communiceren, communicatie via Bridge is niet gespecificeerd

Erik1971 schreef op donderdag 4 januari 2018 @ 19:48:
ZLL ondersteund communicatie van Remotes/Switches/Sensoren via een bridge niet vanuit de specificatie, is een tekortkoming van ZLL specificatie en niet een Vendor Lock.

En sorry, maar dat sluit toevallig aan bij alles wat mij tot nu toe via diverse kanalen is wijsgemaakt over dit onderwerp. Vertegenwoordigers van Philips inclusief. Aangezien het dus niet bepaald de eerste keer is dat ik iets dergelijks hoor, ben ik geneigd om het te geloven.

Staat dit dan beschreven in die PDF die ik via jouw link kan downloaden? Heb je misschien nog een tip op welke van de 121 pagina's? Ik kan het er in ieder geval niet terugvinden, maar dat kan komen omdat ik van de helft niets snap.

Ik hoor hier gewoon twee tegenstrijdige meningen waarvan er toevallig één aansluit bij wat ik dacht te weten en de andere niet. Ik zie ook weinig concrete informatie die me eventueel over de streep zou kunnen trekken, anders dan "Ik verdien er mijn geld mee dus geloof me maar". Sorry maar dat doet het voor mij niet.

En verder boeit deze hele discussie me eigenlijk ook vrij weinig dus ik denk dat ik er ook maar eens mee op moet houden.

[mediumdry]

8-Track schreef op donderdag 4 januari 2018 @ 20:20:
Zie ik hem in de Hue app? Nee.
Kan ik hem gebruiken in mijn bestaande configuratie? Ja.
Zou ik het fijner vinden als ik mijn wandzender in de Hue app zou zien? Ach.
Is dat überhaupt technisch mogelijk? Geen idee!

Dat is mogelijk, sterker nog, dat is waar Homey, Domoticz en Home Assistant voor zijn. Het zou wel fijn zijn. Dat je een knop een functie geeft die afhankelijk is van randvoorwaarden als of het dag of nacht is. Of een bepaalde lamp aanstaat, of je tv. Of wat dan ook. Als een rook/koolmonoxide melder merkt dat het fout is, dat dan automatisch alle lampen op max sterkte aangaan.

Niet dat ik dat op dit moment nodig heb. Maar het lijkt me prettig als het in de Hue app (of app van welke gateway dan ook) dat mogelijk is. Dat is functionaliteit die ik liefst lokaal wil, zonder extra tussenstappen die alleen maar latency toevoegen.

[Verwijderd]

Xander schreef op donderdag 4 januari 2018 @ 22:11:
En sorry, maar dat sluit toevallig aan bij alles wat mij tot nu toe via diverse kanalen is wijsgemaakt over dit onderwerp. Vertegenwoordigers van Philips inclusief. Aangezien het dus niet bepaald de eerste keer is dat ik iets dergelijks hoor, ben ik geneigd om het te geloven.

Vertegenwoordigers zijn niet echt een goede bron van informatie.

Zigbee is een mesh netwerk. Dat wil zeggen dat er niet een centraal regelend iets is, of gespecificeerd. Dat is geen bug of tekortkoming, maar een gevolg van de topologie.

De 'bridge' is precies dat; een brug tussen het zigbee netwerk en iets anders. In dit geval de apps en de clouddienst.

De bridge doet geen dingen die niet in de ZLL spec staan. De schakelaars ook niet, zijn allemaal zll compliant devices. De genoemde magneetschakelaar ook.

Toch werkt die NIET met/via de bridge en met de apps. Terwijl dit wél gewoon gekund had. Dat is dus een vendor lock.

In het algemeen, verdiep je eens in ZLL en wat dat is. ZLL werkt met clusters van functionaliteiten. Een device kan in meerdere clusters zitten, en meerdere functies hebben. Zigbee is een mesh netwerk, dus bv. een lamp is niet alleen een 'endpoint lamp', maar ook een 'router device'. De Dimmerswitches van Philips zijn controller_colorscenecontroller devices. Als ik nu een collor_colorscenecontroller device pak van een andere fabrikant, zal het niet werken op de hub. Terwijl ze allemaal dezelfde (open) standaard volgen.

Dát is dus een vendor lock.

Het gaat daarin verder dan alleen maar 'philips heeft er voor gekozen de app alleen de clusters cq functionaliteiten van de eigen switches te laten ondersteunen'. Het is gewoon perfect mogelijk om een generieke schakelaar te maken, waarmee je in de app elke schakelaar kunt gebruiken, ongeacht merk. Juist omdat het aan een standaard voldoet. Dit is wél zo voor lampen. Dit hád ook zo kunnen zijn voor schakelaars. Heel simpel; de app zoekt apparaten met een bepaald (philips) type ID, met een bepaalde (philips) mac prefix, waaruit een 'uniqueid' wordt samengesteld. Dat kan dus alleen voor philips spullen. Had philips de check op een philips mac adres, vendor id en uniqueid weggelaten, dan had de 'dimmerswitch' uit de app gewoon gewerkt met dimmerswitches van een ander merk. Wellicht dat dat het wat duidelijker maakt; er zit in de broncode van de hub voor schakelaars een stuk code, wat kijkt of het wel een philips schakelaar is, en hem anders niet pakt. Dat is écht een vendor lock. Hoe lang je daar ook over praat.

Dat dat niet zo is voor schakelaars; is maar één reden voor. Philips wil het systeem zoveel mogelijk gesloten houden.

En hoe lang of kort we er ook over praten; geef je oma een setje met hub lampen en dimmer en ze krijgt het aan het werk. Geef haar een 3rd party schakelaar en ze krijgt het niet aan de praat. Dát is een vendor lock.

Dat slimme tweakers dan met scriptjes of bepaalde handelingen, zaken toch min of meer aan het werk kunnen krijgen (in de app zul je het nooit krijgen) doet daar niets aan af.

Kort door de bocht gezegd kun je zeggen, dat er in de philips app, voor bv. een schakelaar, de volgende code zit:

code:

if (manufacturer_id= 0x100b) then { work}  else { do not work } .

Die 0x100b = 4107 = het philips ID.

Zou je een schakelaar maken die EXACT dezelfde functionaliteiten en clusters etc aanbied als de Philips Dimmerswitch, dan zou je die NOG niet kunnen binden en zien in de hue app. Zuiver omdat de vendor_id niet van philips is.

Ik weet niet hoe duidelijker je een voorbeeld van een vendor lock precies wilt hebben?

[ Voor 18% gewijzigd door Verwijderd op 04-01-2018 22:45 ]

[PROnline]

Erik1971 schreef op woensdag 3 januari 2018 @ 23:39:
[...]

Oud nieuws, werk je soms voor een concurrent van Philips om hier onrust te zaaien , is bijna 1,5 jaar geleden toen dit bericht is gedeeld door Philips en het betrof maar een zeer klein aantal exemplaren,mag aannemen dat die nu onderhand wel zijn vervangen

ik ga me schamen in een klein hoekje. Ik zag 7 november staan en las even over de 2016 heen.

[Erik1971]

PROnline schreef op donderdag 4 januari 2018 @ 23:16:
[...]


ik ga me schamen in een klein hoekje. Ik zag 7 november staan en las even over de 2016 heen.

Het is je vergeven

[8-Track]

mediumdry schreef op donderdag 4 januari 2018 @ 22:34:
[...]

Niet dat ik dat op dit moment nodig heb. Maar het lijkt me prettig als het in de Hue app (of app van welke gateway dan ook) dat mogelijk is. Dat is functionaliteit die ik liefst lokaal wil, zonder extra tussenstappen die alleen maar latency toevoegen.

Ik vraag me af of je dat wel mag verwachten van een lampenfabrikant die probeert verlichting te verkopen dat ze een bridge maken die zulke veelomvattende functionaliteit heeft. Ik heb ook een tado thermostaat, met een bridge uiteraard, en daar verwacht ik dat soort functionaliteit ook niet van. Toch is het scenario dat je schetst wel degelijk mogelijk op bijvoorbeeld een Homekit niveau. Ik kan in Homekit regels maken als "als mijn Philips motion sensor beweging registreert zet dan mijn thermostaat op 21 graden, alleen na zonsondergang".

Overigens verbaas ik me over het latency aspect dat je steeds ter sprake brengt. Of het licht in mijn huis nu getriggerd wordt door een Hue Tap, een Philips bewegingssensor, een Busch-Jaeger zender, op de telefoon via de Hue app of via de Woning app van Apple, alles reageert vrijwel direct zonder merkbare (verschillen in) latency.

[Verwijderd]

Of je het mag verwachten, is een heel ander verhaal.

Vanuit Philips bekeken, is het naar mijn mening gewoon dom. Hardwarematig is de hub in staat om veel meer te zijn dan het nu is. Doordat er met een standaard gewerkt wordt waarin voor elke cluster gewoon gespecificeerd staat hoe/wat, hadden ze gewoon zonder meerwerk generieke schakelaars kunnen toestaan.

Doordat ze zich alleen beperken tot lampen van zichzelf en derden, en overige materiaal alleen van zichzelf, zijn mensen die écht iets willen op het gebied van home automation, nog steeds gedwongen andere apparatuur erbij te kopen. En als je dat tóch al gaat doen, waarom zou je dan nog 30+ euro gaan uitgeven voor een Philips Dimmerswitch, terwijl je voor 10 euro een prima werkende dimmerswitch van bv. xiaomi kunt kopen.

Dit soort protectionisme werkt gewoon niet. Dat wordt keer op keer bewezen.

Ik heb hier een JN5169 gebaseerde dimmerswitch liggen. Deze heb ik inmiddels zo ver dat hij als philips dimmerswitch op de hub en op de app bruikbaar is. Je ziet hem dan als dimmerswitch. Dit is werkende code, de hub weet niet beter of het IS een philips dimmer switch.

Als ik nu ALLEEN de vendor_id aanpas in de code (van Philips naar NXP bijvoorbeeld), dan werkt hij NIET meer.

[mediumdry]

8-Track schreef op donderdag 4 januari 2018 @ 23:21:
Ik vraag me af of je dat wel mag verwachten van een lampenfabrikant die probeert verlichting te verkopen dat ze een bridge maken die zulke veelomvattende functionaliteit heeft.

Ik begrijp dat vendoren niet veel willen investeren in de "extra" functionaliteit. Ik vind het ook prima als het van een andere vendor is. Daarom ben ik ook blij met open standaarden als zigbee en ZLL.

Ik heb ook een tado thermostaat, met een bridge uiteraard, en daar verwacht ik dat soort functionaliteit ook niet van. Toch is het scenario dat je schetst wel degelijk mogelijk op bijvoorbeeld een Homekit niveau. Ik kan in Homekit regels maken als "als mijn Philips motion sensor beweging registreert zet dan mijn thermostaat op 21 graden, alleen na zonsondergang".

Overigens verbaas ik me over het latency aspect dat je steeds ter sprake brengt. Of het licht in mijn huis nu getriggerd wordt door een Hue Tap, een Philips bewegingssensor, een Busch-Jaeger zender, op de telefoon via de Hue app of via de Woning app van Apple, alles reageert vrijwel direct zonder merkbare (verschillen in) latency.

Gaat homekit niet via de computers van Apple? Alle youtube filmpjes die ik zie waarin zaken gecombineerd worden is er vreselijke latency. Zoals ook jouw filmpje met je spot en siri (5+ seconden, als ik me herinner). Als ik Alexa gebruik dan is het een kleine 3 seconden, op het randje van acceptabel. Knoppen die direct met de lampen communiceren (zoals die van ikea of jouw BJs) gaan vrijwel instant. De Philips knoppen en apps die via de Hue Bridge gaan zijn ook snel genoeg nog, maar wel merkbaar langzamer al. Ik geloof dat ik er erg gevoelig voor ben. (gelukkig niet voor het "flikker" verhaal waar ik links en rechts over lees die verschillende led lampen zouden hebben)

Als homekit daar geen extra latency bovenop gooit (dus niet via de Apple servers gaat), dan moet ik daar toch eens verder naar gaan kijken. Er is alleen nog geen homekit skill voor Alexa.

Ik denk dat het uiteindelijk de richting op gaat dat er een standaard app of bridge zal komen die voorbij het "enthousiast" stadium is. (zie weer homey/domoticz/home assistant, die daar allemaal nog niet zijn) Homekit zou dat kunnen zijn, maar heeft weer andere nadelen.

[Verwijderd]

zeef schreef op donderdag 4 januari 2018 @ 15:48:
Ik krijg buiten eigen netwerk geen verbinding meer met mijn Hue bridge. Niet op android, niet op iOS. Het heeft een half jaar probleemloos gewerkt, maar nu niet meer. Moet ik een poort opengooien in Ziggo modem?

Kun je wel de webpagina van de hue bridge bezoeken op je eigen netwerk? Zo nee, controleer de bekabeling tussen je bridge en router.

[Verwijderd]

mediumdry schreef op vrijdag 5 januari 2018 @ 00:22:
latency

Latency komt meestal door verzadiging van de 2.4Ghz band. Het is een spread spectrum protocol, en zigbee deelt het frequentiegebied met wifi.

Zie hier de uitleg:
https://support.metageek....gBee-and-WiFi-Coexistence

Heb je last van latency met hue, is dat eigenlijk altijd aan één van twee zaken te wijten:
- inteferentie met wifi (ook bv. van buren etc). Dit kun je tweaken door te experimenteren met signalen van zowel wifi als zigbee
- teveel devices op één hub

De Philips hub kán in principe ook wifi, de hardware zit er in, en hij is ook wifi cetrified, maar dit hebben ze niet aangezet. Waarschijnlijk om dezelfde reden.

Ik merk zelf met 40+ devices op één hub nog weinig van latency. Soms via de app in een buitenhuis situatie, dat zal te maken hebben met de belasting op Philips' coud service.

Wat ik wel merk, is dat heel soms (zeg 1 keer per 100 keer drukken) een commando niet overkomt en je nog eens moet drukken. Soit.

[ Voor 10% gewijzigd door Verwijderd op 05-01-2018 00:35 ]

[Exorcist]

Ik heb er al even op gezocht, maar:

vannacht hebben we (meermaals zo (b)lijkt) een stroomonderbreking gehad in het dorp. Kom ik net beneden en alle lampen op max. sterkte aan. Dit vind ik onprettig i.v.m. evt. afwezigheid als zoiets nogmaals voorkomt. Nu lees ik dit hier bij meerdere mensen en dat het dus geen standaard setting is en dit alleen met wat kunst- en vliegwerk "op te lossen" is. Het lijkt me toch basisfunctionaliteit welke ontbreekt..

Heb het overigens vaker meegemaakt maar dat is door eigen toedoen geweest (stekkerblokken met draadloze schakelaar inschakelen die de piekbelasting overschrijden) en ik dus gelijk weer de lampen kon corrigeren.

[zeef]

Xander schreef op donderdag 4 januari 2018 @ 20:54:
[...]

Communicatie gaat via Hue servers, je hebt er geen port forwarding voor nodig.

Is je bridge nog wel gekoppeld aan je Hue account? Op https://account.meethue.com/bridge

Ja

Kun je op https://my.meethue.com/ de boel wel bedienen?

Ja

Anders zou ik eerst de bridge eens een reboot geven als je dat nog niet geprobeerd hebt.

gedaan, geen oplossing.

Verwijderd schreef op vrijdag 5 januari 2018 @ 00:30:
[...]


Kun je wel de webpagina van de hue bridge bezoeken op je eigen netwerk? Zo nee, controleer de bekabeling tussen je bridge en router.

Ja, kan.

[ Voor 21% gewijzigd door zeef op 05-01-2018 08:20 ]

[Will_M]

zeef schreef op vrijdag 5 januari 2018 @ 08:20:
[...]
Ja
[...]
Ja
[...]
gedaan, geen oplossing.

[...]

Ja, kan.

Heeft de HUE Bridge misschien een ander IP Adres gekeregen in je privé netwerk thuis, óf heeft je router een ander adres van Ziggo gekregen? Mijn ervaring is dat je die HUE Bridge(s) het best op DHCP kunt laten staan met een reserrvering in de DHCP scope van je DHCP server.

Ik bedien die dingen (3 stuks! hier) overigens, van buiten m'n eigen netwerk, niet middels de "MeetHUE" omgeving maar middels Apple Homekit (Ik heb ook géén account(s) bij My HUE omdat ik die extra afhankelijkheid naar Philips niet (meer) wil hebben. Been There, Done That ....Got the T-Shirt. Jaren geleden (10?) tot 2 keer toe onder garantie een nieuw moederbord in een Philips TV gekregen omdat NET-TV niet wilde werken. Achteraf bleek dat m'n firewall verkeer naar/van een paar "vreemde" IP adressen van Philips "dropte" waarbij die adressen hard-coded in de firmware van de TV zaten (niet ééns als FQDN maar als keihard IP-v4 adres.... ).

[ Voor 12% gewijzigd door Will_M op 05-01-2018 09:08 ]

[GewoonDennis]

8-Track schreef op donderdag 4 januari 2018 @ 16:09:
[...]

Voor iOS is er de Hue Lights app, waarmee je de bridge in Touchlink mode kan zetten. Daarmee heb ik mijn BJ dimmers en wandzenders aan het netwerk toegevoegd, en zo zal ik het dus ook moeten doen met de IKEA lampen...

Ikea lampen met goeie firmware (batchnr 1725 en hoger) is gewoon plug and play. Indraaien en op app op zoeken klikken.

[aawe mwan]

Exorcist schreef op vrijdag 5 januari 2018 @ 07:24:
Ik heb er al even op gezocht, maar:

... er staat geen vraagteken in je verhaal.

Maar erg vervelend inderdaad. Ik zie ook hier in de stad af en toe dat in woningen dag en nacht de lampen aan zijn, voor weken lang. De elektriciteit gaat om centen, maar iedereen ziet dat er niemand thuis is.

Wat je kunt doen is bijvoorbeeld je internetrouter zo instellen dat die een e-mailtje naar je verstuurt zodra de router opnieuw opgestart is en er weer internetconnectiviteit is. Als je niet thuis bent, dan lees je dat mailtje op je mobiele telefoon en kan je met behulp van de Hue app alle lampen brengen in de stand waarin je ze op dat moment wilt hebben.

Je kunt ook Ikea Trådfri lampen gebruiken. Na een stroomonderbreking komen die niet terug in volle helderheid, maar in de helderheid die je gebruikt hebt vlak voordat je ze uit zette. Dat is al een stuk beter.

Iets wat je ook nu al zelf kunt doen, is je bridge zo instellen dat de lampen in elk geval op bepaalde tijdstippen uit gaan (zijn de lampen al uit, dan verandert er niets).

Ik heb trouwens het omgekeerde probleem ook: apparaten die aangesloten zijn via een schakelbaar stopcontact om ze remote te kunnen resetten, gaan na een stroomonderbreking niet automatisch aan.
(De standaard Tweaker oplossing zou natuurlijk zijn om een UPS aan te schaffen.)

Behalve de Hue bridge heb ik ook nog systemen van andere merken. Ik heb een Chinese Zigbee bridge en daarin is het zo opgelost dat ze je een pushmelding op je mobiele telefoon sturen als je „vergeten” bent om een lamp uit te doen. Verder heb ik tussenstekkers van Fritz en deze zijn instelbaar: ik heb ze zo ingesteld dat ze na een stroomuitval teruggaan naar de stand van vlak voor de stroomuitval.

[mucuracat]

@Verwijderd

Kun je geen app bouwen voor ons??

[Exorcist]

aawe mwan schreef op vrijdag 5 januari 2018 @ 08:34:
[...]


.
Iets wat je ook nu al zelf kunt doen, is je bridge zo instellen dat de lampen in elk geval op bepaalde tijdstippen uit gaan (zijn de lampen al uit, dan verandert er niets).

Dit staat op zich al ingesteld (aan bij schemering, uit als we op bed liggen en in de ochtend aan bij ontwaken en uit bij verlaten huis), maar dan denk ik dat een extra schematische instelling inderdaad nodig is midden in de nacht "uit om ...." voor de zekerheid. Want met die felle verlichting landt er nog net geen vliegtuig in je achtertuin.

[Jos-P]

Zo heb ik dat inderdaad ook opgelost. Alle kamers uit om 03.00 uur.

[wim-vdv]

Exorcist schreef op vrijdag 5 januari 2018 @ 08:45:
[...]


Dit staat op zich al ingesteld (aan bij schemering, uit als we op bed liggen en in de ochtend aan bij ontwaken en uit bij verlaten huis), maar dan denk ik dat een extra schematische instelling inderdaad nodig is midden in de nacht "uit om ...." voor de zekerheid. Want met die felle verlichting landt er nog net geen vliegtuig in je achtertuin.

Midden in de nacht zal ik nooit alle lampen tegelijk aan hebben, dus ik heb een regel aangemaakt dat tussen 01:00 en 06:00, als alle lampen aanstaan, ze dan worden uitgezet. (En ook een tweede regel die hetzelfde doet tussen 10:00 en 16:00).

[xxxneoxxx]

Same here. Gewoon een regel aangemaakt, als er om 3 uur snachts nog iets aanstaat, gewoon uitzetten. Sluit ook mooi aan op de "zet lampen woonkamer aan bij zonsondergang" regel. Als je dus op vakantie bent, staan niet 24x7 je lampen aan, en vanwege het feit dat ze aan en weer uitgaan, is het alsof er alsnog iemand thuis is.

zeef schreef op vrijdag 5 januari 2018 @ 08:20:
[...]
Ja
[...]
Ja
[...]
gedaan, geen oplossing.

[...]

Ja, kan.

Hier een zelfde soort issue gehad. Heel lullig, maar na verloop van tijd kwam ik erachter dat ik meer apparaten in huis niet meer kon benaderen na een reboot. De bridge had hier overigens het meeste last van om een of andere reden. Allicht dat deze zichzelf af en toe reboot? Probeer je het ding te benaderen op ip adres, kom je er niet meer bij. Met een beetje kunst en vliegwerk erachter gekomen dat de Horizon box in mijn geval de boosdoener was. Dat lelijke ding kan ook fungeren als DHCP server schijnbaar en zat dus lekker in dezelfde reeks, heel soms, lekker zelf ip adressen uit ter delen aan apparaten. Ander subnet erbij.. Paar keer geprobeerd de configuratie aan te passen van de horizon box maar die Horizon box is qua instellingen zo ontransparant als het maar zijn kan. Uiteindelijk netwerkstekker aan de achterkant er maar uitgehaald omdat alles qua netwerksettings en DHCP server uit stond, maar het ding toch ip adressen uit bleef delen.. Kon ie ook direct op energiezuinige modus.

Bottomline: Als je bridge dus *ergens* vandaan opeens een ander ip adres aangeboden krijgt, dan gaat van buitenaf connecten dus ook niet meer werken. Noteer dus het IP adres van je bridge en dubbelcheck deze nadat je er een keer niet bij kan. Het IP addy reserveren op je router kan inderdaad ook geen kwaad. Verder hier ook niets nodig qua port forwarding om er van buitenaf bij te kunnen.

[El Martino]

zeef schreef op vrijdag 5 januari 2018 @ 08:20:
[...]
Ja
[...]
Ja
[...]
gedaan, geen oplossing.

[...]

Ja, kan.

Ik heb sinds kort precies hetzelfde probleem, via iOS. Heb thuis KPN. Via de webbrowser werkt het wel goed, maar helaas niet meer via de Hue App.

[edit]
Raaarrr.... Net nog even gecontroleerd in de app, en blijkbaar was ik 'spontaan' uitgelogd bij "Mijn Hue". Net weer ingelogd en alles werkt zoals het zou moeten.

[ Voor 20% gewijzigd door El Martino op 05-01-2018 10:04 ]

[mediumdry]

Verwijderd schreef op vrijdag 5 januari 2018 @ 00:35:
Latency komt meestal door verzadiging van de 2.4Ghz band. Het is een spread spectrum protocol, en zigbee deelt het frequentiegebied met wifi.

...

Heb je last van latency met hue, is dat eigenlijk altijd aan één van twee zaken te wijten:
- inteferentie met wifi (ook bv. van buren etc). Dit kun je tweaken door te experimenteren met signalen van zowel wifi als zigbee
- teveel devices op één hub

Ik heb niet heel veel devices en, hoewel er in mijn flat veel 2,4Ghz netwerken zijn, geen last van interferentie latency. Als dat zo was, dan zou het varieren.

-Directe verbindingen zijn prima
-Verbindingen via de bridge zijn iets langzamer, maar nog altijd vrijwel direct
-via Alexa (retourtje Amazon servers en spraakherkenning) heeft wat latency

Ieder radertje dat je extra in de keten zet zal extra latency toevoegen. Ik heb al eens een hele set lampen vervangen omdat ze pas na een seconde aansprongen (oude leds). Ik ben er gevoelig voor, dus wil niet graag een oplossing met veel stappen in een keten, zeker niet als het dan zelfs via een externe cloud gaat (zoals IFTTT).

Het gaat me om toegevoegde latency van een keten, niet van de laatste stap naar de lamp.

[zeef]

wimmel_1 schreef op vrijdag 5 januari 2018 @ 08:29:
[...]


Heeft de HUE Bridge misschien een ander IP Adres gekeregen in je privé netwerk thuis, óf heeft je router een ander adres van Ziggo gekregen? Mijn ervaring is dat je die HUE Bridge(s) het best op DHCP kunt laten staan met een reserrvering in de DHCP scope van je DHCP server.

Ik bedien die dingen (3 stuks! hier) overigens, van buiten m'n eigen netwerk, niet middels de "MeetHUE" omgeving maar middels Apple Homekit (Ik heb ook géén account(s) bij My HUE omdat ik die extra afhankelijkheid naar Philips niet (meer) wil hebben. Been There, Done That ....Got the T-Shirt. Jaren geleden (10?) tot 2 keer toe onder garantie een nieuw moederbord in een Philips TV gekregen omdat NET-TV niet wilde werken. Achteraf bleek dat m'n firewall verkeer naar/van een paar "vreemde" IP adressen van Philips "dropte" waarbij die adressen hard-coded in de firmware van de TV zaten (niet ééns als FQDN maar als keihard IP-v4 adres.... ).

Homekit werkt wel. Dat loopt natuurlijk via de lokale ATV.

Heb de bridge gereset: no joy

[enbroerse]

Ik ben een beginnend hue gebruiker. We hebben meerdere lampen en motion sensoren.

Ik heb de philips hue app en all4hue.

Ik zou graag ergens aanwillen zetten dat mijn motion sensoren een groen lichtje geven als ze beweging detecteren. Is dat met de all4hue app in te stellen?

[CWH]

Kan iemand mij vertellen wat de maximale detectieafstand is van de Hue bewegingsmelder?

[meesje]

CWH schreef op vrijdag 5 januari 2018 @ 12:09:
Kan iemand mij vertellen wat de maximale detectieafstand is van de Hue bewegingsmelder?

Graag de volgende keer even wat meer je best doen voordat je een vraag stelt!
In google heb ik het volgende ingeven: hue motion sensor afstand
Vrijwel direct zie je een link van de consumentenbond: reikwijdte 5 meter.
Daaronder een artikel van icultere met dezelf info.

[robkrekel]

Ik vermoed dat het in de praktijk vaak zelfs meer is. Anders heb ik geen verklaring waarom de scene in mijn open keuken af en toe veranderd zonder dat ik binnen de 5 meter van de sensor kom. Ik ga heb dan ook (weer) verplaatsen, kijken of ie het ergens anders beter doet (als in, minder snel detecteert). Nu heb ik gevoeligheid (?) op max staat, dat zal ook vast schelen.

[Xander]

zeef schreef op vrijdag 5 januari 2018 @ 08:20:
[...]
Ja
[...]
Ja

Apart. Via https://my.meethue.com/ bedien je de boel ook "van buitenshuis"?? Heel raar dat dit wel werkt en de app niet.

Je hebt dit ook al gecontroleerd:

El Martino schreef op vrijdag 5 januari 2018 @ 09:47:
[...]

Raaarrr.... Net nog even gecontroleerd in de app, en blijkbaar was ik 'spontaan' uitgelogd bij "Mijn Hue". Net weer ingelogd en alles werkt zoals het zou moeten.

?

Anders zou ik het ook niet weten

[arjandijk162]

**niet een heel nuttige toevoeging

[ Voor 96% gewijzigd door arjandijk162 op 05-01-2018 13:24 ]

[Sunri5e]

Gister 4 G10 Tradfri lampjes van 14 euro bij de Ikea gehaald en aangesloten op mijn Hue Bridge. Had het even wat voeten in aarde maar het werkt perfect.

[CWH]

meesje schreef op vrijdag 5 januari 2018 @ 12:14:
[...]

Graag de volgende keer even wat meer je best doen voordat je een vraag stelt!
In google heb ik het volgende ingeven: hue motion sensor afstand
Vrijwel direct zie je een link van de consumentenbond: reikwijdte 5 meter.
Daaronder een artikel van icultere met dezelf info.

Ik had idd alleen op de produktpagina van Philips gekeken, daar stond het niet bij waarbij ik er ervan uit ging dat het geen algemeen gegeven was. Excuses, maar toch bedankt voor de info!

[meesje]

CWH schreef op vrijdag 5 januari 2018 @ 13:52:
[...]


Ik had idd alleen op de produktpagina van Philips gekeken, daar stond het niet bij waarbij ik er ervan uit ging dat het geen algemeen gegeven was. Excuses, maar toch bedankt voor de info!

Geen probleem. Maar inderdaad de info op de pagina van Philips is wel summier (100 graden en 5 meter ontbreekt).

[Dennis van der Stelt]

Vraag : Ik had iemand met Scratch / Blocks een routine zien bouwen om lichtjes aan / uit te zetten. Kan me niet herinneren of dat hier was. Was volgens mij Domoticz of iets dergelijks. Is wel gaaf, want dan kan m'n zoon van 11 lekker aan de gang ermee.

Weet iemand hoe je dat moet realiseren met Scratch?

[zeef]

Xander schreef op vrijdag 5 januari 2018 @ 13:20:

Je hebt dit ook al gecontroleerd:

[...]

?

Anders zou ik het ook niet weten

Dat was 'm. Uitgelogd, nieuw wachtwoord ingesteld. Inloggen en it works. Woei!

[Sunri5e]

Zijn er nog leuke apps op de markt die bijvoorbeeld een zonsondergang of opkomst simuleren?

[Civic09]

Heb deze week mijn Hue setje (2 kleurenlampen met bridge) binnen gekregen en behoorlijk enthousiast. Kan ik nu ook eenvoudig Ikea lampen koppelen of moet ik daar eerst ook een Ikea bridge voor aanschaffen?

[Sunri5e]

Civic09 schreef op vrijdag 5 januari 2018 @ 14:16:
Heb deze week mijn Hue setje (2 kleurenlampen met bridge) binnen gekregen en behoorlijk enthousiast. Kan ik nu ook eenvoudig Ikea lampen koppelen of moet ik daar eerst ook een Ikea bridge voor aanschaffen?

Ik heb gister hetzelfde gedaan. Het kost even wat tijd en wat tutorials lezen/kijken maar het is goed te doen en het functioneert prima. Je merkt het verschil niet tussen Hue lampen en die van de Ikea.

[mediumdry]

Hue lampen kunnen wat donkerder dimmen dan de Ikea lampen.

[Sunri5e]

mediumdry schreef op vrijdag 5 januari 2018 @ 14:29:
Hue lampen kunnen wat donkerder dimmen dan de Ikea lampen.

Oke, ik zie het verschil bij die van mij niet. Wellicht zit er nog verschil tussen de lampen van 7 en 14 euro?

[arjandijk162]

robkrekel schreef op vrijdag 5 januari 2018 @ 12:21:
Ik vermoed dat het in de praktijk vaak zelfs meer is. Anders heb ik geen verklaring waarom de scene in mijn open keuken af en toe veranderd zonder dat ik binnen de 5 meter van de sensor kom. Ik ga heb dan ook (weer) verplaatsen, kijken of ie het ergens anders beter doet (als in, minder snel detecteert). Nu heb ik gevoeligheid (?) op max staat, dat zal ook vast schelen.

Gegevens zijn gelijk aan Ikea sensor. Praktijk is ander. Hue komt veel verder

[mediumdry]

Sunri5e schreef op vrijdag 5 januari 2018 @ 14:46:
[...]
Oke, ik zie het verschil bij die van mij niet. Wellicht zit er nog verschil tussen de lampen van 7 en 14 euro?

Ik heb het verschil gezien bij de E27 lampen, wellicht dat de GU-10 anders is...

[Will_M]

Sunri5e schreef op vrijdag 5 januari 2018 @ 14:14:
Zijn er nog leuke apps op de markt die bijvoorbeeld een zonsondergang of opkomst simuleren?

Heb je al eens bij HUE Labs gekeken? Middels de HUE Bridge i.c.m. HUE Lab's is vaak véél meer mogelijk dan dat er standaard mogelijk lijkt

[meesje]

Sunri5e schreef op vrijdag 5 januari 2018 @ 14:14:
Zijn er nog leuke apps op de markt die bijvoorbeeld een zonsondergang of opkomst simuleren?

Indien je ook gebruik maakt van iOS (iphone/ipad) kun je ook kijken naar HomeKit. Daarin kun je regels maken n.a.v. sunrise en sunset.

[pixels66]

Ben ik nu serieus de enige die problemen heeft met de motion sensor? Die heb ik ingesteld dat deze vanaf 17.00 actief wordt, maar vaak staat voor die tijd mijn verlichting in de gang al aan, omdat de daglicht sensor dat blijkbaar nodig acht(te donker)... Om debiel van te worden..

[KoenCows]

pixels66 schreef op vrijdag 5 januari 2018 @ 17:14:
Ben ik nu serieus de enige die problemen heeft met de motion sensor? Die heb ik ingesteld dat deze vanaf 17.00 actief wordt, maar vaak staat voor die tijd mijn verlichting in de gang al aan, omdat de daglicht sensor dat blijkbaar nodig acht(te donker)... Om debiel van te worden..

Heb je al geprobeerd de daglicht sensitiviteit van de sensor bij te stellen? Kan bij de settings onderaan.

[pixels66]

KoenCows schreef op vrijdag 5 januari 2018 @ 17:19:
[...]


Heb je al geprobeerd de daglicht sensitiviteit van de sensor bij te stellen? Kan bij de settings onderaan.

Ja, dit heb ik op verschillende daglicht momenten gedaan, ik schuif deze dan telkens helemaal naar beneden en druk dan op bewaar...
Resultaatloos helaas..

[Will_M]

pixels66 schreef op vrijdag 5 januari 2018 @ 17:14:
Ben ik nu serieus de enige die problemen heeft met de motion sensor? Die heb ik ingesteld dat deze vanaf 17.00 actief wordt, maar vaak staat voor die tijd mijn verlichting in de gang al aan, omdat de daglicht sensor dat blijkbaar nodig acht(te donker)... Om debiel van te worden..

Ik heb hier 7 van die dingen in gebruik en heb er écht totaal géén issues mee. Misschien dat je die HUE Sensor eens een keer kunt verwijderden en daarna nog eens kijkt of het toevallig niet iets anders (rule / routine) is wat je lampen "automagisch" inschakelt (dus zónder die sensor weer opnieuw te koppelen)?

@meesje : Ik had hier gisteren een "Klik-Graag" neefje over de vloer en had dus al m'n iPad's al vér buiten bereik van 't (overigens érg lieve) manneke opgeborgen.... Helaas wist 'ie de HUE Tap voor amper 10 seconden met z'n tengels te beroeren..... Gevolg: HUE Tap ineens spoorloos verdwenen in m'n Apple Homekit én in de HUE App....

Met 3 HUE Bridges direct langs elkaar in de meterkast is het vervolgens weer géén sinecure om dat ding weer gevonden én gekoppeld te hunnen krijgen aan de "meést dichtstbijzijnde" HUE Bridge (twee HUE Bridges van de stroom af moeten pakken om 'm weer gekoppeld te kunnen krijgen aan de "juiste" HUE Bridge) en dat wilde ook alleen maar werken als ik mét het ding op een halve meter van die nog bereikbare HUE Bridge verwijderd was.

Ik ben benieuwd hoe datzelfde "spel" zich ooit gaat openbaren als je buren ook een HUE Bridge aan durven te schaffen (hier gelukkig geen last van)... Je moet dan waarschijnlijk gaan vragen of ze hún systeem even willen uitschakelen ofzo, en dan mag je nog maar hopen dat je het element niet in een wandschakelaar weggewerkt hebt

[ Voor 45% gewijzigd door Will_M op 05-01-2018 17:53 ]

[dragon2]

pixels66 schreef op vrijdag 5 januari 2018 @ 17:14:
Ben ik nu serieus de enige die problemen heeft met de motion sensor? Die heb ik ingesteld dat deze vanaf 17.00 actief wordt, maar vaak staat voor die tijd mijn verlichting in de gang al aan, omdat de daglicht sensor dat blijkbaar nodig acht(te donker)... Om debiel van te worden..

Zoals eerder aangegeven, die motionsensor zou gewoon niets moeten doen voor 17:00 uur, als je dat niet wil. "Do nothing" dus, ipv "zet een scene indien beweging+te donker". En als hij dan nog steeds aangaat voor 17:00 dan komt dat ergens anders door, een timer ofzo.

Hoe heb je dat "ingesteld dat deze vanaf 17.00 actief wordt" nou precies ingeregeld dan?
Dit zou goed moeten werken namelijk:

[ Voor 7% gewijzigd door dragon2 op 05-01-2018 18:28 ]

[Ethirty]

wimmel_1 schreef op vrijdag 5 januari 2018 @ 17:26:
[...]


Ik heb hier 7 van die dingen in gebruik en heb er écht totaal géén issues mee. Misschien dat je die HUE Sensor eens een keer kunt verwijderden en daarna nog eens kijkt of het toevallig niet iets anders (rule / routine) is wat je lampen "automagisch" inschakelt (dus zónder die sensor weer opnieuw te koppelen)?

@meesje : Ik had hier gisteren een "Klik-Graag" neefje over de vloer en had dus al m'n iPad's al vér buiten bereik van 't (overigens érg lieve) manneke opgeborgen.... Helaas wist 'ie de HUE Tap voor amper 10 seconden met z'n tengels te beroeren..... Gevolg: HUE Tap ineens spoorloos verdwenen in m'n Apple Homekit én in de HUE App....

Met 3 HUE Bridges direct langs elkaar in de meterkast is het vervolgens weer géén sinecure om dat ding weer gevonden én gekoppeld te hunnen krijgen aan de "meést dichtstbijzijnde" HUE Bridge (twee HUE Bridges van de stroom af moeten pakken om 'm weer gekoppeld te kunnen krijgen aan de "juiste" HUE Bridge) en dat wilde ook alleen maar werken als ik mét het ding op een halve meter van die nog bereikbare HUE Bridge verwijderd was.

Ik ben benieuwd hoe datzelfde "spel" zich ooit gaat openbaren als je buren ook een HUE Bridge aan durven te schaffen (hier gelukkig geen last van)... Je moet dan waarschijnlijk gaan vragen of ze hún systeem even willen uitschakelen ofzo, en dan mag je nog maar hopen dat je het element niet in een wandschakelaar weggewerkt hebt

Als je de Tap 10s ingedrukt houdt verdwijnt hij inderdaad uit de app, maar opnieuw toevoegen is mij tot nu toe altijd makkelijk gelukt. Apparaat toevoegen, tap indrukken en klaar. De Tap is nog wel bekend in het systeem, dus alles werkt daarna weer als vanouds.

Als jij daadwerkelijk 3 bridges hebt, zou ik maar eens gaan labelen wat bij welke bridge hoort.

[Verwijderd]

mucuracat schreef op vrijdag 5 januari 2018 @ 08:41:
@Verwijderd

Kun je geen app bouwen voor ons??

Nee, nooit. Apps (als in: een native app voor een telefoon) is een gigantische doodlopende straat. Alleen goed voor spelletjes, verder niet.

Als ik uberhaupt al zelf iets ga bouwen, anders dan gewoon reeds bestaande spullen combineren tot een off-the-shelf open source open product, dan wordt dat iets wat een responsive website serveert, en dus ook werkt op een mobiel.

Als app komt er dan hooguit een 'verpakte browser'.

[Will_M]

Ethirty schreef op vrijdag 5 januari 2018 @ 18:37:
[...]

Als je de Tap 10s ingedrukt houdt verdwijnt hij inderdaad uit de app, maar opnieuw toevoegen is mij tot nu toe altijd makkelijk gelukt. Apparaat toevoegen, tap indrukken en klaar. De Tap is nog wel bekend in het systeem, dus alles werkt daarna weer als vanouds.

Als jij daadwerkelijk 3 bridges hebt, zou ik maar eens gaan labelen wat bij welke bridge hoort.

Ik heb hier ná dat geneuzel van laatst (té veel accessoires / rules op één bridge) de hele config hier thuis op de schop gegooid en dus ook m'n lampen opnieuw mogen verdelen over 3 HUE Bridges. De HUE Lampen wéten echter daarna nog steeds aan welke HUE Bridge ze gekoppeld hebben gezeten dus je kunt ze niet "zomaar' even van de éne naar de andere HUE Bridge over zetten (allemaal V2.0 / V2.1 Bridges). Ik heb dus ALLE lampen mogen demonteren (± 50 stuks) én ze allemaal op serienummer weer mogen toevoegen aan de juiste HUE Bridge, waarbij ik nu een onderscheid gemaakt heb in de woonlagen van m'n woning.

Uiteraard heb ik nú een méér dan complete Microssoft Exelsheet met MAC Adressen / S/N's / namen / BRIDGE koppelingen (MS SQL Database was een béétje OVERKILL, vond ik )..... Dus documentatie waarin alle gegevens bekend zijn zodat ik de volgende keer niet wéér al m'n lampen hoef te gaan demonteren (vooral de badkamerspiegel was even "K*T" omdat de "Driver" van de LEDstrip Puls redelijk goed IP44 waterproof gemaakt is én juist daar dus het S/N op staat).

Het enige wat ik gelabeld heb: De HUE Bridges vanwege 't feit dat ze alle 3 langs elkaar in de meterkast hangen, maar ook die krijgen middels een IP reservering in de DHCP scope een "statisch" adres toegekend zodat ik ook die dingen niet meer "kwijt" raak.

[ Voor 7% gewijzigd door Will_M op 05-01-2018 19:23 ]

[Verwijderd]

mediumdry schreef op vrijdag 5 januari 2018 @ 10:11:
-Directe verbindingen zijn prima
-Verbindingen via de bridge zijn iets langzamer, maar nog altijd vrijwel direct
-via Alexa (retourtje Amazon servers en spraakherkenning) heeft wat latency

Ieder radertje dat je extra in de keten zet zal extra latency toevoegen. Ik heb al eens een hele set lampen vervangen omdat ze pas na een seconde aansprongen (oude leds). Ik ben er gevoelig voor, dus wil niet graag een oplossing met veel stappen in een keten, zeker niet als het dan zelfs via een externe cloud gaat (zoals IFTTT).

Het gaat me om toegevoegde latency van een keten, niet van de laatste stap naar de lamp.

Wat er misgaat in je redenatie, is het idee dat je, zonder bridge, DIRECT een lamp bediend. Dit is namelijk helemaal geen vaststaand feit. Zigbee is een mesh netwerk. De kans is groot dat je VIA de dichtsbijzijnde lamp, de lamp bediend die je wil hebben.

Met alle respect, als je al lampen gaat vervangen omdat je denkt dat de latency 'in' de lampen zit, dat is van een hoog aluhoedjes niveau. Ik denk dat dan de latency een psychosomatisch iets geworden is.

[Will_M]

Verwijderd schreef op vrijdag 5 januari 2018 @ 18:58:
[...]


Wat er misgaat in je redenatie, is het idee dat je, zonder bridge, DIRECT een lamp bediend. Dit is namelijk helemaal geen vaststaand feit. Zigbee is een mesh netwerk. De kans is groot dat je VIA de dichtsbijzijnde lamp, de lamp bediend die je wil hebben.

Met alle respect, als je al lampen gaat vervangen omdat je denkt dat de latency 'in' de lampen zit, dat is van een hoog aluhoedjes niveau. Ik denk dat dan de latency een psychosomatisch iets geworden is.

Zelfs met "te véél" accessoires / rules heb je absoluut géén last van latency. Ik schakel hier vrij veel middels Apple Homekit (Siri) en zelfs Siri had niet in de gaten dat sommige HUE accesoires er ooit niet meer waren in de HUE Bridge (tot ná een resync).

[meesje]

pixels66 schreef op vrijdag 5 januari 2018 @ 17:14:
Ben ik nu serieus de enige die problemen heeft met de motion sensor? Die heb ik ingesteld dat deze vanaf 17.00 actief wordt, maar vaak staat voor die tijd mijn verlichting in de gang al aan, omdat de daglicht sensor dat blijkbaar nodig acht(te donker)... Om debiel van te worden..

Ik heb de motion sensor via HomeKit geconfigureerd: bij beweging na 16.30 dan lampen aan. Heb je toevallig ook HomeKit dan kun je het via die weg proberen.
O ja, mocht je HomeKit hebben dan moet je wel expliciet aangeven in de hue app dat de motion sensor in de woning app wordt geconfigureerd. Indien in zowel de woning app als de hue app, dan kun je raar gedrag krijgen.

[aawe mwan]

wimmel_1 schreef op vrijdag 5 januari 2018 @ 18:48:
[...]
Ik heb hier ná dat geneuzel van laatst (té veel accessoires / rules op één bridge) de hele config hier thuis op de schop gegooid en dus ook m'n lampen opnieuw mogen verdelen over 3 HUE Bridges.

Je hebt geluk dat jouw oplossing mogelijk is, want volgens mij is Philips de enige waarvan de app het ondersteunt om gemakkelijk over te schakelen naar een andere bridge.

Was het voor jou trouwens niet handiger geweest om een „professionele” Zigbee bridge te kopen?
Ik weet niet of Philips er ook een heeft, maar Chinese verkopers hebben ze in elk geval wel en ook Osram maakt een pro-versie van de Lightify bridge.

[Will_M]

aawe mwan schreef op vrijdag 5 januari 2018 @ 19:13:
[...]


Je hebt geluk dat jouw oplossing mogelijk is, want volgens mij is Philips de enige waarvan de app het ondersteunt om gemakkelijk over te schakelen naar een andere bridge.

Was het voor jou trouwens niet handiger geweest om een „professionele” Zigbee bridge te kopen?
Ik weet niet of Philips er ook een heeft, maar Chinese verkopers hebben ze in elk geval wel en ook Osram maakt een pro-versie van de Lightify bridge.

Dat wordt misschien de volgende stap als dat spul ooit Apple Homekit Certified wordt. Ik gebruik de HUE Bridge's eigenlijk alleen maar om de lampen aan "kamers" te linken én om de HUE Accessoires beschikbaar te kunnen krijgen én linken + configureren aan / voor die "Kamers" (waarbij die kamers niet eens voor een fysieke kamer hoeven te staan maar vaak meer een gedeelte van een vertrek zijn). Feitelijke bediening doe ik middels Apple Homekit (waar ik ook géén configuratie in doe behalve de "Coming Home / Leaving Home" zaken) dus ook "Hé Siri werkt hier AS A CHARME

Ander voordeel is dat die HUE bridges praktisch voor niets worden weg gegeven door Philips (tenzij je er één los wil aanschaffen). Ik had genoeg van die dingen liggen vanwege de aanschaf van een aantal "Starter Kit's" welke vooral interessant voor me waren vanwege de combinatie HUE Lampen + HUE Dimmers.

[aawe mwan]

Verwijderd schreef op vrijdag 5 januari 2018 @ 00:35:
[...]
Latency komt meestal door verzadiging van de 2.4Ghz band. Het is een spread spectrum protocol, en zigbee deelt het frequentiegebied met wifi.

Zie hier de uitleg:
https://support.metageek....gBee-and-WiFi-Coexistence

In theorie klopt dat verhaal helemaal, maar in de praktijk zijn er ook mensen die in een stad wonen. In mijn geval zenden er op elk WiFi kanaal ongeveer 9 andere stations. En dan bedoel ik niet alleen de kanalen 1, 6 en 11, maar alle kanalen (op 2,4GHz).

[meesje]

Ethirty schreef op vrijdag 5 januari 2018 @ 18:37:
[...]

Als je de Tap 10s ingedrukt houdt verdwijnt hij inderdaad uit de app, maar opnieuw toevoegen is mij tot nu toe altijd makkelijk gelukt. Apparaat toevoegen, tap indrukken en klaar. De Tap is nog wel bekend in het systeem, dus alles werkt daarna weer als vanouds.

Als jij daadwerkelijk 3 bridges hebt, zou ik maar eens gaan labelen wat bij welke bridge hoort.

Naast snel achter elkaar op de knoppen drukken, houdt mijn zoontje de knoppen ook lang ingedrukt. Dat viel een week geleden op toen hij de kerstboom verlichting (elgato eve energy) aan wilde doen. Bij het indrukken keek hij naar de kerstboom. Op dat moment kon ik gelijk reageren van laat de knop maar los. De actie wordt trouwens ook pas uitgevoerd na los laten.

Bij mijn vorige bericht zat ik op twee weken, nu al weer op 2,5 week dat de Tap het nog steeds doet. Dat de Tap opeens het niet meer deed (of verdwenen was in de woning app), heb ik toch het idee dat het aan mijn zoontje ligt. @Serena Jij had toch ook problemen met het uitvallen van de Tap. Heb jij toevallig ook een klein familielid die lang op de knoppen drukt van de tap? Ik ben wel erg benieuwd of als je nu de Tap weer zal configureren in HomeKit, je nog steeds na een x tijd hebt dat ie uitvalt. Toch wel leuk als je de Elgato stekkers direct kunt aansturen ipv indirect via een Hue lamp?

@wimmel_1 Bedankt voor het delen van de ervaring met je neefje. Wat mij trouwens opviel, is wanneer de Hue Tap er mee op hield, deze nog wel zichtbaar was in zowel de Woning app als de Hue app. Wat ik toen (twee keer) heb gedaan was de Hue Tap eerst verwijderen, maar dat zorgde er voor dat ook de bridge verdween..... Bij de eerste keer dacht ik van je hebt zelf de verkeerde accessoire verwijderd, maar na de tweede keer wist ik zeker dat ik de hue tap had geselecteerd om te verwijderen. Mijn oplossing is om de Hue Tap uit de hue app te verwijderen en deze daar weer toe te voegen en daarna verder configureren in de woning app.

[Verwijderd]

meesje schreef op vrijdag 5 januari 2018 @ 19:27:
Naast snel achter elkaar op de knoppen drukken, houdt mijn zoontje de knoppen ook lang ingedrukt. Dat viel een week geleden op toen hij de kerstboom verlichting (elgato eve energy) aan wilde doen. Bij het indrukken keek hij naar de kerstboom. Op dat moment kon ik gelijk reageren van laat de knop maar los. De actie wordt trouwens ook pas uitgevoerd na los laten.

Dit is niet waar, althans niet helemaal. De Philips dimmerswitch kan onderscheid maken tussen 'kort duwen' en 'lang duwen', en daar verschillende acties aanhangen. Zo kun je de dimmerknoppen ingedrukt houden.

Bij mijn vorige bericht zat ik op twee weken, nu al weer op 2,5 week dat de Tap het nog steeds doet. Dat de Tap opeens het niet meer deed (of verdwenen was in de woning app),

De tap is een overdesigned falend product. Het verschil tussen de tap en de dimmerswitch, is dat de dimmerswitch batterijgevoed is. De tap niet. De tap haalt de enrgie uit het indrukken van de knoppen.

Dat houdt dus ook in, dat als ie niet bediend is, hij verdwijnt van het netwerk. Om pas weer terug te komen als de knop ingeduwd wordt.

Latency zit dus bij de tap in het device zelf ingebakken. Op het moment dat jij op de knop duwt, onstaat er de energie waarop het ding werkt. Hij moet dan eerst wakker worden, verbinding maken, en kan dán pas het daadwerkelijke commando versturen.

Nu de dimmerswitch er is, snap ik niet dat er nog mensen zijn die de tap kopen. En als je heel erg op de latency zit, moet je dus ook geen tap kopen, maar een batterijgevoede dimmerswitch.

Hier in huis alles hue met dimmerswitch en voor bepaalde ruimtes (gangen, toiletten, badkamer) een switch icm. een bewegingssensor.

Ik woon in een nieuwbouwwijk in een soortgelijke situatie als iemand hierboven al beschreef; op alle wifi kanalen zit wel iemand, en veel huizen hebben zelfs meerdere wifi's.

Nu zijn wifi en zigbee zogeheten spread spectrum protocollen. Dat houdt in dat er prima meerdere devices op één 'kanaal' kunnen zitten (er is helemaal geen kanaal, eigenlijk, een kanaal is een range aan frequenties waarover gehopt wordt).

Daar zit echter wel een grens aan. Zitten er heel veel zaken dicht bij elkaar op hetzelfde kanaal, dan raakt het frequentiegebied wat bij dat kanaal hoort 'verzadigd', en krijg je latency of uitvallers.

Je hoeft dus niet perse een leeg kanaal te hebben, maar kijk even op de link die ik gaf, en zorg in elk geval dat je eigen wifi en zigbee zoveel mogelijk uit elkaars haar blijven.

De philips bridge wil helaas niet naar kanaal 26. Ik heb 'm op 25 en het huis-wifi op 1, die toevallig leger is hier in de buurt. Dat werkt, met hub, nagenoeg latencyvrij. Ik zie geen verschil tussen 'via hub' (wat helelaam niet bestaat) of 'rechtstreeks' (wat ook helemaal niet bestaat).

Ik zie wél verschil tussen 'via de clouddienst'. En da's vrij logisch. Dus als je bv. je mobiel niet op het lokale wifi hebt, en dan iets bediend. Dán merk ik wel latency. Ook gebruik ik Triggi (een soort IFTTT) en die kent ook een enorme latency. Die hebben 'NOW' knoppen die je in het pulldownmenu op je android phone krijgt, als ik op zo'n knop duw, kan het zo 2 seconden duren voor het gebeurd.

Ik denk dat de mensen die met latency bezig zijn, het hele concept van home automation niet snappen. Het doel is juist dat het geautomatiseerd wordt. Met bewegingssensoren en een hele reeks aan triggi triggers, gaat de verlichting hier in huis nagenoeg geheel uit zichzelf. HEt komt maar amper voor dat er nog iemand op een knopje hoeft te duwen.

Voorbeeld; een half uur voor zonsondergang gaat de verlichting in de woonkamer aan. Als je op de gangen of toiletten of in de badkamer komt, gaat het licht aan en na 5 minuten weer uit. Duw je bv. in de badkamer op de schakelaar, gaat het pas na een uur weer uit (voor als iemand bv. in bad wil). Om 7 uur gaat het licht op de kinderkamers aan, bij het naar bed brengen zetten we het in nachtstand (alleen nachtlampje aan, redelijk gedimd) en om 2300 gaat het naar slaapstand (nog meer gedimd). Om 20:00 wordt de verlichting in de woonkamer naar 'gezellig gedimd' gezet.

Enzovoort, enzovoort. Naar mijn mening is het de truuk om je verlichting zo intelligent te maken met regels en sensoren, dat je helemaal geen schakelaar meer aan hoeft te raken. En dus latency geen issue is. Want of die trigger nu om 19:00 of 19:01 uitgevoerd wordt, maakt helemaal geen moer uit.

[Verwijderd]

Oh, met betrekking to de tap en het verdwijnen ervan. Hou in je achterhoofd dat het een mesh netwerk is. Stel nu eens dat je tap zelf de bridge niet kan bereiken. Stel dat de door de tap bediende lampen tússen tap en bridge zitten. Als dan alles aan is, zal de tap VIA die lampen verbinding maken met de bridge. Zet je dan met de tap die lampen uit, valt zijn verbindingsmogelijkheid weg, en kan hij dus, als ie wakker wordt voor het aanzetten, geen verbinding meer krijgen.

Dit is op te lossen door je bridge dichter bij je tap te zetten. Je kunt het testen door voor de grap tussen bridge en test eens een paar lampen te zetten die altijd aan zijn.

[mediumdry]

Verwijderd schreef op vrijdag 5 januari 2018 @ 18:58:
Wat er misgaat in je redenatie, is het idee dat je, zonder bridge, DIRECT een lamp bediend. Dit is namelijk helemaal geen vaststaand feit. Zigbee is een mesh netwerk. De kans is groot dat je VIA de dichtsbijzijnde lamp, de lamp bediend die je wil hebben.

Dat is natuurlijk helemaal waar, maar met een knop die "direct" praat met een lamp (en vlak bij de lamp is) is er 1 stap. Van een knop naar de bridge en dan naar de lamp is het 2x door de mesh. Dat hoeft niet per se langer te duren, maar zal dat in de meeste gevallen wel zijn, afhankelijk van de plaatsing van de bridge en knop en lamp. (ik heb strategisch wat lampen toegevoegd omdat er een lamp wat ver van de andere lampen en bridge zat om de mesh te verbeteren)

En voorbij de bridge in het ethernet netwerk zijn er dan vaak nog extra communicatie stappen. En via een clouddienst heb je altijd nog weer extra latency. Op welk punt het een "probleem" wordt is per persoon verschillend.

Met alle respect, als je al lampen gaat vervangen omdat je denkt dat de latency 'in' de lampen zit, dat is van een hoog aluhoedjes niveau. Ik denk dat dan de latency een psychosomatisch iets geworden is.

De lampen waar ik het over had waren geen smart lampen. In de begintijd van de spaarlampen en ledlampen had je lampen die een opwarmtijd hadden en pas na een minuut op volle sterkte waren en lampen die pas na een seconde (of 2) aansprongen. (vanaf het moment dat je de stroom er op zet/ouderwetse schakelaar schakelde). Herinner je je de iconen die aangaven dat een lamp binnen een seconde 80% of meer van de lichtopbrengst hadden niet meer? Ik werd gek van die lampen.

[Verwijderd]

mediumdry schreef op vrijdag 5 januari 2018 @ 20:05:
De lampen waar ik het over had waren geen smart lampen. In de begintijd van de spaarlampen en ledlampen had je lampen die een opwarmtijd hadden en pas na een minuut op volle sterkte waren en lampen die pas na een seconde (of 2) aansprongen. (vanaf het moment dat je de stroom er op zet/ouderwetse schakelaar schakelde). Herinner je je de iconen die aangaven dat een lamp binnen een seconde 80% of meer van de lichtopbrengst hadden niet meer? Ik werd gek van die lampen.

Ik ken het fenomeen, maar dan heb je het dus niet meer over zigbee latency. Of schakellatency. En daar ging het over. Niet over spaarlampen die pas na enige tijd op volle kracht zijn.

Ik moet eerlijk zeggen dat ik historisch gesproken niet onderbouwd ben qua HUE, maar zijn er ooit zulke HUE lampen geweest dan? ik meende dat dat altijd 'meteen aan' LED lampen zijn geweest?

[Ino Dekker]

Even wat recht zetten:

Verwijderd schreef op donderdag 4 januari 2018 @ 22:38:
De Dimmerswitches van Philips zijn controller_colorscenecontroller devices. Als ik nu een collor_colorscenecontroller device pak van een andere fabrikant, zal het niet werken op de hub.

Klopt, de dimmer switch is ook een controller_colorscenecontroller device, maar er zijn meer endpoints. Op een ander (HA) endpoint is het een switch/sensor die button events stuurt naar de hub die er door middel van het geprogrammeerde gedrag voor zorgt dat er lampen aangestuurd worden. Een generieke colorscenecontroller stuurt normale on/off, level, color, scene en group cluster commando's, die geen effect hebben op de hub. Volgens mij is de Ikea motion sensor ook niets anders dan een generieke controller.

code:

if (manufacturer_id= 0x100b) then { work}  else { do not work } .

Die 0x100b = 4107 = het philips ID.

Zou je een schakelaar maken die EXACT dezelfde functionaliteiten en clusters etc aanbied als de Philips Dimmerswitch, dan zou je die NOG niet kunnen binden en zien in de hue app. Zuiver omdat de vendor_id niet van philips is.

Aangezien er nog geen andere switch bestaat die aan het eerste criterium voldoet kun je niet bewijzen dat de vendor-id lock er ook op zit.

[mediumdry]

Verwijderd schreef op vrijdag 5 januari 2018 @ 20:13:
Ik ken het fenomeen, maar dan heb je het dus niet meer over zigbee latency. Of schakellatency. En daar ging het over. Niet over spaarlampen die pas na enige tijd op volle kracht zijn.

Ik zei dat ter illustratie dat ik gevoelig ben voor latency en er de schurft aan heb. Dat was blijkbaar niet duidelijk.

Verwijderd schreef op vrijdag 5 januari 2018 @ 19:57:
Ik denk dat de mensen die met latency bezig zijn, het hele concept van home automation niet snappen. Het doel is juist dat het geautomatiseerd wordt.

Dat is een mogelijkheid. Er zijn er veel meer. De mogelijkheid van het aanpassen waar de fysieke knoppen zitten voor een lamp. Mogelijkheid om meer lampen op 1 knop te zetten. Mogelijkheid om in 1 keer alle lampen uit te zetten als je het huis uit gaat.

Er is een hoop te automatiseren, zeker als je alleen woont of met weinig anderen. Als je een heel regelmatig leven leidt dan is heel veel te automatiseren. Niet voor iedereen.

In mijn geval heb ik te maken met mensen die knoppen gewend zijn en dat ook niet willen veranderen. Dus daar moet ik rekening mee houden.

Ieder zijn mening. Ik vind dat als je home automation altijd via een clouddienst laat lopen dat je dan verkeerd bezig bent. Als je niet de mogelijkheid geeft alles lokaal te houden (inclusief data) dan ben je niet goed bezig. Als je een product maakt waarbij je geen rekening houdt met hoe mensen het traditioneel gebruiken, dan maak je een product voor een kleinere markt dan zou kunnen. Maar goed, dat is mijn mening en dat vertaalt zich in welke producten ik gebruik. Ik hoop dat producenten producten maken die compatibel zijn met mijn mening. Vaak is dat niet zo.

Overigens is Philips Hue nauwelijks Home Automation te noemen. Het automation deel is erg klein. Het is een networked licht product, dat o.a. gebruikt kan worden voor Home Automation.

[meesje]

@wimmel_1 Door jouw klik graag neefje opmerking, ben ik in dit topic (te veel) gaan uitwijden over de hue tap icm HomeKit. Dat had ik beter in het HomeKit topic kunnen doen. Sorry daarvoor.

@Verwijderd Je hebt gelijk. Ik heb net nog een test gedaan. Al bij het indrukken gaan de lampen aan, niet alleen pas na loslaten. Dat neemt niet weg, dat bij lang indrukken (door mijn zoontje) de tap niet meer werkt.
Ik vind het trouwens erg bijzonder dat je helemaal los gaat na een opmerking van mij dat mijn Hue Tap het nu al 2,5 week goed werkt (icm HomeKit, zonder HomeKit heeft ie altijd 100% gewerkt). Je betrekt allerlei zaken er bij; latency, niet perse een leeg kanaal te hebben, etc. Ik haak dan echt helemaal af. Sowieso zou ik je adviseren om je schrijfstijl aan te passen. Bijvoorbeeld ‘ik zie wél het verschil’. Heeft er iemand aangegeven dat je niet het verschil ziet..... Je zult ongetwijfeld heel veel kennis hebben, maar probeer wat minder belerend over te komen. Dat kan botsen met anderen, zoals gisteren.

[Will_M]

meesje schreef op vrijdag 5 januari 2018 @ 20:32:
@wimmel_1 Door jouw klik graag neefje opmerking, ben ik in dit topic (te veel) gaan uitwijden over de hue tap icm HomeKit. Dat had ik beter in een het HomeKit topic kunnen doen. Sorry daarvoor.

@Verwijderd Je hebt gelijk. Ik heb net nog een test gedaan. Al bij het indrukken gaan de lampen aan niet alleen pas na loslaten. Dat neemt niet weg, dat bij lang indrukken (door mijn zoontje) de tap niet meer werkt.
Ik vind het trouwens erg bijzonder dat je helemaal los gaat na een opmerking van mij dat mijn Hue Tap het nu al 2,5 week goed werkt (icm HomeKit, zonder HomeKit heeft ie altijd 100% gewerkt). Je betrekt allerlei zaken er bij; latency, niet perse een leeg kanaal te hebben, etc. Ik haak dan echt helemaal af. Sowieso zou ik je adviseren om je schrijfstijl aan te passen. Bijvoorbeeld ‘ik zie wél het verschil’. Heeft er iemand aangegeven dat je niet het verschil ziet..... Je zult ongetwijfeld heel veel kennis hebben, maar probeer wat minder belerend over te komen. Dat kan botsen met anderen, zoals gisteren.

Ik vind 't, in tegenstelling tot anderen misschien, eigenlijk wel grappig dat ook dit soort discussies hier gevoerd worden nét zoals die discussie over wel/géén "VENDOR LOCK" hier gewoon gevoerd moet kunnen worden. Het gaat op zo'n moment misschien niet meer 100% over HUE ansich maar 't zijn wél ervaringen van mede HUE gebruikers welke er toe doen als je de algehele "UXP" in beschouwing neemt.

Als we hier alleen de, No-Offence, vragen mogen stellen welke betrekking hebben op 't wel/niet kunnen koppelen van Ikea Traffri spullen óf voor de zovéélste keer een linkje naar HUE Labs moeten geven omdat mensen iets willen bereiken wat niet in de standaard GUI van de HUE Bridge kan dan wordt 't wel érg saai (IMHO).

[meesje]

wimmel_1 schreef op vrijdag 5 januari 2018 @ 20:40:
[...]


Ik vind 't, in tegenstelling tot anderen misschien, eigenlijk wel grappig dat ook dit soort discussies hier gevoerd worden nét zoals die discussie over wel/géén "VENDOR LOCK" hier gewoon gevoerd moet kunnen worden. Het gaat op zo'n moment misschien niet meer 100% over HUE ansich maar 't zijn wél ervaringen van mede HUE gebruikers welke er toe doen als je de algehele "UXP" in beschouwing neemt.

Als we hier alleen de, No-Offence, vragen mogen stellen welke betrekking hebben op 't wel/niet kunnen koppelen van Ikea Traffri spullen óf voor de zovéélste keer een linkje naar HUE Labs moeten geven omdat mensen iets willen bereiken wat niet in de standaard GUI van de HUE Bridge kan dan wordt 't wel érg saai (IMHO).

Het is inderdaad ook wel een grijs gebied: homebridge, homekit, xiaomi, ikea, etc. Daar heb je helemaal gelijk in. Maar als hier iemand een vraag stelt over dat ie een xiaomi sensor niet werkend krijgt met hue middels homebridge of domoticz, dan denk ik wel van stel die vraag ergens anders. Een discussie over zigbee vind ik dan wel beter hier passen (hue=zigbee).

Maar ach, zo lang we elkaar niet voor rotte vis uitmaken, kan alles wel.....

[Verwijderd]

Ino Dekker schreef op vrijdag 5 januari 2018 @ 20:20:
Even wat recht zetten:

Je zet niet recht? Je zegt hetzelfde als ik?

Aangezien er nog geen andere switch bestaat die aan het eerste criterium voldoet kun je niet bewijzen dat de vendor-id lock er ook op zit.

Die bestaat dus wel. Ik heb zélf een JN5169 gebaseerde schakelaar ontwikkeld die als Philips Dimmerswitch op het netwerk zit. Dat vertel ik notabene in de posting waarop je reageert. End ie werkt, zolang ik het Philips Vendor ID erin laat staan. Voor de hue app en hub etc, is het dan 'gewoon' een philips dimmerswitch. Dat werkt, en zo gebruik ik hem.

Verander ik nu in de code de vendor_id (ja exact, die bestaat), van 0x100b (=philips) naar iets anders, dan werkt ie niet meer.

QED.

Inhoudelijk; op meesje en anderen; of het spul vendor locked is, is heel on topic en gaat over Hue. Idem de discussies over zigbee. Er komen nogal wat 'klachten' tevoorschijn die hun basis hebben in niet weten hoe het systeem werkt. Het is dan goed als mensen uitleggen hoe het - volgens hun - werkt.

Dat is niet belerend bedoeld. Mensen, en zeker tweakers, kunnen er niet zo goed tegen als iemand anders het beter lijkt te weten, en reageren daar snel boos op of vatten het als belerend op. Je kunt ook zeggen 'goh dat wist ik niet' of 'daar ben ik het niet mee eens', zonder allemaal ad hominemn aanvallen te plegen.

Op andere vlakken mogen anderen mij uitgebreid de les lezen, maar op dit vlak weet ik vrij goed hoe het zit, en leg ik dat graag uit als ik merk dat mensen ergens iets vertellen wat niet klopt.

Als een niet-geinformeerd iemand dit draadje zo zou gaan lezen, zou ie kunnen denken dat alles zomaar samenwerkt met de Philips spullen (wat niet zo is) of dat er allemaal onverklaarbare grote onbruikbare latencies in het geheel zitten. Wat ook niet zo is. Dus geef ik daar tegengas op.

Wellicht moeten mensen een swat minder prikkelbaar reageren of het gelijk als belerend opvatten, als iemand iets wat zij gezegd hebben, tegenspreekt?

[ Voor 42% gewijzigd door Verwijderd op 05-01-2018 20:56 ]

[Will_M]

@Verwijderd GE-WEL-DI-GE EDIT!!

[Ino Dekker]

Verwijderd schreef op vrijdag 5 januari 2018 @ 20:53:
[...]


Je zet niet recht? Je zegt hetzelfde als ik?

Volgens mij niet. Je zegt dat een andere controller niet in de hub komt, terwijl de Philips dimmer switch dat wel doet en ik zeg dat de Philips dimmer switch niet alleen een controller is waardoor hij wel in de hub komt.
Maar goed, als je dat bedoelde was mij dat niet duidelijk en heb ik het bij deze in ieder geval voor mezelf verduidelijkt.

Die bestaat dus wel. Ik heb zélf een JN5169 gebaseerde schakelaar ontwikkeld die als Philips Dimmerswitch op het netwerk zit. Dat vertel ik notabene in de posting waarop je reageert. End ie werkt, zolang ik het Philips Vendor ID erin laat staan. Voor de hue app en hub etc, is het dan 'gewoon' een philips dimmerswitch. Dat werkt, en zo gebruik ik hem.

Verander ik nu in de code de vendor_id (ja exact, die bestaat), van 0x100b (=philips) naar iets anders, dan werkt ie niet meer.

Dan doe je toch iets niet goed. Maar misschien dat je JN5169 device geen onderscheidt maakt tussen vendor_id en manufacturer code bij manufacturer specific cluster commando's/attributen.

[Verwijderd]

Ino Dekker schreef op vrijdag 5 januari 2018 @ 21:14:
Dan doe je toch iets niet goed. Maar misschien dat je JN5169 device geen onderscheidt maakt tussen vendor_id en manufacturer code bij manufacturer specific cluster commando's/attributen.

Ik doe niets fout. Hou op het op andere zaken te gooien. Vendor_id en manufacturer code zijn één en dezelfde. Code die werkt, als er 'philips' instaat, maar niet werkt als er 'sony' in gezet wordt. Dan is er een vender lock. Het JN5169 device is een veelgebruikte chip welke 100% voldoet aan de zigbee specificatie.

Neem dat nou eens van iemand aan. Dat, óf laat eens zien hoe jij een niet-philips schakelaar op je hub en in je app hebt gekregen, want het is niet vendor locked, dus moet dat kunnen. Nou laat maar zien dan.

[Ino Dekker]

Verwijderd schreef op vrijdag 5 januari 2018 @ 21:19:
[...]


Ik doe niets fout. Hou op het op andere zaken te gooien. Vendor_id en manufacturer code zijn één en dezelfde. Code die werkt, als er 'philips' instaat, maar niet werkt als er 'sony' in gezet wordt. Dan is er een vender lock. Het JN5169 device is een veelgebruikte chip welke 100% voldoet aan de zigbee specificatie.

Neem dat nou eens van iemand aan. Dat, óf laat eens zien hoe jij een niet-philips schakelaar op je hub en in je app hebt gekregen, want het is niet vendor locked, dus moet dat kunnen. Nou laat maar zien dan.

Nee, die zijn niet hetzelfde en het zegt niets over het voldoen aan de zigbee specificatie. Je kan en mag manufacturer specifieke attributen/commando's implementeren van een andere vendor dan de vendor van het device of de zigbee stack (zoals in een van de descriptors staat vermeld). De manufacturer code is hier om te voorkomen dat dezelfde attributen/commando's niet meer dan 1 betekenis heeft.

Als jij mij een sniffer log kan laten zien waarin vendor_id = 0x1234 (of iig anders dan 0x100b), maar waar manufacturer code bij ZCL manufacturer specifieke attributen/commando's wel 0x100b is en het niet wil werken, dan neem ik het van je aan.