Hallo,
Vorwort:
ich beschäftige mich jetzt schon ein paar Tage mit FHEM und habe einige erfolgreiche Tests damit machen können, wobei ich hauptsächlich mit Homematic Geräten arbeite. Aktuell verwende ich den RFD von eq3 inklusive HMLANGW zur Reichweitenskalierung. Das Ganze funktioniert schon "ganz ok" aber ist nicht wirklich das Gelbe vom Ei. Besonders bei großen Skalierungen (60 HMLANs mit 500 Geräten) hat der RFD immer mal wieder Probleme. Er stürzt mir auch in kleinen Installationen mal wieder ob und beim Hochfahren des Dienstes müssen immer alle HMLANs erreichbar sein, da sie sonst in der Liste der Interfaces nicht auftauchen. Jetzt habe ich das alles mit FHEM mal nachgespielt und habe in meinen ersten Beobachtungen bereits festgestellt, dass es in so ziemlicher jeder Hinsicht besser ist. Die Reichweitenskalierung meiner Homematic Geräte ist hier der wichtigste Punkt. Während ich beim RFD mit Roaming arbeite, kann ich bei FHEM einfach die passende ID der VCCU vergeben, ein paar IP-Adressen eintragen und bin eigentlich schon fertig. Roaming hat einfach zu viele Probleme, vorallem mit Geräten, die sich selber nicht zyklisch melden. Bei 60 HMLANs gibt es immer mal wieder Ausfälle und diese möchte ich sie gut wie möglich abfangen. Ich kann sogar meine auf dem RFD eingelernten Geräte direkt mit FHEM verwalten, sofern ich einfach nur die richtige ID vergebe. So muss ich nicht mal den Anlernmodus am Gerät selbst betätigen. Wie gesagt bei 500 Geräten in einer Installation wäre der Aufwand enorm. Im Großen und Ganzen bin ich also von FHEM richtig beeindruckt!
Frage:
Mal mehr oder weniger unabhängig von der Hardware auf der FHEM läuft. Nehmen wir als Beispiel mal an ich wäre dort in der Hinsicht flexibel und wir hätten die besagten 500 Geräte und 60HMLANs im Netzwerk verteilt. Ich habe eigentlich nur 2 Anforderungen. Einmal möchte ich natürlich Sachen in den Geräten selber setzen können und dann möchte ich über die Events wie zum Beispiel Temperaturänderung am Thermostat informiert werden. Ich möchte die Daten nichtmal direkt in FHEM verarbeiten sondern weiter an eine andere Instanz schicken, die sich dann darum kümmert. Ich habe gesehen, dass man MQTT verwenden kann und konnte das auch schon erfolgreich testen. In der WEB Oberfläche sehe ich Änderungen an den Geräten immer bereits sofort. Wird das über Websockets, SSE oder irgendwie mit Longpolling gelöst? Ich bin da beim Debuggen im Browser nicht wirklich auf einen grünen Zweig gekommen und im Prinzip würde mir das schon reichen. Das Setzen von Geräteinformationen würde ich über die REST-API lösen, das sah eigentlich ganz nett aus. Da ich aus der Welt des RFD mit dem XML-RPC kommt, wäre es natürlich noch cool, wenn ich sowas wie newDevices etc auch als Event bekommen könnte. Gibts da etwas für? Ansonsten würde ich in FHEM alles abschalten wollen, was irgendwie groß Last ziehen könnte, je nachdem was es dort so geben könnte.
Danke schonmal vorab,
gritob
Hallo Gritob,
eine Frage vorab: Was ist RFD? hat sich geklärt
500 Devices mit 60 HM-LAN ist keine kleine Hausnummer - sollte aber passen
Ist das eine (sehr) große Lokation, oder mehrere Kleine?
Mehrere IO's können via einer VCCU zu einer logischen zusammen gefasst werden (hmlan1, hmlan2, hmlanx --> vccu1) - Ausfallsicherheit von dem phys IO, Funklastverteilung, automatische Wahl der besten Funkverbindung (RSSI) ...
Die automatische Aktualisierung im Web Frontend wird via Longpoll durchgeführt
Die interne Kommunikation innerhalb von FHEM wird via "Messagebus" gehandelt
FHEM ist Singlethreaded
Zur externen Kommunikation kannst Du mit vermutlich wenig Aufwand RFD mit Daten versorgen (notify wird vermutlich Dein Freund)
Liebe Grüße
Ralf
PS.: Ich würde den Threat in den Homematic Bereich verschieben, damit der Maintainer Martin es auch mitbekommt :-)
Hi,
das mit der VCCU hatte ich oben schon erwähnt, danke aber nochmal für die Sicherheit, dass es auch so funktioniert, wie ich es mir gedacht habe :). Es handelt sich um eine große Location.
Verschieben ist ok, wenns dadurch besseres Feedback gibt. Ich werd mir mal notify anschauen. Vielen Dank schonmal für die Antwort.
Grüße
Mal abgesehen von der technischen Realisierbarkeit...
500 Homematic-Geräte sind extrem viel. Vermute ich richtig, daß vielleicht 60-70% davon batteriebetrieben sind? Das wären dann so 300?
Willst Du wirklich 1000 Batterien im Jahr wechseln? Für mich schreit ein Projekt dieser Größe nach Kabeln und zwei-drei großen Schaltschränken.
Aber wenn Du diesen Weg nicht gehen willst, kannst Du doch mal die Statistiken des Funkverkehrs posten (Stichwort hm rssi)?
Ciao, -MN
Hi,
das Projekt und weitere existiert so schon nur halt mit dem RFD. Die Batterien muss ich nicht wechseln :). So wie es aktuell aussieht, halten die Batterien schon etwas länger als ein Jahr, sofern man die Geräte nicht extrem hart belastet und 1-2 sinnvolle Einstellungen macht. Bei den mitgelieferten Batterien hast du immer mal welche dabei, die schon nach einigen Monaten leer sind aber ab dann gehts schon länger, wenn du nicht das billigste vom billigen nimmst. Die Netzwerkinfrastruktur besteht daher auch bereits. 500 Geräte und 60 hmlans ist das aktuell Größte, deswegen bemesse ich mich da dran. Es geht mir hier eigentlich nicht um das Projekt selbst, sondern wie ich FHEM sinnvoll verwenden kann. Vielleicht habe ich mich etwas falsch ausgedrückt :)
60-70% kommt hin. Der Rest sind meist dann Schaltaktoren.
Grüße
ZitatWird das über Websockets, SSE oder irgendwie mit Longpolling gelöst?
Per default HTTP longpolling, wenn man "attr WEB longpoll websocket" setzt, dann ueber websocket. Was ist SSE?
Eine einfachere Variante davon ist ueber telnet (sprich "plain TCP/IP") per "inform timer" verfuegbar. Oder man verwendet MQTT. Kuriose Loesungen wie SingleFileLog gibts auch, man kann aber auch alles in eine DB oder eine Datei schreiben.
Zitatsowas wie newDevices etc auch als Event bekommen könnte. Gibts da etwas für?
Weiss nicht genau, was newDevices ist, aber wenn (nach der Initialisierung) ein neues Geraet angelegt wird, dann gibt es ein "global DEFINED XXX" Event.
ZitatAnsonsten würde ich in FHEM alles abschalten wollen, was irgendwie groß Last ziehen könnte, je nachdem was es dort so geben könnte.
Im default fhem.cfg gibt es ein eventTypes, was jedes event prueft, den braucht man nur fuer die drop-down Modifizierung von notify.
Das initialUsbCheck kann (je nach Hardware) beim starten etwas nerven.
Falls die Geraete dynamisch angelegt werden, dann wuerde ich beim autocreate das filelog Attribut abschalten.
Die FHEMWEB und telnet Instanzen kosten nix, wenn man sie nicht verwendet. Man kann sie alle entfernen, man hat halt dann keine Moeglichkeit interaktiv was zu aendern.
Wenn es doch irgendwo Engpaesse geben sollte, dass bitte melden.
super danke für die antwort! damit habe ich denke erstmal genug stoff, um mich etwas beschäftigen zu können. SSE sind server side events, wird eigentlich auch von jedem modernen browser unterstützt. ist im prinzip nur die richtung von server zum client um events zu erhalten. halt die eine richtung von websockets.
€: einfach um alle fragen zu beantworten. newDevices ist beim xml-rpc dienst von eq3 einfach das event, was dich informiert, wenn ein neues gerät reinkommt. also ja genau das habe ich gesucht :)
nochmal ein zweiter nachtrag. irgendwie ist das ganze per telnet und inform timer wirklich schon ausreichend und macht n guten eindruck. ist auch für mich sehr leicht abzugreifen aus anderen quellen heraus. setzen kann ich darüber ja dann auch direkt machen, wenn ich die verbindung eh schon offen hab.
Grüße