Anbindung and ebusd mit modul 98_GAEBUS.pm

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

Vorheriges Thema - Nächstes Thema

Prof. Dr. Peter Henning

@Reinhart:

Es fehlt hier noch die Rückmeldung von der HE-Pumpe. Dafür ist m.E. FS20 nicht zuverlässig genug. Man könnte alerdings per FS20KSE einen Rückkanal implementieren, kostet dann nur 20 €.

LG

pah

Reinhart

Hallo Pah!

Danke für den Hinweis, kann ich mir überlegen, da dieses Gerät ja wirklich feststellen könnte ob Spannung bei der Pumpe anliegt und dann auch gleich Mails verschickt.
In meinem Fall ist es aber nicht wirklich kritisch, denn wenn diese Pumpe nicht läuft bleibt es kalt und das würde ich gleich merken.

Meine Therme versorgt ja 3 Geschoße und diese Pumpe ist in meinem Geschoß. Wenn die Heizkörperregler in diesem EG einen bestimmten Öffnungswinkel (einstellbar) unterschreiten, dann wird auch die Pumpe zwecks Stromersparnis abgeschaltet.  Bei Nachtabsenkung sowieso.

Ich setze ja schon parallel zu meiner "alten" FS20-Hauszentrale auch HM Devices ein (vorerst nur Pooltemperatursensoren) und mit diesen Devices wäre dein festgestelltes Problem auch schon entschärft. Mit ebusd habe ich keinen Einfluß auf diese Pumpe, da die extern eingebaut ist und kann daher leider auch keine Parameter aus der Therme abgreifen die aussaugen ob sie läuft.

FS20 Technik ist leider was Rückkanal betrifft ein Stiefkind, bin aber bis jetzt zum Glück zufrieden damit. Neue Devices kauf ich jetzt nur mehr HM.

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

Reinhart

@jamesgo

mir ist bei den Schreibversuchen via GAEBUS aufgefallen, dass du zwar alle Schreibvarianten von John berücksichtigt hast (sie werden auch bei "set" richtig angezeigt), aber schreiben kann ich nicht wirklich damit, da erfolgt dann eine Fehlermeldung.

Variante mit "wi" klappt bei mir nicht.
*wi,430#install,,,,"15","B509","0E",,,,,,
r;wi,,MaintenanceDate,nächste Wartung,,,,"5900",,,date,,,Datum nächste Wartung


Wenn ich die cvs auf nur "w" ändere, klappt auch das Schreiben!
r;w,,MaintenanceDate,nächste Wartung,,,,"5900",,,date,,,Datum nächste Wartung

Vielleicht kannst du den Fehler auch nachstellen.

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

jamesgo

Hallo Reinhart,

ja, dass mit den "wi" ist mir schon aufgefallen und ich hab das auch schon gefixt.

Werde die Version morgen einstellen.

Grüße
Andy

Reinhart

#49
Ich habe hier mit dem GAEBUS experimentiert um die Schreibfunktionen Anhand eines Beispiels "Wartungstermin setzen" zu testen. Ich habe eine Vaillant Therme mit einer VRC430, bei anderen Geräten kann das etwas abweichen. Es zeigt das Zusammenspiel zwischen Frontend und GAEBUS.

Zunächst müssen einige Vorbereitungen mit GAEBUS getroffen werden.

- über "set" die Variable "w~430~MaintenanceDate~nächste_Wartung" auswählen
- durch klicken auf "set" ein Attribut erzeugen
- diesem Attribut den Wert "nWartung" geben.
sollte dann so ausschauen: w~430~MaintenanceDate~nächste_Wartung nWartung

Mann sollte aber die aller Letzte Version von GAEBUS haben (die Andy heute veröffentlichen wird). Wenn nicht, dann sollte man im cvs File nachschauen ob der Wert dieser Variablen mit "w" geschrieben wird. Steht bei dir noch "wi", dann bitte entsprechend ändern.

so geht's nur bei der neuen Version
*wi,430#install,,,,"15","B509","0E",,,,,,
r;wi,,MaintenanceDate,nächste Wartung,,,,"5900",,,date,,,Datum nächste Wartung


und so auch bei der alten
*w,430,,,,"15","B509","0E",,,,,,
r;w,,MaintenanceDate,nächste Wartung,,,,"5900",,,date,,,Datum nächste Wartung



