Moin
In dem Beitrag https://forum.fhem.de/index.php/topic,40189.msg637507.html#msg637507
Würde andiskutiert, dass man mittels CUxD und hmccu Somfy Rolläden einbinden könnte.
Ist da jemand weiter gekommen?
Ich habe es derzeit so "gelöst", dass ich in der CCU2 2 virtuelle Taster je Rolläden defiert habe, einen für auf, einen für ab und dann in FHEM mittels eines doif auf diese virtuellen Taster den Somfy Rolläden auslöse. Das geht, ist aber nicht wirklich schön. Lieber würde ich ein mittels CUxD angelegten virtuellen Jalousienschalter benutzen. (Vorteil = in CCU2 bzw. Entsprechenden Apps schönere Darstellung)
Ich bekomme den Schalter in der ccu mittels CUxD angelegt, aber bekomme in FHEM keine entsprechend nutzbaren Readings angezeigt. (press Short / long ) und Level erst mit Verzögerung und außerdem nur nach manuellem Device Update.
Ist da jemand weiter als ich?
Hatte ich schon zu deinem anderen Beitrag geschrieben: leider schickt CUxd nicht alle Statusänderungen über seine RPC Schnittstelle raus. Ich habe genau die gleiche Konstellation.
Ok, dann hilft hier die aktuelle Version und geänderte Einstellungen nicht weiterˋ sprich es geht einfach nicht?
Also ...
Die gute Nachricht: ich habe es geschafft, über einen virtuellen CUxD Jalousienaktor in der CCU einen Somfy Rollladen in FHEM zu steuern. Auch der umgekehrte Weg ist natürlich möglich.
Die schlechte Nachricht: Das läuft nur mit HMCCU 4.1, das ich gerade bei mir im Test habe. Du musst Dich also noch etwas gedulden.
Zitat von: zap am 29 Juni 2017, 21:04:58
Also ...
Die gute Nachricht: ich habe es geschafft, über einen virtuellen CUxD Jalousienaktor in der CCU einen Somfy Rollladen in FHEM zu steuern. Auch der umgekehrte Weg ist natürlich möglich.
Die schlechte Nachricht: Das läuft nur mit HMCCU 4.1, das ich gerade bei mir im Test habe. Du musst Dich also noch etwas gedulden.
Klingt super! Danke
Zitat von: zap am 29 Juni 2017, 21:04:58
Also ...
Die gute Nachricht: ich habe es geschafft, über einen virtuellen CUxD Jalousienaktor in der CCU einen Somfy Rollladen in FHEM zu steuern. Auch der umgekehrte Weg ist natürlich möglich.
Die schlechte Nachricht: Das läuft nur mit HMCCU 4.1, das ich gerade bei mir im Test habe. Du musst Dich also noch etwas gedulden.
Da ich natürlich gespannt u ungeduldig bin: gibt es schon eine ungefähre Zeitplanung für den Release?
Bitte nicht falsch verstehen, will auf keinen Fall drängeln, kann a) nicht über Deine Zeit verfügen und will b) natürlich lieber länger warten und ein stabiles System haben
Zitat von: Garbsen am 30 Juni 2017, 13:40:03
Da ich natürlich gespannt u ungeduldig bin: gibt es schon eine ungefähre Zeitplanung für den Release?
Das hängt bei mir u.a. vom Wetter ab.
Schönes Wetter => Mountainbike, Grillen, ...
Schlechtes Wetter => Computerkram
Theoretisch(!) funktioniert es auch mit der 4.0. Allerdings brauchst Du dann Notifies, und ich sag mal so: Notify und ich werden keine Freunde mehr werden, von DOIF ganz zu schweigen.
Ich beschreibe mal kurz das Prinzip:
- Man legt in der CCU ein virtuelles CUxD Device vom Typ Jalousienaktor an. In den Geräteeinstellungen setzt man die Anzahl Kanäle auf 1. Das Gerät nennt man z.B. "SOMFY", den Kanal 1 "SOMFY:1"
- In FHEM mach man im IO-Device in "get devicelist". Außerdem ergänzt man das Attribut rpcInterfaces um "CUxD", setzt das Attribut ccuflags auf "extrpc" und startet am besten alles neu.
- Nun definiert man in FHEM ein Device vom Typ HMCCUCHN für den Kanal "SOMFY:1", nennen wir es mal "HM_RO_KU_Fenster"
- Nun setzt man noch einige Attribute für "HM_RO_KU_Fenster":
attr HM_RO_KU_Fenster ccureadingfilter (LEVEL|WORKING|STATE|PRESS|STOP)
attr HM_RO_KU_Fenster ccuscaleval LEVEL:0:1:0:100
attr HM_RO_KU_Fenster cmdIcon up:fts_shutter_up stop:fts_shutter_manual down:fts_shutter_down
attr HM_RO_KU_Fenster controldatapoint LEVEL
attr HM_RO_KU_Fenster event-on-update-reading .*
attr HM_RO_KU_Fenster eventMap /datapoint STOP true:stop/datapoint LEVEL 0:down/datapoint LEVEL 100:up/
# attr HM_RO_KU_Fenster peer 1.LEVEL:$1.LEVEL <= 100:fhem:set HM_RO_Kueche position $value;;\
attr HM_RO_KU_Fenster statedatapoint LEVEL
attr HM_RO_KU_Fenster substexcl control
attr HM_RO_KU_Fenster substitute LEVEL!#0-0:closed,#100-100:open;;WORKING,STOP!(0|false):no,(1|true):yes
attr HM_RO_KU_Fenster webCmd up:down:stop:control
attr HM_RO_KU_Fenster widgetOverride control:slider,0,10,100
Das auskommentierte Attribut "peer" gibt es in der 4.0 noch nicht. Das müsste man durch ein Notify oder DOIF ersetzen. Im Prinzip passiert folgendes: Sobald der Datenpunkt LEVEL aktualisiert wird, reicht HM_RO_KU_Fenster das Level an das eigentliche Somfy-Device (hier "HM_RO_Kueche") durch bzw. führt den Befehl "set position" aus.
Wichtig! Wenn man das so eingerichtet hat, darf man den Rolladen nur noch über das CCU Device oder das HMCCUCHN Device in FHEM steuern. Nicht mehr über das Somfy-Device, da weder HMCCU noch die CCU davon etwas mitbekommt. Auch ein Notify auf das FHEM Somfy-Device ist eine schlechte Idee, da dadurch eine Schaltschleife erzeugt wird.
Das CUxD Device in der CCU schickt nur LEVEL und STOP an FHEM. Die Tastendrücke (PRESS) werden nicht aktualisiert. Wenn man in der CCU die virtuellen Rauf/Runter Schalter drückt, kommt als LEVEL entweder 0 oder 1 in HMCCU an. Zwischenwerte gibt es nur, wenn man eine Prozentangabe macht.
Das sieht gut aus!
Ich gebe Dir Recht, ohne notify und/oder DOIF wäre es viel eleganter.
Zwar setze ich sehr viele DOIF (notwendigerweise) ein, aber das ist ja gerade der Grund, warum ich wo es geht von FHEM weg und zu CCU2 hin will. Ist halt wesentlich besser nachzuvollziehen was wo gemacht ist. Durch die notify u doif steigt nur durch, wer tief in die cfg einsteigt.
Das ist mir langfristig zu unsicher und fehlerträchtig.
Ok, werde das mal versuchen umzusetzen, hängt bei mir von ähnlichen wetterbedingten Themen ab, wobei Mountainbike nichts mehr für mein Alter ist ;-)
Und ich muss sicherstellen, dass FHEM auf die Devices, die ich umstelle nicht mehr alleine zugreift, sondern der Befehl immer von der ccu angestoßen wird. Da kommen dann wieder meine vielen DOIF ins Spiel (finden und auskommentieren)
Aber...
Es geht voran!
Danke
Wenn es Dir bei FHEM nur darum geht, die Geräte einzubinden, die von der CCU nicht unterstützt werden, schau Dir mal OpenHab an. Seit Version 2.0 ist das richtig gut und die Version 2.1 kommt nun mit Eclipse IOT Anbindung. Da bleibt bzgl. Anbindung exotischer Geräte kaum ein Wunsch offen. Und in der Weiterentwicklung ist richtig Drive drin.
Dazu kommt eine gute, moderne Oberfläche und eine gut strukturierte und übersichtliche Regeldefinition. Die CCU lässt sich selbstverständlich anbinden.
Damit will ich FHEM nicht schlecht machen. Es hat auch seine Vorteile. Nur ist es halt ein bisschen in die Jahre gekommen und die Architektur könnte moderner sein.
Hallo zap
Im Grundsatz funktioniert das Super. Ich habe es so eingerichtet und ein Doif drauf gesetzt, dass bei Änderung vom Reading 1.LEVEL den realen Rolläden auf die gleiche Position fährt, wie im Reading Control.
Ein Problem habe ich, das ich mir nicht erklären kann. Immer wenn ich in der CCU den Virtuellen Rollden if eine Position unter 50% fahre oder auch in FHEM den slider für Control auf unter 50% setze, gehen die Readings 1.LEVEL control hmstate und state im FHEM Device auf inf ab 50% bekomme ich korrekte Werte
Irgendeine Idee?
Hier ein List des FHEM Devices
Internals:
CFGFN
DEF CUX2801005:1
IODev d_ccu
NAME HM_SOMFY_RolloU3_1_1
NR 2488
STATE Inf
TYPE HMCCUCHN
ccuaddr CUX2801005:1
ccudevstate active
ccuif CUxD
ccuname SOMFY:RolloU3_1:1
ccutype CUX-HM-LC-Bl1PBU-FM
channels 1
statevals devstate
Readings:
2017-07-01 17:35:34 1.LEVEL Inf
2017-07-01 17:19:16 1.STATE false
2017-07-01 17:22:24 1.STOP yes
2017-07-01 17:19:16 1.WORKING no
2017-07-01 17:35:34 control Inf
2017-07-01 17:35:34 hmstate Inf
2017-07-01 17:35:34 state Inf
Hmccu:
Dp:
0.lowbat:
VAL false
0.sticky_unreach:
VAL true
0.unreach:
VAL false
1.cmd_retl:
VAL
1.cmd_rets:
VAL
1.cmd_setl:
VAL
1.cmd_sets:
VAL
1.control:
VAL 2
1.inhibit:
VAL false
1.level:
VAL Inf
1.rand:
VAL 21157
1.state:
VAL false
1.stop:
VAL 1
1.working:
VAL false
Attributes:
IODev d_ccu
ccureadingfilter (LEVEL|WORKING|STATE|PRESS|STOP)
ccuscaleval LEVEL:0:1:0:100
cmdIcon up:fts_shutter_up stop:fts_shutter_manual down:fts_shutter_down
controldatapoint LEVEL
event-on-update-reading .*
eventMap /datapoint STOP true:stop/datapoint LEVEL 0:down/datapoint LEVEL 100:up/
group Allgemein
room CCU2
statedatapoint LEVEL
substexcl control
substitute LEVEL!#0-0:closed,#100-100:open;WORKING,STOP!(0|false):no,(1|true):yes
webCmd up:down:stop:control
widgetOverride control:slider,0,10,100
"Inf" ???? Das ist krass. Kannst Du bitte noch das DOIF posten und ein List vom Somfy Device?
Zitat von: zap am 02 Juli 2017, 10:12:47
"Inf" ???? Das ist krass. Kannst Du bitte noch das DOIF posten und ein List vom Somfy Device?
Hier ein List vom DOIF (mittlerweile etwas verändert, ändert aber nichts am inf-Problem)
Internals:
CHANGED
DEF ([HM_SOMFY_RolloU3_1_1:1.LEVEL] eq "closed")
(set RolloU3_1 on)
DOELSEIF
([HM_SOMFY_RolloU3_1_1:1.LEVEL] eq "open")
(set RolloU3_1 off)
DOELSE
(set RolloU3_1 Sonnenschutz)
NAME HM_SOMFY_RU3_1
NR 959
NTFY_ORDER 50-HM_SOMFY_RU3_1
STATE cmd_2
TYPE DOIF
Readings:
2017-07-02 10:21:53 Device HM_SOMFY_RolloU3_1_1
2017-07-02 10:21:53 cmd 2
2017-07-02 10:21:53 cmd_event HM_SOMFY_RolloU3_1_1
2017-07-02 10:21:53 cmd_nr 2
2017-07-02 10:21:53 e_HM_SOMFY_RolloU3_1_1_1.LEVEL open
2017-07-02 10:21:53 state cmd_2
Condition:
0 ReadingValDoIf($hash,'HM_SOMFY_RolloU3_1_1','1.LEVEL') eq "closed"
1 ReadingValDoIf($hash,'HM_SOMFY_RolloU3_1_1','1.LEVEL') eq "open"
Devices:
0 HM_SOMFY_RolloU3_1_1
1 HM_SOMFY_RolloU3_1_1
all HM_SOMFY_RolloU3_1_1
Do:
0:
0 set RolloU3_1 on
1:
0 set RolloU3_1 off
2:
0 set RolloU3_1 Sonnenschutz
Helper:
event 1.LEVEL: open,control: 100,open,hmstate: open
globalinit 1
last_timer 0
sleeptimer -1
timerdev HM_SOMFY_RolloU3_1_1
timerevent 1.LEVEL: open,control: 100,open,hmstate: open
triggerDev HM_SOMFY_RolloU3_1_1
timerevents:
1.LEVEL: open
control: 100
open
hmstate: open
timereventsState:
1.LEVEL: open
control: 100
state: open
hmstate: open
triggerEvents:
1.LEVEL: open
control: 100
open
hmstate: open
triggerEventsState:
1.LEVEL: open
control: 100
state: open
hmstate: open
Internals:
Itimer:
Readings:
0 HM_SOMFY_RolloU3_1_1:1.LEVEL
1 HM_SOMFY_RolloU3_1_1:1.LEVEL
all HM_SOMFY_RolloU3_1_1:1.LEVEL
Regexp:
0:
1:
All:
State:
State:
Trigger:
Attributes:
do always
event-on-change-reading 1
room RollosVirtuell,CCU2 Hier das List vom realem Somfy-Device
Internals:
ADDRESS 000005
DEF 000005
IODev CUL_433
NAME RolloU3_1
NR 722
STATE oben
TYPE SOMFY
move stop
Code:
1 000005
Readings:
2016-12-12 10:22:50 Automatik 1
2017-07-02 10:21:53 enc_key A1
2017-07-02 10:22:05 exact 100
2017-07-02 10:22:05 position 100
2017-07-02 10:21:53 rolling_code 0D71
2017-07-02 10:22:05 state open
Attributes:
IODev CUL_433
alias Rollo_WZ_Links
devStateIcon .*oben:fts_shutter_20 .*unten:fts_shutter_90 .*70:fts_shutter_50
drive-down-time-to-100 21
drive-down-time-to-close 22
drive-up-time-to-100 1
drive-up-time-to-open 22
eventMap /open:oben/closed:unten/on:runter/off:hoch/pos 50:Sonnenschutz
fhem_widget_command {"allowed_values":["on","stop","off"],"order":5,"alias":"RolloWZlinks"}
genericDeviceType blind
group Rolläden WZ,Wohnzimmer
homebridgeMapping CurrentPosition=position,minValue=0,maxValue=100 TargetPosition=position,minStep=10,invert,cmd=
icon fts_shutter_updown
model somfyblinds
positionInverse 1
room FHEM_Widget,Homekit,Somfy,Sueden,Unten,Wohnzimmer
siriName Rollo Wohnzimmer links
sortby 06
userReadings Automatik
webCmd runter:hoch:stop:Sonnenschutz
widgetOverride eventMap:textField-long
Wie gesagt, das Problem tritt ausschließlich für Werte zwischen 0,1 und 49,9 auf bei 0 ist alles gut und bei 50 und mehr auch.
Allerdings funzt es nicht für das Somfy Device einen Pos Befehl zu setzen, (auch meinen derzeitigen Pos Befehl im doif muss ich noch ändern).
Das Problem: FHEM weiß nicht wo der Rolloaden wirklich steht, jeder Pos Befehl fährt das Rollo neu (d.h. Wenn ich 2 mal hintereinander Pos Sonnenschutz (Pos 40) eingebe, fährt der Rolläden beim 2. Befehl erneut, obwohl er nach dem ersten ja schon auf Pos 40 steht. Das scheint aber eher ein Problem des Somfy Moduls zu sein)
Was mir noch fehlt ist ein Stop-Befehl. Zwar steht in den Readings auch ein reading 1.Stop, aber das aktualisiert sich irgendwie nicht und steht von Anfang an auf yes.
Momentan geht also "nur" öffnen / schließen (was schon nicht schlecht ist)
Das Stop-Problem habe ich jetzt durch 2 getrennte doif gelöst, warum man das nicht in 1 Doif packen kann verstehe ich noch nicht ganz.
Wobei: grundsätzlich habe ich es damit geschafft, dass das FHEM Device auf einen Stop-Befehl in der ccu reagiert. Allerdings ist da irgendwo noch ein Problem, da FHEM in der Anzeige dieser doif und der entsprechenden Devices sehr träge wird, als ob irgendeine Schleife läuft. Aber das FHEM Device reagiert
1. Doif für hoch/Runter
defmod HM_SOMFY_RU1_1 DOIF ([HM_SOMFY_RolloU1_1_1:1.LEVEL] eq "closed")\
(set RolloU1_1 on)\
(setreading HM_SOMFY_RolloU1_1_1 1.STOP no)\
\
DOELSEIF\
([HM_SOMFY_RolloU1_1_1:1.LEVEL] eq "open")\
(set RolloU1_1 off)\
(setreading HM_SOMFY_RolloU1_1_1 1.STOP no)\
\
\
\
\
\
attr HM_SOMFY_RU1_1 room RollosVirtuell,CCU2
setstate HM_SOMFY_RU1_1 cmd_2
setstate HM_SOMFY_RU1_1 2017-07-02 11:41:26 Device HM_SOMFY_RolloU1_1_1
setstate HM_SOMFY_RU1_1 2017-07-02 11:41:26 cmd 2.2
setstate HM_SOMFY_RU1_1 2017-07-02 11:41:26 cmd_event HM_SOMFY_RolloU1_1_1
setstate HM_SOMFY_RU1_1 2017-07-02 11:41:26 cmd_nr 2
setstate HM_SOMFY_RU1_1 2017-07-02 11:41:26 cmd_seqnr 2
setstate HM_SOMFY_RU1_1 2017-07-02 11:41:26 e_HM_SOMFY_RolloU1_1_1_1.LEVEL open
setstate HM_SOMFY_RU1_1 2017-07-02 11:41:26 state cmd_2
2. Doif für Stop
defmod HM_SOMFY_RU1_1_2 DOIF ([HM_SOMFY_RolloU1_1_1:1.STOP] eq "yes")\
(setreading HM_SOMFY_RolloU1_1_1 1.LEVEL stop)\
(set RolloU1_1 stop)\
DOELSE\
\
attr HM_SOMFY_RU1_1_2 room RollosVirtuell,CCU2
setstate HM_SOMFY_RU1_1_2 cmd_2
setstate HM_SOMFY_RU1_1_2 2017-07-02 11:41:26 Device HM_SOMFY_RolloU1_1_1
setstate HM_SOMFY_RU1_1_2 2017-07-02 11:41:26 cmd 2
setstate HM_SOMFY_RU1_1_2 2017-07-02 11:41:26 cmd_event HM_SOMFY_RolloU1_1_1
setstate HM_SOMFY_RU1_1_2 2017-07-02 11:41:26 cmd_nr 2
setstate HM_SOMFY_RU1_1_2 2017-07-02 11:41:26 e_HM_SOMFY_RolloU1_1_1_1.STOP no
setstate HM_SOMFY_RU1_1_2 2017-07-02 11:38:36 mode enable
setstate HM_SOMFY_RU1_1_2 2017-07-02 11:41:26 state cmd_2
Wie gesagt, mit DOIF habe ich bisher durchwachsene Erfahrungen gemacht. Die Ergebnisse sind manchmal nicht nachvollziehbar und daher verwende ich es nicht mehr. Spätestens nach einem halben Jahr weiß man nicht mehr genau, was man mit einer Regel erreichen wollte und muss sich erst wieder reindenken. Viel zu komplex.
CUxD verhält sich allerdings manchmal auch seltsam. Beispielsweise werden LEVEL und STOP nicht aktualisiert, wenn man in den Einstellungen Befehle CMD_xx hinterlegt. Dafür hat man dann CMD_xxx Readings, wenn eine der Tasten up/down gedrückt wird, wobei nicht zwischen den Tasten entschieden wird.
Wg. dem Problem bei LEVEL < 50 warte mal ab bis zur 4.1. Vielleicht liegt es ja an DOIF. Hast Du in der CCU die richtigen Max und Min Werte für das CUxD Device eingestellt?
Wo kann ich in der CCU min und max Werte einstellen?
In den Einstellungen zum CUxD Device sehe ich nur
BLIND|CMD_SHORT
BLIND|CMD_LONG
BLIND|EXEC_TIMEOUT
Min (1-999)
BLIND|CH_PARAM1
BLIND|CH_PARAM2
BLIND|CH_PARAM3
BLIND|CH_PARAM4
BLIND|CH_PARAM5
BLIND|TIMER_PRESET
BLIND|CMD_TIMER
BLIND|PARAMETER
(0-99)
BLIND|MAX_VAL
(1-65535)
Die einzigen Einträge hier sind für
Exec time out = 60
Blind Parameter = 0
Und Blind Max Value = 100
Min wert sehe ich keinen
Gruß
K-H
Ich meinte MAXVAL. Ein min habe ich auch nicht. Meine Einstellungen sind identisch.
Ok, ich probiere weiter mit den Doif, zur Zeit habe ich, nachdem ich die ZeitsteuerungRollos für Rollos abends u morgenns an die CCU "übergeben" habe unklare Folgen bei FHEM.
2 Totalabstürze und manche Rolläden reagieren erst nach mehrmaligem Befehl. Eigentlich ein typisches Zeichen für falschen Rollingcode bei Somfy. Aber ich wüßte nicht warum, denn die Ansteuerung läuft ja auch über die CCU letztlich "ganz normal" über die FHEM Somfy-Devices.
Vielleicht nur Zufall, aber wie gesagt:ausprobieren erforderlich.
Mal sehen, ob sich das dann mit 4.1 ändert
Was mir jetzt erst auffällt: MAXVAL steht auf 100 und trotzdem liefert CUxD Werte zwischen 0 und 1. Anscheinend skaliert CUxD die Werte automatisch in 0-1.
Was ich mich jetzt frage: Was muss man in LEVEL reinschreiben? Werte 0-1 oder 0-100? Solange das Attribut ccuscaleval gesetzt ist, wird 0-1 in LEVEL geschrieben.
Zitat von: zap am 03 Juli 2017, 19:28:18
Was mir jetzt erst auffällt: MAXVAL steht auf 100 und trotzdem liefert CUxD Werte zwischen 0 und 1. Anscheinend skaliert CUxD die Werte automatisch in 0-1.
Was ich mich jetzt frage: Was muss man in LEVEL reinschreiben? Werte 0-1 oder 0-100? Solange das Attribut ccuscaleval gesetzt ist, wird 0-1 in LEVEL geschrieben.
Ehrlich gesagt Null-Ahnung, leider gehen meine Kenntnisse nicht so weit, dass ich wirklich verstehe wieso hier was mit Substitute und eventMap verändert wird. Mir ist nur aufgefallen, dass in Substitute mit Open/closed und in eventmap mit up/down gearbeitet wird, beides bezogen auf Level.
Was heißt "Inf" eigentlich?
Seltsam ist ja, dass das nur für Werte > 0 und < 50 passiert.
Kann das mit Rundungsverhalten zu tun haben? Wenn 100 eigentlich 1 ist, wäre 49 ja 0,49 gerundet = 0.
Aber wie gesagt, ich habe nicht wirklich Ahnung.
Lässt sich das Stop besser abfangen, da steht bei mir ja immer yes und ich ändere das jetzt im doif immer auf No um, wenn sich der Rolläden bewegt, um dann die Änderung auf yes durch einen stop-Befehl der ccu entsprechend mitzubekommen und umzusetzen. Ist natürlich sehr umständlich.
Das Inf kann eigentlich nur von CUxD kommen. Keine Ahnung, was das bedeutet.
Das Problem bei STOP ist, dass CUxD niemals"no" schickt. Da du aber event-on-update-reading gesetzt hast, sollte das eigentlich trotzdem funktionieren. Hat vermutlich was mit DOIF zu tun. Mit der 4.1 brauchst Du das nicht mehr. Leider muss ich noch einiges testen, bevor ich die Version rausgeben kann.
Zitat von: zap am 04 Juli 2017, 07:30:47
Das Inf kann eigentlich nur von CUxD kommen. Keine Ahnung, was das bedeutet.
Das Problem bei STOP ist, dass CUxD niemals"no" schickt. Da du aber event-on-update-reading gesetzt hast, sollte das eigentlich trotzdem funktionieren. Hat vermutlich was mit DOIF zu tun. Mit der 4.1 brauchst Du das nicht mehr. Leider muss ich noch einiges testen, bevor ich die Version rausgeben kann.
Stop: kannst du nicht ein 'no' initiieren, immer wenn ein Fahrbefehl (Level Veränderung) kommt? So mache ich es jetzt ja mit dem doif.
Termin 4.1:Kein Problem, mir ist gut getestet und stabil weitaus lieber als zu früh veröffentlicht und instabil.
Bin ja froh, dass es überhaupt jemanden gibt, der das programmiert!👍