Firmware zu CUL, CUNX und Co. mit Timestamp Option ASKSIN tsculfw V0.41

Begonnen von noansi, 09 Juni 2014, 19:16:01

Vorheriges Thema - Nächstes Thema

noansi

Hallo Dog,

ZitatDie beiden USB Geräte (CUL und ZWDongle) habe doch tatsächlich nach Flashen Deiner Firmware die devs getauscht und nach Flashen der 1.66er wieder zurück!?
Das liegt dann vermutlich an der Seriennummer, die ich der Firmware mitgegeben habe. Dafür hat das Feature bei richtiger Nutzung auch seine Vorteile bei mehreren CULs im System.

ZitatKann ich das später auf ein sinnvolles Maß reduzieren (verbose ist 3).
Wenn Du verbose 3 nicht benötigst, dann einfach reduzieren auf 2 oder weniger.

Gruß, Ansgar.

dog_martin

Moin Ansgar,

habe das zweite Display jetzt tatsächlich vollständig pairen können.
Ein getConfig läuft jedoch immer noch nicht vollständig ohne einen RESPONSE TIMEOUT (register oder peer read) durch.

Merkwürdigerweise hat Display Nr. 1 damit gar keine Probleme...
(Kann das eigentlich allein durch Bauteiltoleranzen verursacht werden?)

Ich habe einige (für mich) neue CUL Attribute gesehen.
Was bedeuten diese und die diversen neuen LOG Parameter genau?
(bspw: dhmSt, dHMtgt, dDly, tgtDly, toms, CCAdly, hmSioDly)

Und, an welchen Parametern kann/sollte ich schrauben um vielleicht eine Verbesserung herbei zu führen?
(Gibt es eine Doku, die ich noch nicht gefunden habe?)

Vielen Dank im Voraus!

noansi

#212
Hallo Dog,

ZitatMerkwürdigerweise hat Display Nr. 1 damit gar keine Probleme...
(Kann das eigentlich allein durch Bauteiltoleranzen verursacht werden?)
Gleiche Firmware Version? Abstand / Hindernisse / Ausrichtung zu CUL (Funkprobleme)? Störsender? Lötfehler?

ZitatEin getConfig läuft jedoch immer noch nicht vollständig ohne einen RESPONSE TIMEOUT (register oder peer read) durch.
Dann bitte ein Log mit
attr global mseclog 1
verbose 4 für den CUL und das device für solch einen getConfig.
Ausserdem ein list von CUL und dem device.
Welche 10_CUL_HM.pm verwendest Du?

dhmSt:     Zeitdifferenz auf CUL zwischen letztem Empfang vom device und dem Senden der Nachricht/Antwort
dHMtgt:    Ziel für die Zeitdifferenz, idealerweise sollte dhmSt diesen Wert annehmen
toms:       Sendeverzögerung an CUL auf FHEM Seite (Sendewarteschlange wird Timerbasiert abgearbeitet)
CCAdly:    zusätzliche Sendeverzögerung auf CUL verursacht durch Kanalbelegung
hmSioDly: Aus Kommunikation mit CUL, Sendequittungen etc. ermittelte Restverzögerung des IO zu CUL

ZitatGibt es eine Doku,
Es gibt diesen Thread und den Code.

ZitatUnd, an welchen Parametern kann/sollte ich schrauben um vielleicht eine Verbesserung herbei zu führen?
Ohne Log und Lists gibt die Glaskugel leider gar nichts her.  ;)
Ich weiss bisher nur, dass Du einen CUL V3.4 an einem Linux basierten System verwendest und Probleme bei Pairing und getConfig mit Displays hast. (device Hardware, die keinen Typ hat und die ich selber auch nicht besitze)

Gruß, Ansgar.

noansi

Hallo Dog,

ich habe meine Glaskugel jetzt hier https://forum.fhem.de/index.php/topic,56839.msg483271.html#msg483271 etwas erhellen können. (Wäre nett und hilfreich gewesen, mir einen Link auf diesen Thread mitzuteilen)

