Hallo,
ich habe nach ca. 2 Monaten Betrieb Probleme mit den Unterputz-Rolladenaktoren. Diese fahren nach sunrise und sunset hoch und runter. Die manuellen Tasten werden so gut wie gar nicht verwendet.
Jetzt habe ich im Frontend bemerkt, dass der Offen-Zustand (Level 100) nicht mehr korrekt angezeigt wurde. Bei vollständigem Öffnen war der zurückgegebene Level erst nur noch 90, dann 80 statt der korrekten 100 bei Zustand offen. Beim nachschauen der Register habe ich bemerkt, dass der Wert R-driveDown auf 20 steht (so hatte ich ihn auch programmiert), der Wert für R-driveUp aber auf set_21. Den hatte ich auf 21 programmiert. Versuche andere Zeiten einzugeben gibt bei R-driveDown die programmierte Zeit zurück, bei R-driveUp aber immer set_XX mit XX die programmierte Zeit.
Mache ich etwas falsch oder kann das die Ursache sein, dass mir im Laufe der Zeit der Zustand Offen nicht mehr korrekt angezeigt wird?
Gruß Jürgen
Homematic-Bereich wäre eher passend da es um ein HM-Gerät geht (dafür gibt es die unterschiedlichen Bereiche).
Verschieben kannst du selbst.
ich würde als erstes mal ein getConfig am Aktor machen, um zu sehen ob das set_21 s überhaupt angenommen wurde vom Aktor,
nicht das das noch auf org 50 sekunden steht.
Hallo Hary,
Kommt unknown command. Den Befehl gibt es bei dem Aktor anscheinend nicht.
Ein getValue bringt Value not captured.
Ein getparam R-driveUp bringt set_21 s
Hatte gestern über das Frontend mittels webcmd den Rolladen hochgefahren. Dann stand er auf 100. Jetzt, nachdem er zeitgesteuert hochgefahren ist steht er wieder auf 90.
Hatte das Problem schon jemand? Dadurch erkenne ich nicht mehr, ob er wirklich offen ist.
Hallo Jürgen,
habe diesen Rollladen-Actor auch im Einsatz. Es gibt dort ein getConfig (siehe screenshot). Der Rollladen ist etwas größer daher die unterschiedlichen drive-Zeiten. Alle 10 Fahrten wird eine Referenzfahrt durchgeführt, damit sind die Posistionsanfahrten relativ genau.
Stell mal ein list device zur Verfügung, damit wird etwas mehr Informationen haben.
ciao walter
Hallo wkarl,
Das getconfig
CFGFN
./FHEM/Flur_UG.cfg
CUL_0_MSGCNT
6
CUL_0_RAWMSG
A0D0CA410316C1F31AE260601B400::-58.5:CUL_0
CUL_0_RSSI
-58.5
CUL_0_TIME
2015-05-01 08:45:04
DEF
316C1F
IODev
CUL_0
LASTInputDev
CUL_0
MSGCNT
6
NAME
FL_UG_Rolladen
NR
351
STATE
90
TYPE
CUL_HM
lastMsg
No:0C - t:10 s:316C1F d:31AE26 0601B400
protCmdPend
2 CMDs pending
protLastRcv
2015-05-01 08:45:04
protSnd
7 last_at:2015-05-01 20:08:05
protState
CMDs_processing...
rssi_CUL_0
avg:-57.33 min:-59 max:-56 lst:-57 cnt:3
rssi_at_CUL_0
avg:-59.08 min:-60 max:-57.5 lst:-58.5 cnt:6
Readings
CommandAccepted
yes
2015-05-01 08:45:00
D-firmware
2.3
2015-02-14 17:03:08
D-serialNr
LEQ1026377
2015-02-14 17:03:08
PairedTo
0x31AE26
2015-02-14 17:03:34
R-confBtnTime
permanent
2015-02-14 16:38:31
R-driveDown
20 s
2015-02-14 17:01:24
R-driveTurn
0.5 s
2015-02-14 16:38:32
R-driveUp
set_22 s
2015-04-26 21:53:28
R-intKeyVisib
invisib
2015-02-14 16:38:31
R-localResDis
off
2015-02-14 16:38:31
R-pairCentral
0x31AE26
2015-02-14 15:59:58
R-sign
off
2015-02-14 16:38:32
R-statusInfoMinDly
2 s
2015-02-14 16:38:32
R-statusInfoRandom
1 s
2015-02-14 16:38:32
R-transmitTryMax
6
2015-02-14 16:38:32
deviceMsg
90 (to CUL_0)
2015-05-01 08:45:04
level
90
2015-05-01 08:45:04
motor
stop:90
2015-05-01 08:45:04
pct
90
2015-05-01 08:45:04
recentStateType
info
2015-05-01 08:45:04
state
90
2015-05-01 08:45:04
timedOn
off
2015-05-01 08:45:04
FL_UG_Rolladen
als erstes
Zitat2 CMDs pending
ist vom 26.4.2015
ZitatR-driveUp
set_22 s
2015-04-26 21:53:28
an der Bedienung hapert es bei dir :)
mußt schon warten bis die Pendings weg sind und F5 an der tastatur oder die Seite neu aufrufen im Webif
Hallo fhem-hm-knecht
Sorry, aber jetzt bin ich an meinen Grenzen. Was hat das mit den 2 cmds pending zu bedeutend? An welcher Bedienung Huberts? Kannst du mich aufklären?
Ja, ich habe es zum letzten Mal am 26.04 versucht und war dann auf Reisen.
Gruß Jürgen
schaue dir einmal die Kommunikation FHEM mit HM an. das ist z.B. im Einsteigerdoc erklärt.
Die Kommandos müssen erst übertragen werden, sonst werden die Register nicht geschrieben - klar.
Danke für den Hinweis. Habe ich alles schon mal gelesen und auch konfiguriert, aber leider wieder in der Zwischenzeit vergessen. Beim Nachschlagen nach den cmdPendings kam dann die Erinnerung langsam wieder.
Habe Zeiten neu gesetzt mit set <name> driveUp bzw. driveDown, die Anlerntaste gedrückt, in FHEM save eingegeben und dann über set <name> getconfig und anschließendem get <name> reg all kontrolliert.
Steht jetzt:
ZitatAZ_Rolladen type:blindActuator -
list:peer register :value
0: confBtnTime :permanent
0: intKeyVisib :invisib
0: localResDis :off
0: pairCentral :0x31AE26
1: driveDown :20 s
1: driveTurn :0.5 s
1: driveUp :21 s
1: refRunCounter :0
1: sign :off
1: statusInfoMinDly :3 s
1: statusInfoRandom :0 s
1: transmitTryMax :6
Denke somit sind die Zeiten korrekt eingegeben (steht kein set_ mehr vor der Zeit) und ich muss warten, ob das Problem wieder auftaucht, dass im Offen-Zustand nur Level 90 oder 80 angezeigt wird.
Wie ich bereits geschriebenhabe: wenn ich den Rolladen über den Taster hochfahre scheint er sich neu zu kalibrieren und dan steht wieder Level 100, wenn er ganz offen ist. Warum das so ist erschließt sich mir nicht.
der Bl1PBU sollte eigentlich ohne ConfigTaste lesen können.
das: mit anlernen drücken steht im Wiki m.E. falsch drin,sollte ich ändern.
Braucht man nach meinen Tests definitiv nicht. Gab es da mal andere Firmware?
Gruß Otto
Hallo,
habe versucht die Werte driveUp und driveDown meiner Homematic Rolladenaktoren HM-LC-Bl1PBU-FM mit kürzeren Fahrzeiten zu setzen. Die Rolladen schalten natürlich korrekt in beiden Entlagen ab, was aber nicht stimmt sind durch die zu großen Werte der beiden driveUp und driveDown, die Prozentwerte beim schließen und dies nicht durch die Lamellenabstände.
Ich habe wie von BMWFan angegeben versucht die Werte zu setzen.
ZitatHabe Zeiten neu gesetzt mit set <name> driveUp bzw. driveDown, die Anlerntaste gedrückt, in FHEM save eingegeben und dann über set <name> getconfig und anschließendem get <name> reg all kontrolliert.
Ich bekomme die beiden Werte jedoch nicht zur Auswahl.
Erreicht man das Ziel jetzt anders? Das Post ist schließlich von 2015.
Und dann frage ich mich gerade, ob es prinzipiell gern gesehen ist, wenn man dieses Thema dann nach dieser Zeit erneut öffnet, oder dann doch lieber einen neuen Beitrag schreibt, auch wenn ich mich ja genau darauf beziehen möchte?
Besten Dank schon mal für die Hilfe und viele Grüße,
Bo
Hallo Bo,
na ja manchmal ist das Leichenfleddern schon problematisch.
Der komplette Befehl sieht so aus set RolloWZR regSet driveDown 19.5
set RolloBWa regSet driveUp 9.5
Die Aussage von BMWFan war etwas luschig. ;D
Gruß Otto
Zitat von: Otto123 am 03 April 2018, 21:48:12
Der komplette Befehl sieht so aus set RolloWZR regSet driveDown 19.5
set RolloBWa regSet driveUp 9.5
Ich wollte heute meinen neuangelernten HM auch nohc mit up und down konfigurieren. Das hat vor langer Zeit auch immer geklappt. Aber plötzlich...
regSet requires parameter: [(prep|{exec})] -regName- -value- [-peerChn-]Hat sich in fhem was geändert ?
Moin,
an der Stelle nicht.
Funktioniert immer noch mit dem Syntax.
Was sagt bei Dir Version HM? Aktuell
Zitat10_CUL_HM.pm 23252 2020-11-28 19:48:27Z martinp876
00_HMLAN.pm 18152 2019-01-05 23:18:38Z martinp876
00_HMUARTLGW.pm 18838 2019-03-09 20:40:14Z mgernoth
HMConfig.pm 22974 2020-10-15 13:34:54Z martinp876
Auch diese Version funktioniert
Zitat10_CUL_HM.pm 22022 2020-05-24 08:50:40Z martinp876
98_HMinfo.pm 21999 2020-05-22 11:05:41Z martinp876
00_HMLAN.pm 18152 2019-01-05 23:18:38Z martinp876
00_HMUARTLGW.pm 18838 2019-03-09 20:40:14Z mgernoth
HMConfig.pm 20888 2020-01-05 06:59:29Z martinp876
Gruß Otto
Moin.
Meinst Du HMinfo ?
Internals:
FUUID 5ccbe732-f33f-e9d9-2aa6-da2e803fe24ea529
NAME homeMatic
NR 127
NTFY_ORDER 50-homeMatic
STATE ???
TYPE HMinfo
Version 01
helper:
weekplanListDef ./tempList.cfg
weekplanListDir ./
weekplanList:
nb:
cnt 0
Attributes:
DbLogExclude .*
group Hardware
room System->Hardware
sumERROR battery:ok,sabotageError:off,powerError:ok,overload:off,overheat:off,reduced:off,motorErr:ok,error:none,uncertain:[no|yes],smoke_detect:none,cover:closed
sumStatus battery,sabotageError,powerError,motor
webCmd update:protoEvents short:rssi:peerXref:configCheck:models
nein. wie ich schrieb die FHEM Version in der FHEM Kommandozeile, beschränkt auf HM Module.
version HM
File Rev Last Change
# $Id: 10_CUL_HM.pm 15816a 2018-01-08 20:20:00Z noansi $
98_HMinfo.pm 23022 2020-10-25 09:09:43Z martinp876
95_YAAHM.pm 23231 2020-11-25 16:25:09Z phenning
HMConfig.pm 22974 2020-10-15 13:34:54Z martinp876
doif.js 15546 2017-12-03 09:57:42Z Ellert
fhemweb.js 23282 2020-12-02 21:44:45Z rudolfkoenig
fhemweb_readingsGroup.js 15189 2017-10-03 17:53:27Z justme1968
Zitat# $Id: 10_CUL_HM.pm 15816a 2018-01-08 20:20:00Z noansi $
HMConfig.pm 22974 2020-10-15 13:34:54Z martinp876
Ich vermute das passt nicht zusammen. Man braucht bei HM immer einen konsistenten Satz an Modul Dateien. Du hast offenbar ein paar Dateien vom Update ausgeschlossen
list global exclude_from_update
Obacht:
Zitatnoansi
Das ist die TSCUL-Version. Also ggf. da mal nachsehen, ob es was neues gibt...!
Zitat von: Otto123 am 10 Dezember 2020, 11:13:32
Ich vermute das passt nicht zusammen. Man braucht bei HM immer einen konsistenten Satz an Modul Dateien. Du hast offenbar ein paar Dateien vom Update ausgeschlossen
list global exclude_from_update
Ups...
10_CUL_HM.pm 00_TSCUL.pm 16_STACKABLETS.pm DevIoTS.pm 10_UNIRoll_TS.pm 13_TSKS300.pm 14_TSCUL_TX.pm 14_TSCUL_WS.pm 15_TSCUL_EM.pm CalcUtil.pm 98_TSCULflash.pmAlles davon gelöscht und ein update all gemacht. Jetzt klappt es. Aber der Aktor zeigt missing ack. Ein List dazu zeigt...
Internals:
.triggerUsed 1
DEF 593BB9
FUUID 5fd0d282-f33f-e9d9-80cd-8f04c9d9eaa0b9a9
IODev myCUL
LASTInputDev myCUL
MSGCNT 1
NAME RL.EG.HomeMatic.WZ_rechts
NOTIFYDEV global
NR 1238
NTFY_ORDER 50-RL.EG.HomeMatic.WZ_rechts
STATE MISSING ACK
TYPE CUL_HM
chanNo 01
lastMsg No:A4 - t:10 s:593BB9 d:F11034 0601C80061
myCUL_MSGCNT 1
myCUL_RAWMSG A0EA4A410593BB9F110340601C80061::-76.5:myCUL:
myCUL_RSSI -76.5
myCUL_TIME 2020-12-10 12:05:57
protCmdDel 17
protLastRcv 2020-12-10 12:05:57
protRcv 1 last_at:2020-12-10 12:05:57
protResnd 22 last_at:2020-12-10 12:06:11
protResndFail 7 last_at:2020-12-10 12:06:16
protSnd 9 last_at:2020-12-10 12:05:57
protState CMDs_done_Errors:1
rssi_at_myCUL cnt:1 min:-76.5 max:-76.5 avg:-76.5 lst:-76.5
rssi_myCUL cnt:1 min:-97 max:-97 avg:-97 lst:-97
.attraggr:
.attreocr:
state
.attrminint:
.userReadings:
HASH(0x69d46a0)
Helper:
DBLOG:
state:
DBLogging:
TIME 1607598376.30447
VALUE MISSING ACK
READINGS:
2020-12-09 14:34:58 .D-devInfo 010100
2020-12-09 14:34:58 .D-stc 30
2020-12-09 14:35:03 .R-confBtnTime permanent
2020-12-09 14:35:03 .R-intKeyVisib invisib
2020-12-09 14:35:03 .R-localResDis off
2020-12-09 14:35:05 .R-refRunCounter 0
2020-12-09 14:35:05 .R-statusInfoMinDly 2 s
2020-12-09 14:35:05 .R-statusInfoRandom 1 s
2020-12-09 14:35:05 .R-transmitTryMax 6
2020-12-10 11:59:57 .associatedWith RL.EG.HomeMatic.WZ_rechts,RL.EG.HomeMatic.WZ_rechts
2020-12-09 14:35:06 .peerListRDate 2020-12-09 14:35:06
2020-12-10 12:05:57 .protLastRcv 20201210120557
2020-12-09 14:34:59 CommandAccepted yes
2020-12-09 14:34:58 D-firmware 2.8
2020-12-09 14:34:58 D-serialNr OEQ0362042
2020-12-09 14:35:30 PairedTo 0xF11034
2020-12-10 12:02:15 R-driveDown set_20.9 s
2020-12-09 14:35:05 R-driveTurn 0.5 s
2020-12-10 12:02:30 R-driveUp set_22.5 s
2020-12-09 14:35:03 R-pairCentral 0xF11034
2020-12-09 14:35:05 R-sign off
2020-12-10 12:03:00 cfgState RegMiss
2020-12-10 12:06:16 commState CMDs_done_Errors:1
2020-12-10 12:05:57 deviceMsg on (to myVCCU)
2020-12-10 12:05:57 level 100
2020-12-10 12:05:57 motor stop:on
2020-12-10 12:05:57 pct 100
2020-12-10 12:05:57 recentStateType info
2020-12-10 12:06:16 state MISSING ACK
2020-12-10 12:06:16 statePosition 0
2020-12-10 12:05:57 timedOn off
RegL_00.:
VAL
helper:
HM_CMDNR 165
cSnd 01F11034593BB9010E,01F11034593BB9010E
getCfgList all
getCfgListNo ,3
mId 0005
peerFriend peerSens,peerVirt
peerOpt 3:blindActuator
regLst 0,1,3p
rxType 1
supp_Pair_Rep 0
cfgChk:
idRc01 RegL_00.,RegL_01.
cmds:
TmplKey :no:1607597997.92258
TmplTs 1607597997.92258
cmdKey 1:1:0::RL.EG.HomeMatic.WZ_rechts:0005:01:
cmdLst:
assignHmKey noArg
clear [(readings|trigger|register|oldRegs|rssi|msgEvents|{msgErrors}|attack|all)]
deviceRename -newName-
down [(-changeValue-|{10})] [(-ontime-|{0})] [(-ramptime-|{0})]
fwUpdate -filename- [-bootTime-]
getConfig noArg
getDevInfo noArg
getRegRaw (List0|List1|List2|List3|List4|List5|List6) [-peerChn-]
getVersion noArg
inhibit [(on|{off})]
off noArg
on noArg
pair noArg
pct -value- [-ontime-]
peerBulk -peer1,peer2,...- [({set}|unset)]
peerIODev [IO] -btn- [({set}|unset)] 'not for future use'
peerSmart -peerOpt-
press [(long|{short})] [(-peer-|{self01})] [(-repCount-|{0})] [(-repDelay-|{0.25})]
raw -data- [...]
regBulk -list-.-peerChn- -addr1:data1- -addr2:data2-...
regSet [(prep|{exec})] -regName- -value- [-peerChn-]
reset noArg
sign [(on|{off})]
statusRequest noArg
stop noArg
toggle noArg
toggleDir noArg
tplDel -tplDel-
tplSet_0 -tplChan-
unpair noArg
up [(-changeValue-|{10})] [(-ontime-|{0})] [(-ramptime-|{0})]
lst:
condition slider,0,1,255
peer
peerOpt SN.EG.HomeMatic.GartenhausTuer,SN.EG.HomeMatic.HausTuer,SN.EG.HomeMatic.TerrassenTuer,myVCCU
tplChan
tplDel
tplPeer
rtrvLst:
cmdList [({short}|long)]
deviceInfo [({short}|long)]
param -param-
reg -addr- -list- [-peerChn-]
regList noArg
regTable noArg
regVal -addr- -list- [-peerChn-]
saveConfig [-filename-]
tplInfo noArg
dir:
cur stop
expert:
def 1
det 0
raw 1
tpl 0
io:
lstRecType 10
newChn +593BB9,00,00,00
nextSend 1607598357.78525
nxtSndMcnt A4
rxt 0
tgtDly 88
vccu myVCCU
lRcTm:
myCUL 399616
tnms 206847184
p:
593BB9
00
00
00
prefIO:
myCUL
mRssi:
mNo A4
io:
myCUL:
-74.5
-74.5
prt:
bErr 0
sProc 0
q:
qReqConf
qReqStat
role:
chn 1
dev 1
prs 1
rpt:
IO myCUL
flg A
ts 1607598357.71747
ack:
HASH(0x7075d50)
A48002F11034593BB900
rssi:
at_myCUL:
avg -76.5
cnt 1
lst -76.5
max -76.5
min -76.5
myCUL:
avg -97
cnt 1
lst -97
max -97
min -97
shadowReg:
RegL_01. 0B:00 0C:D1 0D:00 0E:E1
tmpl:
Attributes:
.devInfo 010100
.mId 006A
IODev myCUL
IOgrp myVCCU:myCUL
autoReadReg 4_reqStatus
comment 1-fach Schaltaktor fuer Wohnzimmer-Jalousie (Rechts)
devStateIcon on:fts_shutter_10@#33DD22 runter:fts_shutter_down@#33DD22 off:fts_shutter_100@#FF3400 hoch:fts_shutter_up@#FF3400 9\d.*:fts_shutter_10@#FF7700 8\d.*:fts_shutter_20@#FF7700 7\d.*:fts_shutter_30@#FF7700 6\d.*:fts_shutter_40@#FF7700 5\d.*:fts_shutter_50@#FF7700 4\d.*:fts_shutter_60@#FF7700 3\d.*:fts_shutter_70@#FF7700 2\d.*:fts_shutter_80@#FF7700 1\d.*:fts_shutter_90@#FF7700 0\d.*:fts_shutter_100@#FF7700
event-on-change-reading state
expert defReg,rawReg
firmware 2.8
group Rolläden
icon fts_shutter_automatic
model HM-LC-BL1PBU-FM
peerIDs 00000000,
room Haus->Wohnzimmer
serialNr OEQ0362042
subType blindActuator
userReadings statePosition {
if(ReadingsVal($name,"state","0") eq "up"
or ReadingsVal($name,"state","0") eq "down"
or ReadingsVal($name,"state","0") eq "closed"
or ReadingsVal($name,"state","0") eq "open_ack")
{ReadingsVal($name,"state",0)}
else
{ReadingsVal($name,"position",0)};;
}
webCmd statusRequest:toggleDir:on:off:up:down:stopIch vermute es liegt an rssi von myCUL. Allerdings der Aktor des Festerns direkt daneben zeigt...
rssi_at_myCUL
cnt:7 min:-79.5 max:-78.5 avg:-78.92 lst:-79.5
rssi_myCUL
cnt:1 min:-78 max:-78 avg:-78 lst:-78 Vor Tagen ging es noch mit rechts.
wenn ich Beta-User richtig verstehe hast Du Dir aber jetzt ev. die TSCUL Kette zerschossen? Ich habe davon leider keine Ahnung.
Also der linke Aktor lässt sich über fhem auch weiterhin steuern. Nur der Rechte streikt mit missing ack, obwohl ich ihn gestern schon komplett neu gepaired habe.
TSCUL kenne ich auch nur vom Hörensagen, aber wenn man es nutzt, hat man üblicherweise auch eine passende firmware im Einsatz. Ergo paßt irgendwas am Ende nicht mehr zusammen.
Meine Empfehlung wäre, ein passendes IO zu besorgen (das Pi-PCB), und bis dahin dann den CUL mit der Standard-firmware zu betreiben (oder eben alles auf die aktuelle TSCUL-Version zu heben).
Eventuell ist der nicht reagierende Aktor auch einfach nur defekt (das Kondensatorthema); Schwächen beim Funken sind da u.A. eines der typischen Symptome, und wenn man auf der Gegenseite einen CUL einsetzt, wird das Geamtergebnis dadurch eher schlechter...
Würde aber empfehlen, ggf. dann ein neues Thema aufzumachen, falls erforderlich, denn der ursprüngliche TE scheint irgendein ganz anderes Problem gehabt zu haben.
Zitat von: Beta-User am 10 Dezember 2020, 12:55:35
TSCUL kenne ich auch nur vom Hörensagen, aber wenn man es nutzt, hat man üblicherweise auch eine passende firmware im Einsatz. Ergo paßt irgendwas am Ende nicht mehr zusammen.
Du meinst die CUL Firmware?
@en-trust
Manchmal hilft es auch einfach den Aktor stromlos zu machen?
Die rssi Werte sind stark asymmetrisch - das ist wirklich ein Zeichen für: es stimmt was nicht.
Zitat von: Otto123 am 10 Dezember 2020, 13:29:49
Du meinst die CUL Firmware?
Jein. "TSCUL" ist eigentlich nur ein Kürzel für ein ganzes Bündel von FHEM-Modul-Varianten und spezieller firmware. noansi hat den aktuellen Stand hier dargestellt (ist im ersten Beitrag dieses Threads auch verlinkt):
https://forum.fhem.de/index.php/topic,24436.msg1098370.html#msg1098370
Früher waren wohl die CUL_HM-Module auszutauschen (daher das exclude, von dem unser Kaperer hier vergessen hatte, für was es gut war...).
Daher weiter meine Meinung: Falls nach Lektüre der Grundlagen zu TSCUL beim TE noch Fragen sind: Eigenen Thread aufmachen; entweder es ist was spezielles rund um TSCUL oder ein HW-Problem. Das sollte dann auch jeweils unter der passenden Flagge segeln, sonst findet es keiner, der helfen kann...
ok - ich werde TS wohl nie wieder "leichtfertig" als Lösungsansatz für cul User empfehlen ... das ist nur was für Spezies
Na ja, ich bin auch bei "Wenn es unbedingt Homematic sein soll UND wenn es dann auch noch unbedingt CUL sein soll, dann => TSCUL".
Aber: noansi hat nach meinem Eindruck sehr viel getan, dass man es heute parallel nutzen kann, von daher ist es heute vermutlich eigentlich viel weniger für "Spezies", wie es noch war, als ich mit FHEM angefangen habe.
Vermutlich ist es heute eigentlich nur noch eine Sonderform eines Interface-Moduls, der Rest integriert sich natlos? (wenn ich mal lustig bin, bau' ich das vielleicht ein, einfach zum testen... Kommt aber recht weit hinten auf meiner Liste ::) ).
zum testen der rssi würde ich mal ein periodisches at definieren, das zb alle 60s ein statusrequest sendet.
dadurch bekommt man normalerweise gleich viel rssi werte für beide funkrichtungen.
mit lediglich 1-2 werten ist eine analyse doch eher "voodoo".