Anbindung and ebusd mit modul 98_GAEBUS.pm

Begonnen von jamesgo, 14 September 2015, 10:18:17

Vorheriges Thema - Nächstes Thema

mikel279

wieder was gelernt  :D

Nun ja, aktuell habe ich keine Probleme - aber entities tendenziell auch steigend - also werde ich die Diskussion gespannt weiter verfolgen ;)

BTW: habe gerade mal einen ersten Schreibversuch gewagt und hierzu was unkritisches verwendet - das Wartungsdatum. Leider ohne Erfolg  :(
Fehlermeldung "ERR: element not found" Wenn ich den Namen des HK1 ändern will, zweiter Versuch, dann bekomme ich ein "done" - scheint also prinzipiell zu funktionieren.
Jemand schon Erfahrungen mit dem Schreiben gesammelt?

LG Mikel

amunra

Zitat von: mikel279 am 16 September 2015, 21:15:02
Fehlermeldung "ERR: element not found" Wenn ich den Namen des HK1 ändern will, zweiter Versuch, dann bekomme ich ein "done" - scheint also prinzipiell zu funktionieren.
Dieses Verhalten habe ich schon mehrfach auch in einer Telnet Session beim lesen beobachtet => also nicht FHEM spezifisch - eher ein ebusd Thema.

@jo und @jamesgo
BlockingCall kann helfen - ich persönlich trenne mein FHEM-Prod-System (Zeitkritisch) von FHEM Ebus(d) System.

kawa0815

Zitat von: jamesgo am 15 September 2015, 10:35:12
@Reinhart, kawa0815,

Könnt ihr bitte mal die aktuelle Version von Sourceforge testen.
Damit sollte das Umlauteproblem gelöst sein.

Danke
Andy

Hallo Andy,

Habe die Version getestet, Umlautproblem tritt nicht mehr auf.

Danke!

Kawa

Jojo11

Zitat von: amunra am 16 September 2015, 22:02:18
Dieses Verhalten habe ich schon mehrfach auch in einer Telnet Session beim lesen beobachtet => also nicht FHEM spezifisch - eher ein ebusd Thema.

@jo und @jamesgo
BlockingCall kann helfen - ich persönlich trenne mein FHEM-Prod-System (Zeitkritisch) von FHEM Ebus(d) System.
Hallo,

wie genau trennst Du denn die beiden Systeme? Im Prinzip müsste blockingcall doch in das Modul eingebaut werden, oder? Auf zwei verschiedenen Rechnern laufen FHEM und ebusd ja schon.

schöne Grüße
Jo


amunra

Zitat von: Jojo11 am 19 September 2015, 21:41:09
wie genau trennst Du denn die beiden Systeme?
Eine HW für Prod und eine für Fhem-Ebusd - dieses System ist auch kein failover System für das Prod System.

Zitat von: Jojo11 am 19 September 2015, 21:41:09
Im Prinzip müsste blockingcall doch in das Modul eingebaut werden, oder?
Ja.

Zitat von: Jojo11 am 19 September 2015, 21:41:09
Auf zwei verschiedenen Rechnern laufen FHEM und ebusd ja schon.
Mit dieser Aussage:
Zitat von: Jojo11 am 16 September 2015, 19:02:26
evtl ist der timeout von 5 Sekunden doch etwas zu viel des Guten. Ich teste jetzt mal mit 3 s. Bei 5 s hatte ich sehr viele disconnects meines Homematic HMLANs, was eigentlich immer auf eine deutliche Systemverlangsamung hindeutet. Es wäre natürlich ideal, wenn die Warterei in einem anderen Prozess laufen würde und somit keinen Einfluss auf den Rest des Systems hätte  ::)
bin ich davon ausgegangen, dass alles auf einer HW bzw. in einer FHEM Instanz läuft. Mich wundert es was ein HMLAN auf dem Ebusd-System sucht - oder steigt dein HMLAN wegen der LAN-Load aus? So ganz verstehe ich das Problem dann wohl nicht. ;o)