Es ist möglich, dass sich die letzte Änderung von Martin bezüglich des Pairings, die wegen eines anderen Problemdevices (HM-Sen-DB-PCB) eingeflossen ist, jetzt bei dem Display HM-Dis-WM55 negativ bemerkbar macht.

Gruß, Ansgar.

dog_martin

Hi Ansgar,

vielen Dank für Deine Bemühungen und einmal mehr für Deine Suche nach meinem anderen Thread!!

Ich verlange gar keine mundgerechte Lösung für mein Problem. Vielmehr bin ich es gewohnt selbst nach Lösungen zu suchen und Fehler zu beseitigen. Deswegen meine Frage nach den Parametern und deren Auswirkungen.

Und - für mich - selbstverständlich habe ich mich bereits selbst auf die Suche nach den Unterschieden beider Displays gemacht und kann sämtliche von Dir genannten Fehlermöglichkeiten mit Sicherheit  (Lötfehler, Funkprobleme, Standort, Ausrichtung) oder an Sicherheit grenzender Wahrscheinlichkeit (Störsender) ausschliessen.

Zum Test habe ich BEIDE Displays an identischen Orten und derselben Firmware (1.0) unter identischen Bedingungen in Betrieb genommen.
Mit unterschiedlichen Ergebnissen. Selbst nach Austausch des zweiten vermeintlich defekten Displays.

Die Suche nach den Unterschieden beider Displays erachte ich momentan jedoch als nebensächlich.
Der derzeitige Funktionszustand ist zwar nicht 100%, aber für mich erst einmal ausreichend funktional.

Aus Interesse würde ich das in den nächsten Tagen gerne noch etwas verbessern.
Insbesondere der RESPONSE TIMEOUT fordert mich heraus...

Ich würde mich freuen, nochmals von Dir zu hören, wenn ich demnächst mit etwas detaillierteren Infos hier eintreffe.

Ein grosses DANKE aus Solingen!
Bernd

noansi

Hallo Bernd,

ZitatDeswegen meine Frage nach den Parametern und deren Auswirkungen.
Es gibt zwar noch Timing Parameter, an denen man drehen kann, aber das erst auf Basis eines aussagekräftigen Logs, da es sonst nur zielloses Probieren ist.

ZitatZum Test habe ich BEIDE Displays an identischen Orten und derselben Firmware (1.0) unter identischen Bedingungen in Betrieb genommen.
OK das war gut so.
Aber zu deutlich unterschiedlichen Zeitpunkten mit FHEM Update(s) dazwischen, richtig?

ZitatIch würde mich freuen, nochmals von Dir zu hören, wenn ich demnächst mit etwas detaillierteren Infos hier eintreffe.
Nur aussagekräftige Logs helfen hier weiter. Mit meiner Firmware Variante und meinen geänderten FHEM Modulen bekomme ich sinnvolle Timing Infos.
Ggf. kann ich Protkollprobleme sehen, so weit ich sie verstehe. Zur Zeit vermute ich eher Protokollprobleme aus Deinen Log Auszügen.

Gruß, Ansgar.

dog_martin

Hi Ansgar,

nein, bei Erstinbetriebnahme lagen schon ca. 14 Tage zwischen Display Nr. 1 und Nr. 2.
Ich nahm ebenfalls zunächst eine Änderung in den Updates als Ursache an.

Habe dann aber gestern mit diversen Backups aus dem relevanten Zeitraum getestet und habe immer ein unterschiedliches Verhalten beobachten können. Auch zuletzt mit Deiner FW und den geänderten Modulen.

Nr. 1 begann unmittelbar nach Tastendruck mit der Übertragung (Wow - das war zuvor nie der Fall) Nr. 2 lässt sich mehrere Sekunden Zeit mit dem Start, überträgt dann einige Sekunden und ein wenig später gibt's dann den Timeout.

Aber wie angekündigt lasse ich dieses WE erst einmal die Finger von einer zumindest einsatzbereiten Konfiguration - bin froh das es dank Deiner Software funktioniert.

Nächstes WE werde ich dann gerne ein paar aussagekräftige Infos liefern und vielleicht gibt es eine Möglichkeit noch etwas zu verbessern.