Wie funktioniert die Routine:

Es wird mit 2 Dummys gearbeitet. Der erste Dummy "Wartung" dient zur Eingabe des Datums. Es werden hier mit setlist die 3 Datumsfelder eingeben und ein Notify formatiert die Eingabefelder in das richtige Datumsformat und kopiert es in den state des 2 Dummy.
Der 2.Dummy wir deshalb benötigt, da im state des 1.Dummy ja nur das letzte Datumsfeld (eines von den 3) steht. Außerdem wird notify noch vor dem Schreiben von STATE ausgeführt. Im Anschluß wird mit set die Befehlszeile an GAEBUS übergeben. Theoretisch kann hier auch an ECMD übergeben werden, dann ist die Syntax der Befehslzeile anzupassen.

#################################
#       Wartungsdatum           #
#################################

define Wartung dummy
attr Wartung group Zeiteingabe
attr Wartung readingList TT MM JJJJ
attr Wartung room eBus
attr Wartung setList TT:01,02,03,04,05,06,07,08,09,10,12,13,14,15,16,17,18,19,20,21,22,23,24,25,26,27,28,29,30,31 MM:00,01,02,03,04,05,06,07,08,09,10,12 JJJJ:2015,2016,2017,2018,2019,2020,2021,2022,2023,2024,2025,2026,2027,2028,2029,2030
attr Wartung stateFormat {sprintf("%.2d.%.2d.%.4d", ReadingsVal($name,"TT",0), ReadingsVal($name,"MM",0), ReadingsVal($name,"JJJJ",0))}
attr Wartung webCmd TT:MM:JJJJ


# dieser Dummy wird benötigt um den Wert formatiert in den state zu schreiben.
define Wartungsdatum dummy
attr Wartungsdatum group Wartungsdatum
attr Wartungsdatum room eBus

# Datum in den Dummy kopieren
define Datentransfer notify Wartung {\
  fhem "set Wartungsdatum " . ReadingsVal("Wartung","TT",0) . "." . ReadingsVal("Wartung","MM",0) . "." . ReadingsVal("Wartung","JJJJ",0);;\
  fhem("set ebus1 nWartung ". ReadingsVal("Wartungsdatum","state",0));;\
}


Kontrolliert man das Logfile sollte sich folgender Inhalt zeigen:
Logfile:
2015.09.21 09:25:11 3: ebus1 execute w -c 430 MaintenanceDate 01.03.2016
2015.09.21 09:25:11 3: ebus1 answer w nWartung done
2015.09.21 09:25:11 3: set ebus1 nWartung 01.03.2016 : done
2015.09.21 09:25:11 3: Datentransfer return value: done


Am Display der Calormatic sollte dann das Wartungsdatum ebenfalls ablesbar sein.
Wer es ganz genau nimmt, der kann den Set Befehl vorher noch auf Plausibilität des Datums (Schaltjahr) überprüfen, ist aber fast schon Luxus. Viel Spaß beim Testen!

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

jamesgo

@All:

ich habe gerade eine neue Version mit folgende Erweiterungen hochgeladen:

- Schreibzugriff auf die Elemente die mit "wi" definiert (und damit mit "#install" geschützt sind)
- Verwendung von BlockingCall

Grüße
Andy

Jojo11

Wow, das ging schnell. Vielen Dank!

schöne Grüße
Jo


Reinhart

Danke Andy, habe "wi" gerade getestet und funktioniert perfekt!

hier das Log:
2015.09.21 16:00:02 3: ebus1: set w~430install~MaintenanceDate~nächste_Wartung
2015.09.21 16:00:16 2: called GAEBUS_Attr(set,ebus1,w~430install~MaintenanceDate~nächste_Wartung,<nWartung>)
2015.09.21 16:00:28 3: ebus1 execute w -c 430#install MaintenanceDate 01.01.2017
2015.09.21 16:00:28 3: ebus1 answer w nWartung done


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

Jojo11

#53
Zitat von: Reinhart am 21 September 2015, 10:42:29
Ich habe hier mit dem GAEBUS experimentiert um die Schreibfunktionen Anhand eines Beispiels "Wartungstermin setzen" zu testen. ...