Viele Grüße
Arthur

Jojo11

Ok, vielleicht etwas falsch ausgedrückt ::)
Ich lasse den ebusd auf einem RPi laufen. Alles andere (fhem) läuft auf einem cubietruck. Der HMLAN steigt aus, wenn fhem zu lange ausgebremst wird und ist daher immer ein guter Indikator für Bremsen im System. Laut apptime bremst zur Zeit am meisten GAEBUS, gefolgt von IPCAM, welches auch keinen Parallelprozess startet.

schöne Grüße
Jo


amunra

Hallo jo,
ok, ich denke jetzt habe ich es verstanden.
Ebusd läuft auf einem RPI -> FHEM auf einem CT (Prod-System) auf dem auch das Modul aktiv ist - und genau die beiden Komponenten "zusammen" trenne ich von meinem Prod-System.
Ich habe eine autonome HW für ebusd auf dem auch eine FHEM Instanz läuft inkl. MySQL-DB.
Der zeitkritische Teil ist FHEM nicht Ebusd (läuft nebenbei - im eigenen Thread und damit eher unkritisch, wenn es stabil läuft).

Für die Heizungssteuerung (die man eher nicht alle 3sek. triggert - die Anzahl der Parameter eher klein ist und damit eher unkritisch für FHEM ist) / Monitorring (Datenerfassung ist eher der Teil der die Load erzeugt, weil höher frequentiert.) brauche ich den ebusd (unkritisch) inkl. Fhem (Modul) Overhead auf dem produktiven System nicht.

Abhängig vom Implementierungsumfang (z.B. Anzahl der Abfragen und Intervalle) ist natürlich der Einsatz auf ein und der selben HW sicher kein Problem.

Das nur als Kurzfassung (nicht betrachtet der Sicherheitsaspekte etc.) zum Thema ;o)..

VG Arthur

Jojo11

Hallo Arthur,

ich könnte ja ein zweites fhem inkl Mudul auf dem ebusd RPi installieren. Somit müsste ich nur noch per Fhem2fhem die readings abholen. Aber kann ich dann auch Werte setzen? Oder wie kommunizieren Deine beiden Systeme miteinander? Ich würde das Produktivsystem auch lieber gerne komplett trennen.

schöne Grüße
Jo


Prof. Dr. Peter Henning

Die Trennung sollte in der Tat physisch sein, schon aus Sicherheitsgründen.

Bisher habe ich auf einem separaten Pi nur den ebusd laufen, wenn GAEBUS etwas stabiler ist, kommt dort ein weiteres externes Fhem dazu.

Komme leider im Moment nicht zum Mit-testen.

LG

pah

amunra

Zitat von: Jojo11 am 20 September 2015, 07:39:57
ich könnte ja ein zweites fhem inkl Mudul auf dem ebusd RPi installieren. Somit müsste ich nur noch per Fhem2fhem die readings abholen. Aber kann ich dann auch Werte setzen? Oder wie kommunizieren Deine beiden Systeme miteinander? Ich würde das Produktivsystem auch lieber gerne komplett trennen.

Ok, an Readings (Informationen) zu kommen muss man nicht zwangsläufig fhem2fhem nehmen - bietet sich an, wenn man zwei FHEM Instanzen im Einsatz hat. Mit FHEM2FHEM kann man doch auf EVENTS reagieren und Aktionen triggern - das geht doch alles mit FHEM Mitteln. Stabilität und Zuverlässigkeit sollte bei der Wahl berücksichtigt werden.