LG Bernd

noansi

Hallo Bernd,

Zitatnein, bei Erstinbetriebnahme lagen schon ca. 14 Tage zwischen Display Nr. 1 und Nr. 2.
am 14.8.16 hat Martin das Pairing Verhalten von 10_CUL_HM.pm mit Blick auf den Klingelsensor geändert.
War Display 1 da schon erfolgreich gepaired mit samt erfolgreichem getConfig?
Wenn ich Dein Thread Datum betrachte, müsste es so gewesen sein.

ZitatNr. 1 begann unmittelbar nach Tastendruck mit der Übertragung (Wow - das war zuvor nie der Fall) Nr. 2 lässt sich mehrere Sekunden Zeit mit dem Start, überträgt dann einige Sekunden und ein wenig später gibt's dann den Timeout.
Ein klein wenig Hintergrundwissen zum Protkoll und Martins Programmierung ist von Vorteil bei der Interpretation.

In Deinen Log Auszügen im Thread quaselt auch schon mal ein anderes Device dazwischen. Da Martin die verschiedenen Sendedaten nachdem Empfang des Request in einen Sendepuffer schiebt und die nach Empfang von Antworten (nicht unbedingt der wirklich passenden) dann nacheinander rausgeschocben werden, ist so ein dazwischen quaseln kontraproduktiv, da dabei die Protokollinterpretation meistens "divergiert" und auch das Timing zwangsweise durcheinander kommt (Display schläft schon wieder).
Daher kann Deine Interpretation bei zu seltener Wiederholung des Experiments und ohne Interpretation der Details (Logs) deutilich schief gehen. ;)

Gruß, Ansgar.

noansi

#218
Diese Version ist veraltet und die letzte wo 00_TSCUL.pm das wesentliche Timing macht.
Hier https://forum.fhem.de/index.php/topic,24436.msg529649.html#msg529649 geht es zu aktuellen Version.

Hallo Testwillige,

da die Integration in die "offizielle" Firmware und FHEM wegen Komplexität der mittlerweile aufgelaufenen Änderungen wohl nichts mehr werden wird, habe ich eine "AddOn" Lösung gebaut, die "Wartungsfreundlicher" ist, da sie quasi neben der normalen FHEM Installation laufen kann, wenn Rudolf und Martin ein paar kleine Änderungen übernehmen. Damit dann eine "updateresistente" Lösung.

Im Anhang ist in culfw-code-459-trunk_lufa_rf_cr_sd_79_7.zip wieder die unveränderte Timestamp Firmware zu finden.
Ergänzender Hinweis: Nach dem flashen von CUL kann es sein, dass das Betriebssystem CUL eine neue Schnittstelle zuweist und ggf. auch anderen USB devices. Auf Linux mit "dmesg" heraus zu lesen. Auch beim Neustart des Systems kann sich die Reihenfolge ändern. Bei meinem Raspi sogar abhängig von der Startart Reboot oder Einschalten.

In der FHEM_module_changed_TS_9.zip sind die neuen und geänderten Module zu finden.

00_TSCUL.pm         -> statt der 00_CUL.pm, aus CUL devices werden damit TSCUL devices in der fhem.cfg (händisch anzupassen)
DevIoTS.pm            -> verbesserte Version von DevIo.pm für die TS Module
CUL_Util.pm            -> Hilfsfunktionen, um CUL Typen abzufragen, für "Mischbetrieb"
16_TSSTACKED.pm -> statt der 16_STACKABLE_CC.pm, aus STACKABLE_CC werden damit TSSTACKED devices in der fhem.cfg (händisch anzupassen)

