Guten Abend,
ich versuche immer noch mit einem für mich vertretbaren Aufwand mein HB-Dis-EP-42BW mit FHEM ans Laufen zu kriegen. Da mein letzter Versuch (https://forum.fhem.de/index.php/topic,109254.msg1039235.html#msg1039235), das Ding direkt mit FHEM in Betrieb zu nehmen scheiterte, versuche ich es nun mit HMCCU. Dank des genialen Scripts (https://github.com/TomMajor/SmartHome/tree/master/HB-Dis-EP-42BW/Script_Helper) von TomMajor muss das Ding ja theoretisch noch nicht mal in FHEM über HMCCU eingerichtet sein, denn zur Ausgabe auf dem Display muss "nur" ein Einzeiler ausgeführt werden, z.B.:
system.Exec("tclsh /usr/local/addons/epaper42.tcl " # "JPDISEP000 /5 'Test ABC ÄÖÜäöüß' 1");
wobei nur "/5 'Test ABC ÄÖÜäöüß' 1" dynamisch ist, der Rest ist statisch, zumindest bei nur einem HB-Dis-EP-42BW im System.
Meine naive Vorstellung wäre nun, dass ich diese Zeichenkette in FHEM berechne und mittels HMCCU an die CCU zur Ausführung übergebe. Doch lt. Wiki muss das Script als Datei vorliegen, damit das an die CCU übergeben werden kann:
set d_ccu hmscript /opt/fhem/sysvars.scr
Versuche ich die Anweisung doch als Zeichenkette zu übergeben:
set d_ccu hmscript "system.Exec("tclsh /usr/local/addons/epaper42.tcl " # "JPDISEP000 /5 'Test ABC ÄÖÜäöüß' 1");"
sagt HMCCU:
HMCCU: d_ccu Usage: set d_ccu hmscript {file|!function|'['code']'} ['dump'] [parname=value [...]]
Auch Hochkommata und Doppelhochkommata anstelle der Anfürungszeichen funktionieren nicht, obwohl ich so die Ausgabe von HMCCU interpretieren würde. Kann es so funktionieren, wie ich es mir vorstelle? Wie müsste dann die Syntax lauten?
Danke schon mal!
Wenn, dann so:
set d_ccu hmscript [system.Exec("tclsh /usr/local/addons/epaper42.tcl JPDISEP000 /5 'Test ABC ÄÖÜäöüß' 1");]
HMScript Code in der Kommandozeile muss in [] angegeben werden. Vermutlich wird es wegen der " trotzdem nicht funktionieren, da FHEM diese interpretiert, bevor sie ans Modul übergeben werden.
Bzw. Versuche es erst mal ohne die Umlaute. Das bit garantiert Probleme.
Auch ohne Umlaute kommt leider
Unknown command ], try help.
Kann man die Anführungszeichen für FHEM irgendwie maskieren? Oder muss HMCCU dafür angepasst werden?
Kannst Du nicht ein Script-File mit Parametern verwenden?
Wenn ich mich rechte erinnere, werden Parameter mit $ eingeleitet, also:
system.Exec("tclsh /usr/local/addons/epaper42.tcl $Device /5 '$Text' 1");
und dann
set d_hccu hmscript <File> Device=JPDISEP000 Text="Test ABC"
Hm, sieht nach "Von hinten durch die Brust ins Auge" aus, aber wenn's funktioniert ;D
Ich werd's später versuchen, aber so wie ich das sehe, kann ich auch den kompletten Befehl als Parameter übergeben und in der Datei nur
$PARAM
stehen haben?
Dann bist Du aber wieder in der Hochkommahölle
Zitat von: zap am 08 April 2020, 20:45:54
Dann bist Du aber wieder in der Hochkommahölle
Das habe ich auch schon bemerkt :) Ich habe das jetzt so gelöst, in der scr-Datei steht Folgendes:
system.Exec("tclsh /usr/local/addons/epaper42.tcl $Device $Text");und in FHEM rufe ich auf
set d_hccu hmscript <File> Device=JPDISEP000 Text="/5 'Test ABC' 1" Damit sollte ich alles abbilden können, was ich mir vorgestellt habe und was das Display und TomMajors Script so hergibt. Zugegeben, ich habe noch nicht alle möglichen Parameter- und Sonderzeichenkombinationen ausprobiert, aber das ergibt sich dann, Learning by Doing :) Das Nonplusultra wäre, wenn ich mit einem Aufruf auch mehrere Zeilen setzen könnte, wie TomMajors Script das ja auch unterstützt:
usage: epaper42 serial /line text [icon number] [/nextline text [icon number]] ...D.h. im Prinzip würde ich gerne Folgendes in FHEM aufrufen (zum Beispiel):
set d_hccu hmscript <File> Device=JPDISEP000 Text%1="/5 'Test ABC' 1" Text%2="/6 'Test XYZ' 2"Wie müsste die dazugehörige scr-Datei aussehen? Ich weiss, die Frage ist nicht mehr HMCCU-spezifisch, aber vielleicht ist sie doch hier am Besten aufgehoben, wg. dem Kontext.
@zap: Danke für das HMCCU-Modul und Deine Unterstützung!
Muss ich mal drüber nachdenken ...
Andere Frage: inwiefern unterscheidet sich die Ansteuerung des Displays von HM Dis-EP-WM55?
Falls es sich nicht unterscheidet, könnte ich es kurzfrisitg direkt in HMCCU unterstützen?
Zitat von: zap am 09 April 2020, 07:15:28
Andere Frage: inwiefern unterscheidet sich die Ansteuerung des Displays von HM Dis-EP-WM55?
Falls es sich nicht unterscheidet, könnte ich es kurzfrisitg direkt in HMCCU unterstützen?
Nach Jerome's Aussage so gut wie gar nicht: https://forum.fhem.de/index.php/topic,73954.msg962094.html#msg962094 (https://forum.fhem.de/index.php/topic,73954.msg962094.html#msg962094).
Aber würde sich dann irgendwas bzgl. der Ansteuerung ändern? Oder Würde man dann TomMajors-Script quasi nach FHEM reinziehen und HMCCU nur noch fertige HM-Messages übergeben und hätte den Salat mit den Anführungszeichen nicht?
Du brauchst das Script dann gar nicht mehr. Die Parameter (Texte, Farben, Icons) werden einfach per Set Befehl übergeben. Das Script wird benötigt, um die Angaben in ein Display-Konformes Format zu wandeln. Das macht dann HMCCU, wie jetzt schon bei dem anderen Display.
Ich trage mal den Typ in HMCCU nach und du kannst dann testen, ob es einfach so ohne weitere Anpassung funktioniert.
Guten Abend,
ich habe mein HB-DIS-EP-42BW seit einiger Zeit mit FHEM im Betrieb, im Prinzip genau so, wie hier (https://forum.fhem.de/index.php/topic,109968.msg1040009.html#msg1040009) beschrieben. Da die direkte FHEM-Unterstützung trotz einiger Nachfragen wohl nicht geplant ist, könnte ich zufrieden sein, wenn nicht ein Problem wäre: ich habe sporadische Verbindungsstörungen zwischen der CCU und dem Display. Das bekomme ich aber nur mit, wenn ich mich mal wieder auf die Weboberfläche der CCU verirre oder wenn ich mal wieder einen falschen Status auf dem Display sehe. Leider bekommt FHEM nicht mit, wenn das tcl-Script auf der CCU auf eine Störung läuft. Da ich einige Status nur sehr selten aktualisiere, bleiben sie u.U. sehr lange falsch.
Zitat von: zap am 10 April 2020, 08:55:18
Ich trage mal den Typ in HMCCU nach und du kannst dann testen, ob es einfach so ohne weitere Anpassung funktioniert.
Ist das schon geschehen? Würde mir diese Integration bei meinem Problem helfen? Oder gibt es irgendeinen anderen Mechanismus, um die Störung zu detektieren und das Script ggf. erneut auszuführen?
Ist noch nicht integriert. Du kannst das Gerät aber trotzdem mit HMCCUDEV oder HMCCUCHN in FHEM anlegen. In Kanal 0 hast Du dann die Standard Datenpunkte wie UNREACH usw und bekommst es mit, wenn das Gerät nicht erreichbar ist.
Guten Abend,
ich habe mein Display heute endlich per HMCCU in FHEM angebunden. Hauptsächlich um die Verbindungsprobleme mitzubekommen, aber auch um die Tasterkanäle nutzen zu können.
Ich bin ein ziemlicher Anfänger in Sachen HMCCU und hätte eigentlich erwartet, dass spätestens nach
ccureadingfilter .*
alle Datenpunkte angezeigt werden, doch das scheint nicht der Fall zu sein?! Jedenfalls sind erst die 0-Datenpunkte angelegt worden, aber nicht die 1-11-Datenpunkte. Erst nachdem ich die Taster 1-10 kurz und lang betätigt habe, kamen auch die entsprechenden Datenpunkte an. Allerdings fehlt der Datenpunkt 11.SUBMIT aber auch 0.UNREACH.
Ich habe nun künstlich für ein Verbindungsproblem gesorgt, in der Hoffnung, dass wenigstens 0.UNREACH auf diese Art noch nachkommt, leider vergeblich. An folgenden Datenpunkten/Readings hat sich dann aber was geändert:
0.STICKY_UNREACH 1
activity dead
hmstate unreachable
Wo kommen denn die "activity" und "hmstate" her? Was ist der Unterschied zw. 0.UNREACH und 0.STICKY_UNREACH? Ist vermutlich nicht HB-Dis-EP-42BW spezifisch, oder?
Ich bin im Moment noch etwas ratlos, wie ich in meinen DOIFs die Verbindungsprobleme abfangen und darauf reagieren soll. Einfach noch mal senden? Solange bis es klappt? Oder auf die Änderung von einem der 3 Datenpunkten/Readings warten (oder einer Kombination von denen)?
Sorry, viele Fragen, die hier teilweise OT sind, sollte das noch weitern ausufern, werde ich einen neuen Thread aufmachen.
Edit:
Nachdem das Verbindungsproblem "behoben" ist, sieht die Kombination so aus:
0.STICKY_UNREACH 1
activity alive
hmstate Initialized
0.STICKY_UNREACH ist also eher nicht zu gebrauchen.
Ein list vom Device wäre hilfreich.
Sticky Unreach bedeutet: Das Gerät war nicht erreichbar.
Hier das List:
Internals:
CFGFN
DEF 4CZ0VF0VOG
FUUID 5efa4493-f33f-7a7c-b7e5-11dd2ce1b29d9f22
IODev myHMCCU
NAME ePaper_1
NR 2097
STATE Initialized
TYPE HMCCUDEV
ccuaddr 4CZ0VF0VOG
ccudevstate active
ccuif BidCos-RF
ccuname ePaper_1
ccutype HB-DIS-EP-42BW
channels 12
statevals devstate
READINGS:
2020-06-29 21:57:10 0.AES_KEY off
2020-06-29 21:57:10 0.CONFIG_PENDING false
2020-06-29 21:57:10 0.DEVICE_IN_BOOTLOADER false
2020-06-29 21:57:10 0.RSSI_DEVICE 183
2020-06-29 21:57:10 0.RSSI_PEER 60
2020-06-30 03:15:02 0.STICKY_UNREACH 1
2020-06-29 21:57:10 0.UPDATE_PENDING false
2020-06-29 22:40:11 1.INSTALL_TEST 1
2020-06-29 22:24:40 1.PRESS_CONT 1
2020-06-29 22:24:39 1.PRESS_LONG 1
2020-06-29 22:24:40 1.PRESS_LONG_RELEASE 1
2020-06-29 22:40:11 1.PRESS_SHORT 1
2020-06-29 22:25:02 10.INSTALL_TEST 1
2020-06-29 22:25:03 10.PRESS_CONT 1
2020-06-29 22:25:02 10.PRESS_LONG 1
2020-06-29 22:25:03 10.PRESS_LONG_RELEASE 1
2020-06-29 22:24:19 10.PRESS_SHORT 1
2020-06-29 22:24:41 2.INSTALL_TEST 1
2020-06-29 22:24:43 2.PRESS_CONT 1
2020-06-29 22:24:41 2.PRESS_LONG 1
2020-06-29 22:24:43 2.PRESS_LONG_RELEASE 1
2020-06-29 22:24:05 2.PRESS_SHORT 1
2020-06-29 22:24:44 3.INSTALL_TEST 1
2020-06-29 22:24:45 3.PRESS_CONT 1
2020-06-29 22:24:44 3.PRESS_LONG 1
2020-06-29 22:24:45 3.PRESS_LONG_RELEASE 1
2020-06-29 22:24:07 3.PRESS_SHORT 1
2020-06-29 22:24:47 4.INSTALL_TEST 1
2020-06-29 22:24:48 4.PRESS_CONT 1
2020-06-29 22:24:47 4.PRESS_LONG 1
2020-06-29 22:24:48 4.PRESS_LONG_RELEASE 1
2020-06-29 22:24:09 4.PRESS_SHORT 1
2020-06-29 22:24:49 5.INSTALL_TEST 1
2020-06-29 22:24:50 5.PRESS_CONT 1
2020-06-29 22:24:49 5.PRESS_LONG 1
2020-06-29 22:24:50 5.PRESS_LONG_RELEASE 1
2020-06-29 22:24:10 5.PRESS_SHORT 1
2020-06-29 22:24:51 6.INSTALL_TEST 1
2020-06-29 22:24:53 6.PRESS_CONT 1
2020-06-29 22:24:51 6.PRESS_LONG 1
2020-06-29 22:24:53 6.PRESS_LONG_RELEASE 1
2020-06-29 22:24:12 6.PRESS_SHORT 1
2020-06-29 22:24:54 7.INSTALL_TEST 1
2020-06-29 22:24:55 7.PRESS_CONT 1
2020-06-29 22:24:54 7.PRESS_LONG 1
2020-06-29 22:24:55 7.PRESS_LONG_RELEASE 1
2020-06-29 22:24:14 7.PRESS_SHORT 1
2020-06-29 22:24:57 8.INSTALL_TEST 1
2020-06-29 22:24:58 8.PRESS_CONT 1
2020-06-29 22:24:56 8.PRESS_LONG 1
2020-06-29 22:24:58 8.PRESS_LONG_RELEASE 1
2020-06-29 22:24:15 8.PRESS_SHORT 1
2020-06-29 22:24:59 9.INSTALL_TEST 1
2020-06-29 22:25:01 9.PRESS_CONT 1
2020-06-29 22:24:59 9.PRESS_LONG 1
2020-06-29 22:25:01 9.PRESS_LONG_RELEASE 1
2020-06-29 22:24:18 9.PRESS_SHORT 1
2020-06-29 21:46:11 R-DEVICE_LED_MODE 1
2020-06-29 21:46:11 R-DISPLAY_INVERTING 0
2020-06-29 21:46:11 R-HB_CRITICAL_BAT_LIMIT 1.000000
2020-06-29 21:46:11 R-HB_DISPLAY_REFRESH_WAIT_TIME 0.000000
2020-06-29 21:46:11 R-KEY_TRANSCEIVER 0
2020-06-29 21:46:11 R-LOW_BAT_LIMIT 1.000000
2020-06-29 21:46:11 R-POWERUP_ACTION 0
2020-06-30 03:15:02 activity alive
2020-06-29 21:57:10 battery ok
2020-06-30 03:15:02 hmstate Initialized
2020-06-29 21:44:19 state Initialized
hmccu:
devspec 4CZ0VF0VOG
dp:
0.AES_KEY:
OSVAL off
OVAL 0
SVAL off
VAL 0
0.CONFIG_PENDING:
OSVAL false
OVAL false
SVAL false
VAL false
0.DEVICE_IN_BOOTLOADER:
OSVAL false
OVAL false
SVAL false
VAL false
0.LOWBAT:
OSVAL ok
OVAL false
SVAL ok
VAL false
0.RSSI_DEVICE:
OSVAL 183
OVAL 183
SVAL 183
VAL 183
0.RSSI_PEER:
OSVAL 60
OVAL 60
SVAL 60
VAL 60
0.STICKY_UNREACH:
OSVAL 1
OVAL 1
SVAL 1
VAL 1
0.UNREACH:
OSVAL dead
OVAL 1
SVAL alive
VAL 0
0.UPDATE_PENDING:
OSVAL false
OVAL false
SVAL false
VAL false
1.INSTALL_TEST:
OSVAL 1
OVAL 1
SVAL 1
VAL 1
1.PRESS_CONT:
OSVAL 1
OVAL 1
SVAL 1
VAL 1
1.PRESS_LONG:
OSVAL 1
OVAL 1
SVAL 1
VAL 1
1.PRESS_LONG_RELEASE:
OSVAL 1
OVAL 1
SVAL 1
VAL 1
1.PRESS_SHORT:
OSVAL 1
OVAL 1
SVAL 1
VAL 1
10.INSTALL_TEST:
OSVAL 1
OVAL 1
SVAL 1
VAL 1
10.PRESS_CONT:
OSVAL 1
OVAL 1
SVAL 1
VAL 1
10.PRESS_LONG:
OSVAL 1
OVAL 1
SVAL 1
VAL 1
10.PRESS_LONG_RELEASE:
OSVAL 1
OVAL 1
SVAL 1
VAL 1
10.PRESS_SHORT:
OSVAL 1
OVAL 1
SVAL 1
VAL 1
2.INSTALL_TEST:
OSVAL 1
OVAL 1
SVAL 1
VAL 1
2.PRESS_CONT:
OSVAL 1
OVAL 1
SVAL 1
VAL 1
2.PRESS_LONG:
OSVAL 1
OVAL 1
SVAL 1
VAL 1
2.PRESS_LONG_RELEASE:
OSVAL 1
OVAL 1
SVAL 1
VAL 1
2.PRESS_SHORT:
OSVAL 1
OVAL 1
SVAL 1
VAL 1
3.INSTALL_TEST:
OSVAL 1
OVAL 1
SVAL 1
VAL 1
3.PRESS_CONT:
OSVAL 1
OVAL 1
SVAL 1
VAL 1
3.PRESS_LONG:
OSVAL 1
OVAL 1
SVAL 1
VAL 1
3.PRESS_LONG_RELEASE:
OSVAL 1
OVAL 1
SVAL 1
VAL 1
3.PRESS_SHORT:
OSVAL 1
OVAL 1
SVAL 1
VAL 1
4.INSTALL_TEST:
OSVAL 1
OVAL 1
SVAL 1
VAL 1
4.PRESS_CONT:
OSVAL 1
OVAL 1
SVAL 1
VAL 1
4.PRESS_LONG:
OSVAL 1
OVAL 1
SVAL 1
VAL 1
4.PRESS_LONG_RELEASE:
OSVAL 1
OVAL 1
SVAL 1
VAL 1
4.PRESS_SHORT:
OSVAL 1
OVAL 1
SVAL 1
VAL 1
5.INSTALL_TEST:
OSVAL 1
OVAL 1
SVAL 1
VAL 1
5.PRESS_CONT:
OSVAL 1
OVAL 1
SVAL 1
VAL 1
5.PRESS_LONG:
OSVAL 1
OVAL 1
SVAL 1
VAL 1
5.PRESS_LONG_RELEASE:
OSVAL 1
OVAL 1
SVAL 1
VAL 1
5.PRESS_SHORT:
OSVAL 1
OVAL 1
SVAL 1
VAL 1
6.INSTALL_TEST:
OSVAL 1
OVAL 1
SVAL 1
VAL 1
6.PRESS_CONT:
OSVAL 1
OVAL 1
SVAL 1
VAL 1
6.PRESS_LONG:
OSVAL 1
OVAL 1
SVAL 1
VAL 1
6.PRESS_LONG_RELEASE:
OSVAL 1
OVAL 1
SVAL 1
VAL 1
6.PRESS_SHORT:
OSVAL 1
OVAL 1
SVAL 1
VAL 1
7.INSTALL_TEST:
OSVAL 1
OVAL 1
SVAL 1
VAL 1
7.PRESS_CONT:
OSVAL 1
OVAL 1
SVAL 1
VAL 1
7.PRESS_LONG:
OSVAL 1
OVAL 1
SVAL 1
VAL 1
7.PRESS_LONG_RELEASE:
OSVAL 1
OVAL 1
SVAL 1
VAL 1
7.PRESS_SHORT:
OSVAL 1
OVAL 1
SVAL 1
VAL 1
8.INSTALL_TEST:
OSVAL 1
OVAL 1
SVAL 1
VAL 1
8.PRESS_CONT:
OSVAL 1
OVAL 1
SVAL 1
VAL 1
8.PRESS_LONG:
OSVAL 1
OVAL 1
SVAL 1
VAL 1
8.PRESS_LONG_RELEASE:
OSVAL 1
OVAL 1
SVAL 1
VAL 1
8.PRESS_SHORT:
OSVAL 1
OVAL 1
SVAL 1
VAL 1
9.INSTALL_TEST:
OSVAL 1
OVAL 1
SVAL 1
VAL 1
9.PRESS_CONT:
OSVAL 1
OVAL 1
SVAL 1
VAL 1
9.PRESS_LONG:
OSVAL 1
OVAL 1
SVAL 1
VAL 1
9.PRESS_LONG_RELEASE:
OSVAL 1
OVAL 1
SVAL 1
VAL 1
9.PRESS_SHORT:
OSVAL 1
OVAL 1
SVAL 1
VAL 1
Attributes:
IODev myHMCCU
ccureadingfilter .*
ccureadingformat datapoint
event-on-update-reading .*
room Flur_OG
Diese Stelle
0.UNREACH:
OSVAL dead
OVAL 1
SVAL alive
VAL 0
lässt mich vermuten, dass hier offenbar automatisch eine Ersetzung stattfindet von "0.UNREACH" nach "activity"?
wie sehen denn die Attribute vom I/O device aus? (Bitte kein list, das wird zu lang).
OK, jetzt wird mir einiges klar, zumindest was "0.UNREACH" und Ersetzung angeht:
Attributes:
ccudef-readingfilter .*
ccudef-readingname ^(.+\.)?LOW_?BAT$:battery;^(.+\.)?UNREACH$:activity
ccudef-substitute AES_KEY!(0|false):off,(1|true):on;LOWBAT,LOW_BAT!(0|false):ok,(1|true):low;UNREACH!(0|false):alive,(1|true):dead;MOTION!(0|false):noMotion,(1|true):motion;DIRECTION!0:stop,1:up,2:down,3:undefined;WORKING!0:false,1:true;INHIBIT!(0|false):unlocked,(1|true):locked
ccuflags procrpc
cmdIcon on:general_an off:general_aus
eventMap /rpcserver on:on/rpcserver off:off/
room VCCU
rpcinterfaces BidCos-RF,HmIP-RF
rpcport 2001,2010
rpcserver on
stateFormat rpcstate/state
Ich habe mal die Definition vor ca. 2 Jahren mehr oder weniger 1:1 aus dem Wiki oder aus dem Forum übernommen und mich nie wieder damit befasst.
Aber was ist mit "11.SUBMIT"?
Schau Dir mal die Ausgabe von "get deviceinfo" an. Ich nehme an, hinter dem SUBMIT steht nur ein W. Das steht für Write, d.h. dieser Datenpunkt ist nur beschreibbar. Wenn dort ein E für Event oder R für Read steht, gibt es auch Readings.
OK, dort steht in der Tat nur ein "W". Danke für Deine Geduld, es scheinen nun alle Fragen bzgl. der Einrichtung geklärt zu sein. Kannst Du absehen, ob Du je dazu kommst, die Funktion zum Befüllen des Displays ohne Umweg über hmscript zu implementieren?
Kannst Du mir hier auch noch einen Tipp geben:
ZitatIch bin im Moment noch etwas ratlos, wie ich in meinen DOIFs die Verbindungsprobleme abfangen und darauf reagieren soll.
Im Moment befülle ich mit hmscript, bei Verbindungsproblemen springt das Ding auf "dead", d.h. im selben DOIF nach 2-3 s den Status prüfen und gegebenenfalls das Senden alle 10 Min wiederholen? Hört sich das nach einer vernünftigen Vorgehensweise? Oder gibt es was eleganteres in Verbindung mit HMCCU?