Hallo Reinhart,

ziemlich genau so habe ich es für das Setzen der Urlaubszeiten auch gemacht, außer dass ich statt eines einzelnen dummies für das Datum immer drei nehmen musste. Das kommt daher, dass ich die Daten auch per smartVISU setzen möchte und ich dafür einen einzelnen Datums-dummy nicht wieder zerpflücken will.
Den Dummy habe ich dann noch mit clonedummy und FHEM2FHEM auf das Hauptsystem gespiegelt, so dass alles schön getrennt ist. Läuft bisher richtig gut.

schöne Grüße
Jo

Reinhart

@Jo

Im Prinzip ist es eh nur mehr Spielerei, weil ja GAEBUS eigentlich schon das Frontend ist. Ist die Variable einmal gesetzt, läßt sie sich ja schon komfortabel steuern. Das ist ja der wesentliche Vorteil von GAEBUS gegenüber ECMD. Lediglich die Eingabesyntax ist zu beachten und die nimmt halt ein setList schon vorab weg.

Ich nehme GAEBUS sehr gerne, für schnell mal was testen.

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

Reinhart

@Andy

ich habe seit der neuen Version nun festgestellt, das mit apptime der GAEBUS nicht einmal mehr sichtbar ist! Auch das Logging alle paar Sekunden hat sich nun normalisiert!

Super Arbeit!

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

nightstorm99

Zitat von: Jojo11 am 21 September 2015, 19:39:53
Hallo Reinhart,

ziemlich genau so habe ich es für das Setzen der Urlaubszeiten auch gemacht, außer dass ich statt eines einzelnen dummies für das Datum immer drei nehmen musste. Das kommt daher, dass ich die Daten auch per smartVISU setzen möchte und ich dafür einen einzelnen Datums-dummy nicht wieder zerpflücken will.
Den Dummy habe ich dann noch mit clonedummy und FHEM2FHEM auf das Hauptsystem gespiegelt, so dass alles schön getrennt ist. Läuft bisher richtig gut.

schöne Grüße
Jo

Hallo Jo,

könntest du zeigen wie du das mit den Zeiten gelöst hast?
Falls es Offtopic ist, gerne auch per PN.
Ich hatte heute ebenfalls angefangen damit. Ich kann jetzt alle Zeiten zwar einstellen, aber weiß noch
nicht wie ich das jetzt noch auf die Tage setze.
Das wären dann unzählige Dummys. Grrrrrrr

Danke und Gruß
Denny

Jojo11

Hallo Denny,

ich habe bisher nur jeweils das Datum für Urlaubsbeginn und Urlaubsende implementiert. Ich fürchte zum setzen aller Zeiten/Wochentage musst Du ziemlich viele Dummies definieren. Da bin ich aber noch nicht. Ich kann heute abend mal schauen.

schöne Grüße
Jo


Reinhart

Hallo Denny!

Jede Methode hat seine Vor- und Nachteile. Wenn du dir Dummys sparen willst, dann nutze doch setList und baue dir beliebig viele Eingabefelder in einer Zeile zusammen. Den Sendestring für GAEBUS kannst nach meinem Beispiel "Wartungsdatum" dann ebenso beliebig zusammen setzen.

Hier eine Beispiel Variante 1 mit getrennten HH MM Feldern und freier Zeitwahl:
define Mo_Fr dummy
attr Mo_Fr group Zeiteingabe Variante1
attr Mo_Fr readingList HH MM HH2 MM2
attr Mo_Fr room HeizProgramm
attr Mo_Fr setList HH:00,01,02,03,04,05,06,07,08,09,10,12,13,14,15,16,17,18,19,20,21,22,23 MM:00,05,10,15,20,25,30,35,40,45,50,55 HH2:00,01,02,03,04,05,06,07,08,09,10,12,13,14,15,16,17,18,19,20,21,22,23 MM2:00,05,10,15,20,25,30,35,40,45,50,55
attr Mo_Fr stateFormat HH:MM - HH2:MM2
attr Mo_Fr webCmd HH:MM: bis :HH2:MM2