10_TSIT.pm            -> statt der 10_IT.pm, mit TSCUL oder TSSTACKED IO-devices zu verwenden, aus IT wird dann TSIT in der fhem.cfg (händisch anzupassen)
10_UNIRoll_TS.pm  -> statt der 10_UNIRoll.pm, mit TSCUL oder TSSTACKED IO-devices zu verwenden, aus UNIRoll wird dann UNIRoll_TS  in der fhem.cfg (händisch anzupassen)
13_TSKS300.pm     -> statt der 13_KS300.pm, mit TSCUL oder TSSTACKED IO-devices zu verwenden, aus TSKS300 wird dann TSKS300  in der fhem.cfg (händisch anzupassen)
14_TSCUL_TX.pm    -> statt der 14_CUL_TX.pm, mit TSCUL oder TSSTACKED IO-devices zu verwenden, aus CUL_TX wird dann TSCUL_TX  in der fhem.cfg (händisch anzupassen)
14_TSCUL_WS.pm   -> statt der 14_CUL_WS.pm, mit TSCUL oder TSSTACKED IO-devices zu verwenden, aus CUL_WS wird dann TSCUL_WS  in der fhem.cfg (händisch anzupassen)
CalcUtil.pm               -> Hilfsrechenroutinen für Taupunkt und Windstärkeindex

Da diese Module ergänzt werden, überleben sie auch ein Update von FHEM.

Für einen Mischbetrieb mit non-Timestamp CUL Modulen muss auch die 00_CUL.pm und 16_STACKABLE_CC.pm ausgetauscht werden, was ggf. bei gestapelten Modulen notwendig ist.

@Rudolf: Nur $clientsSlowRF etc und die Abfragen bezüglich CUL Typ sind angepasst gegenüber der "Standard" Version und werden mit Funktionen aus CUL_Util.pm gebildet -> damit leicht wartbar bei Änderungen und Ergänzungen. Die Änderungen sind mit "# ToDo TSCUL" markiert.
Kannst Du damit leben und das bitte in die Standard Version einfließen lassen? Danke!

10_CUL_HM.pm muss ebenfalls ausgetauscht werden, bis @Martin die Änderung in den Standard übernommen hat. Auch hier wird auf CUL_Util.pm zurück gegriffen, um den CUL Typ abzufragen. (Außerdem noch eine kleine Änderung zum PairRequest bezüglich Unterdrückung von Wiederholungen)

Wie immer, vor Austausch und Veränderungen der fhem.cfg, erst Backup dann Ändern!

Mit folgendem Eintrag (oder Ergänzung des attributs) in der fhem.cfg kann man das fhem update am ungewollten Austausch der angepassten Module hindern:
attr global exclude_from_update 00_CUL.pm 10_CUL_HM.pm 16_STACKABLE_CC.pm 00_TSCUL.pm 16_TSSTACKED.pm DevIoTS.pm CUL_Util.pm 10_TSIT.pm 10_UNIRoll_TS.pm 13_TSKS300.pm 14_TSCUL_TX.pm 14_TSCUL_WS.pm CalcUtil.pm

Hier https://forum.fhem.de/index.php/topic,24436.msg501057.html#msg501057 noch Rudolfs Tip zur Aktualisierung des Commandref  nach dem Kopieren/Austausch der Dateien so dass dann auch Doku zur Nutzung zu lesen ist.
fhem> { `perl contrib/commandref_join.pl` }

Gruß, Ansgar.

EDIT: FHEM_module_changed_TS_9.zip enthält aktualisierte TS-Module. Die Modul HTML Doku ist aktualisert, so dass nach einem Rebuild des FHEM Commandref auch die TS-Module im Commandref zu finden sind. 00_TSCUL.pm ist im Protokollsupport reduziert auf die obigen Module.

MadMax-FHEM

#219
Hallo Ansgar,

so nun lege ich mal los (bzw. fange damit an)...

Ich mache mal einen update aller fhem Installationen (hmusb-System, HMUART-System, und Test-System [spezial-CUL], damit müsste die Testumgebung ja wieder auf Original sein bis auf FW des CUL) und kopiere die (zusätzlichen) pm-Module aus dem Post.

EDIT: folgende habe ich nach /opt/fhem/FHEM/ kopiert:

00_CUL.pm
00_TSCUL.pm
10_CUL_HM.pm
10_TSIT.pm
10_UNIRoll_TS.pm
13_TSKS300.pm
14_TSCUL_TX.pm
14_TSCUL_WS.pm
16_TSSTACKED.pm
CalcUtil.pm
CUL_Util.pm
DevIoTS.pm


