@RCZ zei: “een python script op een NAS lijkt een goeie oplossing, maar voor bedrijven een grote nachtmerrie want je points of failure nemen logischerwijs toe… wie gaat die NAS ondersteunen? wie gaat de disken in de NAS ondersteunen, wie het netwerk, DNS, DHCP etc… - hoe ga je dat doen met de helpdesk als iemand die hier echt geen verstand van heeft gaat bellen omdat het niet werkt? daarom zijn er gesloten systemen omdat de fabrikant hier controle op kan uitoefenen en dus ook support kan leveren.”
Inderdaad en uiteraard allemaal volledig terechte opmerkingen. Al die NAS soft is nodig omdat fabrikanten zich niet aan een standaard willen houden. Als die nu eens standaard MQTT zouden gebruiken is het maar een kwestie van een subscription te maken en klaar.
@RCZ zei: "het kan allemaal perfect idd… en jouw oplossing werkt met de MQTT standaard, maar er zijn nog veeeeeel meer standaarden waarvan fabrikanten zeggen, “dat vinden wij beter, want abc”
… en dus zijn we weer eens vertrokken voor een gelijkaardig verhaal als dat van de videoformaten. Uiteindelijk wint de goedkoopste altijd, kwaliteit speelt geen rol. VHS was de slechtste en werd de standaard want de goedkoopste. Daarom maakten de fabrikanten daarna een akkoord rond CD en die is nu nog steeds de standaard, ondanks de vele pogingen voor een betere kwaliteit met super-CD, DVD enz… de enige die CD wegdrukt is de nóg goedkopere standaard: mp3. We leren niet bij.
@RCZ zei: “maar als jij je wasmachine wil schakelen, waarom zou je dan het stopcontact moeten schakelen? waarom zou je geen bericht aan je wasmachine kunnen sturen om te starten - of dat je wasmachine zelf de status van de solar in de gaten houdt en start bij een bepaalde waarde?”
Omdat mijn wasmachine niet kapot is en geen MQTT kan… en als ik die wil vervangen dan doet die EEBUS en dat is dan weer geen MQTT. Bosch, Siemens etc… zetten koppig door met EEBUS omdat ze er geld mee willen verdienen, het reslutaat is dat EEBUS zo een beetje dood in het water ligt en geen enkele open omgeving aan EEBUS wil. Een op afstand bediend schakelaarindrukarmpje werkt ook niet: touch toetsen.
@RCZ zei: " waarom zou je je spa geen opdracht kunnen geven om het water x graden te maken en af te koelen (of op te warmen afhankelijk waar je woont) op andere tijden?"
Omdat mijn spa dat niet kan. Het regelsysteem via Wifi kost honderden euro en wordt daarom bijna nooit verkocht. En… het is proprietary prorocol, zelfs geen EEBUS.
@RCZ zei: “en zo zou je ook je electra verbruik direct van de leverancier moeten kunnen opvragen met een API call… het zit er bij ons al in, want onze app van de leverancier geeft elke dag mijn verbruik al aan…”
Het zou nuttig zijn als de DSMRv5 rechtstreeks MQTT kon… dat is mijn hele verhaal, iedereen wil zijn eigen protocolletje zodat apparaten elkaar niet begrijpen. Dat is mijn hele betoog hier. We missen als samenleving een enorme opportuniteit omdat de fabrikanten te inhalig zijn en de politiek niks op wil leggen.
Ik moet daarom mijn eerdere uitspraak verhelderen: “Mijn oplossing werkt met de MQTT standaard. Mijn Python code draait intussen op de NAS zonder problemen, uiterst betrouwbaar. En ik meet de waarde waar ook mee gefactureerd wordt. En niet een andere afwijkende waarde. Dat is de toekomst.”
De toekomst is niet dat we een NAS en programmeurstalent modig hebben, de toekomst is het volgen van een standaard. En mijn oplossing toont aan dat MQTT voldoet en betrouwbaar is.
.