define Sa_So dummy
attr Sa_So group Zeiteingabe Variante1
attr Sa_So readingList HH MM HH2 MM2
attr Sa_So room HeizProgramm
attr Sa_So setList HH:00,01,02,03,04,05,06,07,08,09,10,12,13,14,15,16,17,18,19,20,21,22,23 MM:00,05,10,15,20,25,30,35,40,45,50,55 HH2:00,01,02,03,04,05,06,07,08,09,10,12,13,14,15,16,17,18,19,20,21,22,23 MM2:00,05,10,15,20,25,30,35,40,45,50,55
attr Sa_So stateFormat HH:MM - HH2:MM2
attr Sa_So webCmd HH:MM: bis :HH2:MM2


Hier eine Beispiel Variante 2 mit getrennten von bis Feldern und fixen Zeitfenstern (30min):
define Mo_Fr2 dummy
attr Mo_Fr2 group Zeiteingabe Variante2
attr Mo_Fr2 readingList HHMM1 HHMM2
attr Mo_Fr2 room HeizProgramm
attr Mo_Fr2 setList HHMM1:00:00,00:30,01:00,01:30,02:00,02:30,03:00,03:30,04:00,04:30,05:00,05:30,06:00,06:30,07:00,07:30,08:00,08:30,09:00,09:30,10:00,10:30,11:00,11:30,12:00,12:30,13:00,13:30,14:00,14:30,15:00,15:30,16:00,16:30,17:00,17:30,18:00,18:30,19:00,19:30,20:00,20:30,21:00,21:30,22:00,22:30,23:00,23:30 HHMM2:00:00,00:30,01:00,01:30,02:00,02:30,03:00,03:30,04:00,04:30,05:00,05:30,06:00,06:30,07:00,07:30,08:00,08:30,09:00,09:30,10:00,10:30,11:00,11:30,12:00,12:30,13:00,13:30,14:00,14:30,15:00,15:30,16:00,16:30,17:00,17:30,18:00,18:30,19:00,19:30,20:00,20:30,21:00,21:30,22:00,22:30,23:00,23:30
attr Mo_Fr2 stateFormat HHMM1 - HHMM2
attr Mo_Fr2 webCmd HHMM1: bis :HHMM2

define Sa_So2 dummy
attr Sa_So2 group Zeiteingabe Variante2
attr Sa_So2 readingList HHMM1 HHMM2
attr Sa_So2 room HeizProgramm
attr Sa_So2 setList HHMM1:00:00,00:30,01:00,01:30,02:00,02:30,03:00,03:30,04:00,04:30,05:00,05:30,06:00,06:30,07:00,07:30,08:00,08:30,09:00,09:30,10:00,10:30,11:00,11:30,12:00,12:30,13:00,13:30,14:00,14:30,15:00,15:30,16:00,16:30,17:00,17:30,18:00,18:30,19:00,19:30,20:00,20:30,21:00,21:30,22:00,22:30,23:00,23:30 HHMM2:00:00,00:30,01:00,01:30,02:00,02:30,03:00,03:30,04:00,04:30,05:00,05:30,06:00,06:30,07:00,07:30,08:00,08:30,09:00,09:30,10:00,10:30,11:00,11:30,12:00,12:30,13:00,13:30,14:00,14:30,15:00,15:30,16:00,16:30,17:00,17:30,18:00,18:30,19:00,19:30,20:00,20:30,21:00,21:30,22:00,22:30,23:00,23:30
attr Sa_So2 stateFormat HHMM1 - HHMM2
attr Sa_So2 webCmd HHMM1: bis :HHMM2


hier dann noch einen notify der das Zwischenergebnis in den state kopiert definieren und den SendeString zusammen basteln, fertig. Auf diesen fertig zusammen gebauten state kannst auch von jedem anderen Programm wieder zugreifen. Ebenso kannst du dir in einem define 3 von bis Zeiten definieren, d.h. 6 Eingabefelder, Dummys brauchst deswegen dann nicht mehr davon.

Wenn du nicht mit Blockzeiten arbeiten willst, werden die define dann für jeden extra Tag mehr (statt 2 dann 7). Blockzeiten würde ich so gestalten, das du den Montag eingibst und dann auf die 5 Tagesregister bzw 2 Wochenendregister sendest. Das spart Arbeit.

LG
Reinhart

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

amunra

na ja, es gibt noch ein Block "Mo-So" - das nur als Hinweis.