Dann ändere ich den CUL in TSCUL (falls das nicht automatisch geschieht).
EDIT: habe ich mal händisch gemacht (siehe list).


Hier noch ein list des nanoCUL nach den Arbeiten:


Internals:
   CMDS       ABCEFGJKMRTUVWXYZefilmtx
   Clients    TSSTACKED:STACKABLE_CC:CUL_HM:HMS:CUL_IR
   DEF        /dev/serial/by-path/platform-3f980000.usb-usb-0:1.5:1.0-port0@38400 1111
   DeviceName /dev/serial/by-path/platform-3f980000.usb-usb-0:1.5:1.0-port0@38400
   FD         8
   FHTID      1111
   HM_RptCnt  0
   NAME       nanoCUL_HM
   NR         44
   PARTIAL
   RAWMSG     AFF010004B291000CA0847031D1FE000000010B3708
   RSSI       -70
   STATE      Initialized
   TYPE       TSCUL
   VERSION    V 99.79 nanoCUL868
   VERSION_HW nanoCUL_V1.x
   VERSION_TS yes
   XmitOpen   1
   initString X21
Ar
At1
   nanoCUL_HM_MSGCNT 454
   nanoCUL_HM_TIME 2016-09-15 21:17:47
   owner_CCU  vccu
   Matchlist:
     1:TSSTACKED ^\*
     A:CUL_HM   ^A....................
     B:HMS      ^810e04....(1|5|9).a001
     C:CUL_IR   ^I............
   Readings:
     2016-09-15 20:38:24   Xmit-Events     ok:1 disconnected:1 init:2 Warning-HighLoad:1
     2016-06-27 21:46:01   ccconf          freq:868.300MHz bWidth:101kHz rAmpl:33dB sens:8dB drate:9.993kBit/s agcprio:1 agcwait:16 agchyst:2 dcBlockingoff:0 IF:152.34kHz agcMaxLNA:0.0dB agcMaxDVGA:1 AGC_FREEZE:0 freq_offs:0.000kHz
     2016-09-15 20:36:32   cmds             A B C E F G J K M R T U V W X Y Z e f i l m t x
     2016-09-15 20:38:24   cond            ok
     2016-05-06 00:05:19   credit10ms      900
     2016-08-10 20:11:18   hmSioDly        2
     2016-09-15 20:36:49   prot_Warning-HighLoad last
     2016-09-15 20:36:31   prot_disconnected last
     2016-09-15 20:36:33   prot_init       last
     2016-09-15 20:38:24   prot_ok         last
     2016-05-06 00:12:28   raw             V 1.66 nanoCUL868
     2016-09-15 21:11:05   scF             1.00022197238458
     2016-09-15 20:36:32   state           Initialized
     2016-07-22 17:11:01   version         V 1.66 nanoCUL868
   Helper:
     Devio:
       NDisCon    0
       NRFail     0
       RXfailTS
     Hm:
       FUP        0
       hmCrdts    0
       hmSbusy    0
       Unknwn:
         2b1a82:
           aUnknCnt   12000000000
           lRcTm      2447376
           lstRecType 10
           nextSend   1473967052.10586
           nxtSndMcnt 05
           tgtDly     120
         2b8e86:
           aUnknCnt   14000000000
           lRcTm      2449120
           lstRecType 10
           nextSend   1473967053.84941
           nxtSndMcnt EF
           tgtDly     120
         2ba56b:
           aUnknCnt   15000000000
           lRcTm      2395912
           lstRecType 10
           nextSend   1473967000.62846
           nxtSndMcnt 71
           tgtDly     120
         2bbf72:
           aUnknCnt   15000000000
           lRcTm      2382728
           lstRecType 70
           nextSend   1473966987.44248
           nxtSndMcnt BF
           tgtDly     120
         2c8bfc:
           aUnknCnt   14000000000
           lRcTm      2438456
           lstRecType 10
           nextSend   1473967043.1807
           nxtSndMcnt 2C
           tgtDly     120
         2d9b77:
           aUnknCnt   15000000000
           lRcTm      2348048
           lstRecType 10
           nextSend   1473966952.75594
           nxtSndMcnt 8D
           tgtDly     120
         31d1fe:
           aUnknCnt   31000000000
           lRcTm      2462856
           lstRecType 70
           nextSend   1473967067.58828
           nxtSndMcnt A0
           tgtDly     120
         31d958:
           aUnknCnt   31000000000
           lRcTm      2394120
           lstRecType 70
           nextSend   1473966998.83465
           nxtSndMcnt BD
           tgtDly     120
         32185b:
           aUnknCnt   32000000000
           lRcTm      2391752
           lstRecType 70
           nextSend   1473966996.46663
           nxtSndMcnt FE
           tgtDly     120
         32279a:
           aUnknCnt   30000000000
           lRcTm      2370536
           lstRecType 70
           nextSend   1473966975.24673
           nxtSndMcnt B0
           tgtDly     120
         3227f4:
           aUnknCnt   31000000000
           lRcTm      2403632
           lstRecType 70
           nextSend   1473967008.34852
           nxtSndMcnt B7
           tgtDly     120
         322927:
           aUnknCnt   31000000000
           lRcTm      2341496
           lstRecType 70
           nextSend   1473966946.20206
           nxtSndMcnt 5C
           tgtDly     120
         3229b5:
           aUnknCnt   31000000000
           lRcTm      2331552
           lstRecType 70
           nextSend   1473966936.25574
           nxtSndMcnt CD
           tgtDly     120
         3515da:
           aUnknCnt   28000000000
           lRcTm      2150800
           lstRecType 02
           nextSend   1473966755.45921
           nxtSndMcnt 03
           tgtDly     120
         453732:
           aUnknCnt   31000000000
           lRcTm      2370688
           lstRecType 70
           nextSend   1473966975.39876
           nxtSndMcnt 49
           tgtDly     120
         4a347f:
           aUnknCnt   15000000000
           lRcTm      2382328
           lstRecType 5E
           nextSend   1473966987.04222
           nxtSndMcnt DE
           tgtDly     120
         999999:
           aUnknCnt   3000000000
           lRcTm      377432
           lstRecType 12
           nextSend   1473964981.70212
           nxtSndMcnt 99
           tgtDly     120
         Affe11:
           aUnknCnt   38000000000
           lRcTm      2150688
           lstRecType 11
           nextSend   1473966755.34681
           nxtSndMcnt 03
           tgtDly     120
         Affe22:
           aUnknCnt   18000000000
           lRcTm      1403424
           lstRecType 11
           nextSend   1473966007.92033
           nxtSndMcnt 07
           tgtDly     120
     Cnd:
       0          1
       2          1
       253        1
       255        2
     Q:
       HMcndN     0
       answerPend 0
       hmLanQlen  1
       Cap:
         sum        22500
     Ref:
       Sdly       5
       hmDstDly   120
       ioByteRate 3840
       lHMt       2449120
       lSys       793271201
       nusew      32
       pTTu       1024
       pndAs      0
       pndCUAp    0
       pngLm      15
       pngMax     7
       pngMin     7
       pngRef     7
       pngtm      792882700
       scErr      0.499999999767169
       scF        1.00022197238458
       scFN       2
       scHT       13160
       scST       790834700