Meine Sicht der Dinge ist:
1) Es gibt Aktoren und Sensoren (Thermostate, Luft- und Feuchtigkeitssensoren, Schlater etc.)
Bei mir aktuell zuverlässig in FHEM Implementiert.   
2) Therme XYZ angebunden per EBUSD.
Ebenfalls stabil seit Anfang des Jahres.
3) Anbindung EBUSD an FHEM
Hierfür nutze ich das Modul, welches ich Anfang des Jahres geschrieben habe. Der Ansatz war: Einfach halten (geringe Komplexität) - das Modul soll eine EBUSD-FHEM Bridge sein - bzw. Werte abfragen (zu speichern und darzustellen) sowie setzen. Ich bin mit den %sets% also das "setzen von Werten aus FHEM heraus noch nicht zufrieden. Es fehlt mir die Möglichkeit die Daten einfach "darzustellen" ist aber ein anderes Thema.

Was jetzt noch fehlt ist, ich nenne es mal "die Steuerzentrale" - also etwas was die Punkte 1/2/3 vereint und das auch noch möglichst einfach und intuitiv.

Fazit: Also noch viel zu tun.

VG Arthur

Jojo11

Hallo,

so, habe jetzt mal meine Konfig umgebaut:
1) Rechner 1: CT mit Hauptsystem
2) Rechner 2: RPi mit ebusd und FHEM, per FHEM2FHEM an Rechner 1 angebunden
Auf dem RPi läuft GAEBUS und ruft munter alle Daten vom ebusd ab. Apptime hat ergeben, dass damit die Verzögerung des Hauptsystems von 4 s auf 0,4 s reduziert wurden und somit "im Rauschen untergehen"  :)

Jetzt habe ich mir gedacht, dass ich die paar Werte, die ich ab und zu mal setzen möchte (Solltemperaturen und Ferienzeiten) auch über GAEBUS auf Rechner 1 setzen kann, da dies ja mit FHEM2FHEM im LOG-Modus nicht geht. Dazu müsste ich natürlich von zwei Rechnern jeweils per GAEBUS auf den ebusd zugreifen. Spricht da irgendetwas gegen?

schöne Grüße
Jo


amunra

Technisch wird das funktionieren. Was nicht empfehlenswert ist, ist von beiden Systemen aus zu schreiben - sogar das wird technisch gehen, aber die Gefahr sich zu verzetteln ist hoch .
Was dagegen spricht? Das muss jeder für sich entscheiden, da es sehr stark von eigenen Anforderungen (z.B. Sicherheit..) abhängt.
Viele Grüße
Arthur

Jojo11

Schreiben würde ich ja nur von einem System.
Aber andere Idee: Ich könnte vom ebusd-RPi aus per FHEM2FHEM ein paar Dummies auf dem Hauptsystem überwachen und dann bei Änderung die entsprechenden write-Befehle über GAEBUS absetzen. Somit wäre GAEBUS nur auf einem Rechner notwendig. Spricht etwas dagegen, FHEM2FHEM in beide Richtungen zu installieren? Kann ich FHEM2FHEM so konfigurieren, dass nicht grundsätzlich alle readings aller devices übertragen werden und dann aussortiert wird, sondern dass nur die erforderlichen überhaupt übertragen werden? Das könnte sonst das Netzwerk etwas stark belasten, oder?

schöne Grüße
Jo

amunra

So in etwa habe ich z.B. meine Sonos (Modul läuft nicht auf dem Prod-System) Sprachansagen (Temp, Waschmaschine/Trockner fertig, Anrufe, Sonos Radio an etc.) realisiert - läuft seit über 2 Jahren ganz zuverlässig.
Viele Grüße
Arthur

Reinhart

ich habe den ebus auch aus mehreren Gründen von Fhem getrennt und auf einem eigenen Raspi laufen (siehe Schaltplan unten). Läuft via ECMD seit Winter 2014/15 sehr zuverlässig, d.h. für mich ist der ebus schon sehr ausgereift.

http://dengg.lima-city.de/FhemSmarthome-Dateien/main_2.htm

LG
Reinhart


FHEM auf Raspy4 mit Bullseye + SSD, Homematic, ESP8266, ESP32, Sonoff, eBus, NanoCUL, MapleCUL, , MQTT2, Alexa