Attributes:
   hmId       AFFE02
   hmLanQlen  1_min
   rfmode     HomeMatic
   verbose    4



Passt das so oder hab ich da was falsch verstanden?

Danach (falls keine Probleme oder Einspruch bzgl. "da hab ich was falsch gemacht") lege ich dann mal mit dem Mitlauschen etc. los...
EDIT: habe mal gepairt und getConfig gemacht und mitgelauscht...

Gruß, Joachim
FHEM PI3B+ Bullseye: HM-CFG-USB, 40x HM, ZWave-USB, 13x ZWave, EnOcean-PI, 15x EnOcean, HUE/deCONZ, CO2, ESP-Multisensor, Shelly, alexa-fhem, ...
FHEM PI2 Buster: HM-CFG-USB, 25x HM, ZWave-USB, 4x ZWave, EnOcean-PI, 3x EnOcean, Shelly, ha-bridge, ...
FHEM PI3 Buster (Test)

noansi

Hallo Joachim,

ZitatEDIT: folgende habe ich nach /opt/fhem/FHEM/ kopiert:
Du hast die richtigen Dateien kopiert.

ZitatDann ändere ich den CUL in TSCUL (falls das nicht automatisch geschieht).
EDIT: habe ich mal händisch gemacht (siehe list).
Das war richtig. Und eine Automatik gibt es dabei nicht. Wird es wohl auch nicht geben, da ich nicht wissen kann, ob ein User den einen oder einen anderen CUL auf Timstamp  Firmware umstellen und nutzen möchte.

ZitatPasst das so oder hab ich da was falsch verstanden?
Nur für HM passt das so.

Wenn noch IT, TX, WS, KS300 oder Uniroll mit CUL im Spiel sind, dann muss bei Umstellung des jeweiligen CUL/STACKABLE_CC auf TSCUL/TSSTACKED auch auf die jeweile TS Variante händisch umgestellt werden.

Gruß, Ansgar.

MadMax-FHEM

Hi Ansgar,

ok, sehr schön.

Zitat00_TSCUL.pm         -> statt der 00_CUL.pm, aus CUL devices werden damit TSCUL devices in der fhem.cfg

Klang halt ein wenig nach automatisch ;-)

Aber nachdem da nichts automatisch passiert ist habe ich ihn mal umdefiniert...

D.h. bis die Anpassungen (falls) in die 00_CUL.pm bzw. 10_CUL_HM.pm eingeflossen sind muss ich diese vom update ausschließen...

Danke, Joachim
FHEM PI3B+ Bullseye: HM-CFG-USB, 40x HM, ZWave-USB, 13x ZWave, EnOcean-PI, 15x EnOcean, HUE/deCONZ, CO2, ESP-Multisensor, Shelly, alexa-fhem, ...
FHEM PI2 Buster: HM-CFG-USB, 25x HM, ZWave-USB, 4x ZWave, EnOcean-PI, 3x EnOcean, Shelly, ha-bridge, ...
FHEM PI3 Buster (Test)

MadMax-FHEM

Hi Ansgar,

Zitat von: MadMax-FHEM am 17 September 2016, 20:12:44
D.h. bis die Anpassungen (falls) in die 00_CUL.pm bzw. 10_CUL_HM.pm eingeflossen sind muss ich diese vom update ausschließen...

gibt es schon Rückmeldung bzgl. der Integration in 00_CUL.pm und 10_CUL_HM.pm??

Läuft bei mir gut soweit...
...wobei ich auf dem Testsystem nicht so viel damit mache (außer bei Bedarf ;-)  )...

Gruß, Joachim
FHEM PI3B+ Bullseye: HM-CFG-USB, 40x HM, ZWave-USB, 13x ZWave, EnOcean-PI, 15x EnOcean, HUE/deCONZ, CO2, ESP-Multisensor, Shelly, alexa-fhem, ...
FHEM PI2 Buster: HM-CFG-USB, 25x HM, ZWave-USB, 4x ZWave, EnOcean-PI, 3x EnOcean, Shelly, ha-bridge, ...
FHEM PI3 Buster (Test)

noansi

Hallo Joachim,

bis auf einen Daumen ;-) keine Rückmeldung.
Die Wunschliste scheint wohl nicht der richtige Ort dafür.
Oder das Interesse ist sehr bescheiden.

Gruß, Ansgar.

weini

Bei mir läuft aktuell die "normale" culfw sowie FHEM Module. Meine HM-Komponenten laufen soweit auch, allerdings beginnt es zu haken, wenn ich meine Rollladenaktoren auf SIGN ON schalte. Einen zu schalten funktioniert meistens noch, mehrere gleichzeitig geht grundsätzlich schief.

Klingt das nach einem Timing-Problem, wie es die alternative HM FW adressiert?

Falls ich die im Post #218 aufgeführten Komponenten bei mir einspiele, muss ich dann die 00_TSCUL zusätzlich über meine 00_CUL kopieren (oder verlinken), wenn ich noch weitere CULs nutze?