[gelöst] 00_SIGNALduino.pm

Nobbynews · 15 September 2019, 08:51:20

Guten Morgen,

ich habe seit einiger Zeit folgende Meldungen im Event-Monitor festgestellt:

2019-09-15 08:24:24 SIGNALduino radinoCC1101 radinoCC1101 5: radinoCC1101: protocol does not match return from method: (undef)

Nachdem ich einiges ohne Erfolg ausprobiert habe, habe ich mir heute mal die zeitlich passenden Einträge in der Log-Datei und im Event-Monitor mit verbose=4 und verbose=5 angesehen:

Code Auswählen

Log-Datei, Verbose 4
2019.09.15 08:28:29 4: radinoCC1101: hideki start pattern (10101110) not found
2019.09.15 08:28:29 4: radinoCC1101: Found manchester Protocol id 58 clock 487 RSSI -85.5 -> TFA 30.3208.0
2019.09.15 08:28:29 4: radinoCC1101/msg READ: MC;LL=-1000;LH=954;SL=-511;SH=461;D=A8D9F45AE9FE0B9955A7F34;C=487;L=90;R=233;
2019.09.15 08:28:29 4: radinoCC1101: Found manchester Protocol id 10 clock 487 RSSI -85.5 -> Oregon Scientific v2|v3
2019.09.15 08:28:29 4: radinoCC1101: Found manchester Protocol id 12 clock 487 RSSI -85.5 -> Hideki
2019.09.15 08:28:29 4: radinoCC1101: Found manchester Protocol id 58 clock 487 RSSI -85.5 -> TFA 30.3208.0
2019.09.15 08:28:29 4: radinoCC1101/msg READ: MC;LL=-1029;LH=933;SL=-537;SH=429;D=A8D9F45AD9FE0B9955A6694;C=487;L=90;R=231;
2019.09.15 08:28:29 4: radinoCC1101: Found manchester Protocol id 10 clock 487 RSSI -86.5 -> Oregon Scientific v2|v3
2019.09.15 08:28:29 4: radinoCC1101: Found manchester Protocol id 12 clock 487 RSSI -86.5 -> Hideki
2019.09.15 08:28:29 4: radinoCC1101: receive Hideki protocol inverted
2019.09.15 08:28:29 4: radinoCC1101: Hideki protocol converted to hex: 7519BA4A03BECC55CD5A01 with 91 bits, messagestart 1
2019.09.15 08:28:29 4: radinoCC1101 Hideki_Parse: incomming P12#7519BA4A03BECC55CD5A01
2019.09.15 08:28:29 4: radinoCC1101 Hideki crcCheck ok: cs1/cs2 0/90, rawData=7519BA4A03BECC55CD5A01, count+2=9, length=11
2019.09.15 08:28:29 4: radinoCC1101 Hideki_Parse: raw=7519BA4A03BECC55CD5A01, decoded=752bcede05c254ff575a01
2019.09.15 08:28:29 4: radinoCC1101 Hideki_Parse: SensorTyp = 30 decodedString = 752bcede05c254ff575a01
2019.09.15 08:28:29 4: radinoCC1101 decoded Hideki protocol model=Hideki_30, sensor id=2b, channel=1, cnt=3, bat=ok, temp=20.5, humidity=54, comfort=Temp. and Hum. comfortable
2019.09.15 08:28:29 4: radinoCC1101 Hideki_Parse: using longid: 1 model: Hideki_30
2019.09.15 08:28:29 4: radinoCC1101: Found manchester Protocol id 58 clock 487 RSSI -86.5 -> TFA 30.3208.0
2019.09.15 08:28:29 4: radinoCC1101/msg READ: MC;LL=-1000;LH=950;SL=-518;SH=454;D=5180ECBB9F1FEFC7FBFFFFFFFFB6DDF8;C=486;L=125;R=232;
2019.09.15 08:28:29 4: radinoCC1101: Found manchester Protocol id 10 clock 486 RSSI -86 -> Oregon Scientific v2|v3
2019.09.15 08:28:29 4: radinoCC1101: Found manchester Protocol id 12 clock 486 RSSI -86 -> Hideki
2019.09.15 08:28:29 4: radinoCC1101: receive Hideki protocol inverted
2019.09.15 08:28:29 4: radinoCC1101: Hideki protocol converted to hex: 757FB2C47040704000000040490203 with 128 bits, messagestart 0
2019.09.15 08:28:29 4: radinoCC1101 Hideki_Parse: incomming P12#757FB2C47040704000000040490203
2019.09.15 08:28:29 4: radinoCC1101 Hideki crcCheck ok: cs1/cs2 0/2, rawData=757FB2C47040704000000040490203, count+2=13, length=15
2019.09.15 08:28:29 4: radinoCC1101 Hideki_Parse: raw=757FB2C47040704000000040490203, decoded=7581d64c90c090c0000000c0db0203
2019.09.15 08:28:29 4: radinoCC1101 Hideki_Parse: SensorTyp = 12 decodedString = 7581d64c90c090c0000000c0db0203
2019.09.15 08:28:29 4: radinoCC1101 decoded Hideki protocol model=Hideki_12, sensor id=81, channel=4, cnt=1, bat=ok, temp=9, Wc=9, Ws=0, Wg=0, Wd=12, WdDeg=270, Wdtxt=W
2019.09.15 08:28:29 4: radinoCC1101 Hideki_Parse: using longid: 1 model: Hideki_12
2019.09.15 08:28:29 4: radinoCC1101: Found manchester Protocol id 58 clock 486 RSSI -86 -> TFA 30.3208.0
2019.09.15 08:28:30 4: radinoCC1101/msg READ: MC;LL=-1002;LH=940;SL=-520;SH=463;D=80ECBBDF1FEFC7FBFFFFFFFFB6FB08;C=487;L=117;R=230;
2019.09.15 08:28:30 4: radinoCC1101: Found manchester Protocol id 10 clock 487 RSSI -87 -> Oregon Scientific v2|v3
2019.09.15 08:28:30 4: radinoCC1101: Found manchester Protocol id 12 clock 487 RSSI -87 -> Hideki
2019.09.15 08:28:30 4: radinoCC1101: hideki start pattern (10101110) not found
2019.09.15 08:28:30 4: radinoCC1101: Found manchester Protocol id 58 clock 487 RSSI -87 -> TFA 30.3208.0
2019.09.15 08:28:30 4: radinoCC1101/msg READ: MC;LL=-1017;LH=943;SL=-516;SH=443;D=01D9777E3FDF8FF7FFFFFFFF6D9F5;C=486;L=116;R=230;
2019.09.15 08:28:30 4: radinoCC1101: Found manchester Protocol id 10 clock 486 RSSI -87 -> Oregon Scientific v2|v3
2019.09.15 08:28:30 4: radinoCC1101: Found manchester Protocol id 12 clock 486 RSSI -87 -> Hideki
2019.09.15 08:28:30 4: radinoCC1101: hideki start pattern (10101110) not found
2019.09.15 08:28:30 4: radinoCC1101: Found manchester Protocol id 58 clock 486 RSSI -87 -> TFA 30.3208.0

Code Auswählen


Event-Monitor verbose =4
2019-09-15 08:28:29 SIGNALduino radinoCC1101 radinoCC1101 5: radinoCC1101: protocol does not match return from method: (undef)
2019-09-15 08:28:30 SIGNALduino radinoCC1101 radinoCC1101 5: radinoCC1101: protocol does not match return from method: (undef)
2019-09-15 08:28:30 SIGNALduino radinoCC1101 radinoCC1101 5: radinoCC1101: protocol does not match return from method: (Start pattern (10101110) not found)
2019-09-15 08:28:30 SIGNALduino radinoCC1101 radinoCC1101 5: radinoCC1101: protocol does not match return from method: (undef)

Code Auswählen

Log-Datei, verbose 5

2019.09.15 08:24:18 5: radinoCC1101: protocol does not match return from method: (undef)
2019.09.15 08:24:24 4: radinoCC1101/msg READ: MC;LL=-1015;LH=934;SL=-524;SH=453;D=EF8142E95A0BC8;C=487;L=53;R=241;
2019.09.15 08:24:24 4: radinoCC1101: Found manchester Protocol id 58 clock 487 RSSI -81.5 -> TFA 30.3208.0
2019.09.15 08:24:24 5: radinoCC1101: extracted data 00010000011111101011110100010110101001011111010000110111 (bin)
2019.09.15 08:24:24 5: radinoCC1101: protocol does not match return from method: (undef)
2019.09.15 08:24:24 4: radinoCC1101/msg READ: MC;LL=-1013;LH=933;SL=-525;SH=456;D=A8C0B45AEF7C0A174AD1494;C=487;L=90;R=241;
2019.09.15 08:24:24 4: radinoCC1101: Found manchester Protocol id 10 clock 487 RSSI -81.5 -> Oregon Scientific v2|v3
2019.09.15 08:24:24 5: radinoCC1101: extracted data 01010111001111110100101110100101000100001000001111110101111010001011010100101110101101101011 (bin)
2019.09.15 08:24:24 5: radinoCC1101: protocol does not match return from method: (undef)
2019.09.15 08:24:24 4: radinoCC1101: Found manchester Protocol id 12 clock 487 RSSI -81.5 -> Hideki
2019.09.15 08:24:24 5: radinoCC1101: extracted data 10101000110000001011010001011010111011110111110000001010000101110100101011010001010010010100 (bin)
2019.09.15 08:24:24 5: radinoCC1101: protocol does not match return from method: (message is to short)
2019.09.15 08:24:24 4: radinoCC1101: Found manchester Protocol id 58 clock 487 RSSI -81.5 -> TFA 30.3208.0
2019.09.15 08:24:24 5: radinoCC1101: extracted data 01010111001111110100101110100101000100001000001111110101111010001011010100101110101101101011 (bin)
2019.09.15 08:24:24 5: radinoCC1101: protocol does not match return from method: (undef)
2019.09.15 08:24:24 4: radinoCC1101/msg READ: MC;LL=-1021;LH=942;SL=-525;SH=438;D=518168B5BEF8142E95A1A68;C=487;L=89;R=241;
2019.09.15 08:24:24 4: radinoCC1101: Found manchester Protocol id 10 clock 487 RSSI -81.5 -> Oregon Scientific v2|v3
2019.09.15 08:24:24 5: radinoCC1101: extracted data 10101110011111101001011101001010010000010000011111101011110100010110101001011110010110010111 (bin)
2019.09.15 08:24:24 5: radinoCC1101: protocol does not match return from method: (undef)

Code Auswählen

Event-Monitor verbose 5
2019-09-15 08:24:24 SIGNALduino radinoCC1101 radinoCC1101 5: radinoCC1101: protocol does not match return from method: (undef)
2019-09-15 08:24:24 SIGNALduino radinoCC1101 radinoCC1101 5: radinoCC1101: protocol does not match return from method: (undef)
2019-09-15 08:24:24 SIGNALduino radinoCC1101 radinoCC1101 5: radinoCC1101: protocol does not match return from method: (message is to short)
2019-09-15 08:24:24 SIGNALduino radinoCC1101 radinoCC1101 5: radinoCC1101: protocol does not match return from method: (undef)
2019-09-15 08:24:24 SIGNALduino radinoCC1101 radinoCC1101 5: radinoCC1101: protocol does not match return from method: (undef)

Wenn ich mir das so ansehe, scheint es sich für mich um eine Fehler im Modul zu handeln und der Log-Level wird nicht korrekt ausgewertet. Das Attribut eventlogging hat keinen Einfluß.
Hier noch das List zum SignalDuino:

Code Auswählen

Internals:
   Clients    :IT:CUL_TCM97001:SD_RSL:OREGON:CUL_TX:SD_AS:Hideki:SD_WS07:SD_WS09: :SD_WS:RFXX10REC:Dooya:SOMFY:SD_BELL:SD_UT:SD_WS_Maverick:FLAMINGO:CUL_WS:Revolt: :FS10:CUL_FHTTK:Siro:FHT:FS20:CUL_EM:Fernotron:SD_Keeloq:SIGNALduino_un:
   DEF        /dev/serial/by-id/usb-Unknown_radino_CC1101-if00
   DMSG       P12#757FB2448D408D4000000040C93E01
   DevState   initialized
   DeviceName /dev/serial/by-id/usb-Unknown_radino_CC1101-if00@57600
   FD         47
   FUUID      5c430360-f33f-8873-f673-da8ccfb9af1167e8
   FVERSION   00_SIGNALduino.pm:v3.4.1-s10488/2019-07-10
   ITClock    250
   LASTDMSG   P12#757FB2448D408D4000000040C93E01
   LASTDMSGID 12
   MSGCNT     9985
   NAME       radinoCC1101
   NR         139
   NR_CMD_LAST_H 3
   PARTIAL    
   RAWMSG     MC;LL=-1036;LH=920;SL=-535;SH=442;D=A8C0765DDA77F69DFDFFFFFFFFDB660C;C=488;L=126;R=229;
   RSSI       -87.5
   STATE      opened
   TIME       1568529669
   TYPE       SIGNALduino
   sendworking 0
   unknownmessages 
   version    V 3.3.1-RC10 SIGNALduino cc1101 (433Mhz) - compiled at Nov 19 2018 23:11:27
   versionProtocols 1.08
   versionmodul v3.4.1_dev_09.09
   DoubleMsgIDs:
   MatchList:
     10:SD_WS07 ^P7#[A-Fa-f0-9]{6}[AFaf][A-Fa-f0-9]{2,3}
     11:SD_WS09 ^P9#F[A-Fa-f0-9]+
     12:SD_WS   ^W\d+x{0,1}#.*
     13:RFXX10REC ^(20|29)[A-Fa-f0-9]+
     14:Dooya   ^P16#[A-Fa-f0-9]+
     15:SOMFY   ^Ys[0-9A-F]+
     16:SD_WS_Maverick ^P47#[A-Fa-f0-9]+
     17:SD_UT   ^P(?:14|29|30|34|46|68|69|76|81|83|86|90|91|91.1|92|93|95)#.*
     18:FLAMINGO ^P13\.?1?#[A-Fa-f0-9]+
     19:CUL_WS  ^K[A-Fa-f0-9]{5,}
     1:IT       ^i......
     20:Revolt  ^r[A-Fa-f0-9]{22}
     21:FS10    ^P61#[A-F0-9]+
     22:Siro    ^P72#[A-Fa-f0-9]+
     23:FHT     ^81..(04|09|0d)..(0909a001|83098301|c409c401)..
     24:FS20    ^81..(04|0c)..0101a001
     25:CUL_EM  ^E0.................
     26:Fernotron ^P82#.*
     27:SD_BELL ^P(?:15|32|41|42|57|79|96)#.*
     28:SD_Keeloq ^P(?:87|88)#.*
     2:CUL_TCM97001 ^s[A-Fa-f0-9]+
     3:SD_RSL   ^P1#[A-Fa-f0-9]{8}
     4:OREGON   ^(3[8-9A-F]|[4-6][0-9A-F]|7[0-8]).*
     5:CUL_TX   ^TX..........
     6:SD_AS    ^P2#[A-Fa-f0-9]{7,8}
     7:Hideki   ^P12#75[A-F0-9]+
     9:CUL_FHTTK ^T[A-F0-9]{8}
     X:SIGNALduino_un ^[u]\d+#.*
   QUEUE:
   READINGS:
     2019-09-13 15:41:01   ccconf          freq:433.920MHz bWidth:325KHz rAmpl:42dB sens:4dB  (DataRate:5603.79Baud)
     2019-09-13 15:42:29   config          MS=1;MU=1;MC=1;Mred=0
     2019-01-25 05:40:55   freeram         1428
     2019-05-11 07:05:23   ping            OK
     2019-09-13 15:35:20   raw             ccFactoryReset done
     2019-09-13 16:00:46   state           opened
     2019-09-13 16:00:46   version         V 3.3.1-RC10 SIGNALduino cc1101 (433Mhz) - compiled at Nov 19 2018 23:11:27
   XMIT_TIME:
     1568520171
     1568520176
     1568520462
   keepalive:
     ok         1
     retry      0
   mcIdList:
     10
     12
     18
     58
   msIdList:
     1
     3
     3.1
     4
     13
     13.2
     17
     33
     35
     74.1
   muIdList:
     13.1
     17.1
     37
     39
     44
     44.1
     48
     64
     74
     75
     84
     85
     89
Attributes:
   development 1
   eventlogging 0
   flashCommand avrdude -c avr109 -b 57600 -P [PORT] -p atmega32u4 -vv -D -U flash:w:[HEXFILE] 2>[LOGFILE]
   hardware   radinoCC1101
   longids    1
   room       I/O-Geräte
   updateChannelFW testing
   verbose    3
   whitelist_IDs 1,3,3.1,4,10,12,13,13.1,13.2,17,17.1,18,33,35,37,39,44,44.1,48,58,64,74,74.1,75,84,85,89

Ist meine Überlegung richtig, oder muss ich an einer anderen Stelle suchen?

Gruß
Norbert

Sidey · 15 September 2019, 08:59:45

Hi,

Ich bin mir nicht sicher, welches Verhalten Du erwartest hast.
Kannst Du das noch beschreiben?

Geht es darum, dass die Events generiert werden oder geht es um das Event selbst?

Grüße Sidey

Nobbynews · 15 September 2019, 09:49:58

Hallo Sidey,

es geht mir darum, dass diese Events im Event-Monitor gefühlt ca. 70% der Meldungen ausmachen.
Wäre also aus meiner Sicht schön, wenn man das im Event-Monitor ausblenden könnte bzw. gar nicht erst als Event angezeigt wird.

Norbert

Byte09 · 15 September 2019, 09:57:13

ZitatWenn ich mir das so ansehe, scheint es sich für mich um eine Fehler im Modul zu handeln und der Log-Level wird nicht korrekt ausgewertet. Das Attribut eventlogging hat keinen Einfluß.

das verbose-level hat keinen einfluss auf die ausgabe des eventmonitors ( weder in diesem noch in allen anderen modulen ), sondern nur auf das logverhalten, daher handelt es sich erstmal nicht um einen Modulfehler.

Da signalduino ein signal empfängt wird in logischer konsequenz das modul ( device ) aufgerufen - das es das signal dann nicht zuordnen kann ändert aber nichts daran , das vom modul in diesem Fall events erzeugt werden. ( ob dieses notwedig ist oder nicht möchte ich hier nicht beurteilen ) - aber kein Modulfehler.

Kann ja sein , das du im fall eines nicht auswertbaren signals benachrichtigt werden möchtest z.B , dann wird entsprechendes event benötigt

gruss Byte09

Byte09 · 15 September 2019, 10:07:28

habe gerade mal in das modul reingeschaut. Scheinbar gibt es ein Attribut 'eventlogging' im Device.

Code Auswählen

if (AttrVal($name,"eventlogging",0)) {
	  DoTrigger($dev,"$name $loglevel: $text");

wenn du dieses löscht , sollten diese events nicht mehr erzeugt werden ( ohne gewähr ).

wenn ich mir das so anschaue muss es aber gelöscht werden , auf 0 setzen reicht wohl nicht . ( insofern ggf doch ein kleiner Modulfehler

)

gruss Byte09

Nobbynews · 15 September 2019, 10:08:20

Was den möglichen Modulfehler angeht, bin ich mir ja auch nicht sicher. Daher hier meine Nachfrage.

Müsste dann aber nicht das Attribut eventlogging=0 greifen und bei verbose=3 diese Meldungen aus dem Event-Monitor verbannen?
Es handelt sich doch um eine Meldung mit dem Log-Level 5, richtig?
Oder habe ich den Text

Code Auswählen

eventlogging
Mit diesem Attribut können Sie steuern, ob jede Logmeldung auch als Ereignis bereitgestellt wird. Dies ermöglicht das Erzeugen eines Ereignisses fuer jede Protokollnachricht. Setze dies auf 0 und Logmeldungen werden nur in der globalen Fhem-Logdatei gespeichert, wenn der Loglevel höher oder gleich dem Verbose-Attribut ist. Setze dies auf 1 und jede Logmeldung wird auch als Ereignis versendet. Dadurch können Sie die Ereignisse in einer separaten Protokolldatei protokollieren.

völlig falsch verstanden?

Einen Mittschnitt aus dem Event-Monitor habe ich mal als Datei angehängt.

Norbert

Byte09 · 15 September 2019, 10:10:33

Zitat von: Nobbynews am 15 September 2019, 10:08:20
Was den möglichen Modulfehler angeht, bin ich mich ja auch nicht sicher. Daher hier meine Nachfrage.

Müsste dann aber nicht das Attribut eventlogging=0 greifen und bei verbose=3 diese Meldungen aus dem Event-Monitor verbannen?
Es handelt sich doch um eine Meldung mit dem Log-Level 5, richtig?
Oder habe ich den Text
Code Auswählen Erweitern
eventlogging Mit diesem Attribut können Sie steuern, ob jede Logmeldung auch als Ereignis bereitgestellt wird. Dies ermöglicht das Erzeugen eines Ereignisses fuer jede Protokollnachricht. Setze dies auf 0 und Logmeldungen werden nur in der globalen Fhem-Logdatei gespeichert, wenn der Loglevel höher oder gleich dem Verbose-Attribut ist. Setze dies auf 1 und jede Logmeldung wird auch als Ereignis versendet. Dadurch können Sie die Ereignisse in einer separaten Protokolldatei protokollieren.

völlig falsch verstanden?

Einen Mittschnitt aus dem Event-Monitor habe ich mal als Datei angehängt.

Norbert

wenn ich mir das auf die schnelle anschaue , wird auf vorhandensein des attr geprüft , dieses ist auch mit 0 vorhanden .

Zitatwenn ich mir das so anschaue muss es aber gelöscht werden , auf 0 setzen reicht wohl nicht . ( insofern ggf doch ein kleiner Modulfehler )

zumindest findet hier mE keine Prüfung statt , die das in der comandref erklärte verhalten abbilden könnte
... kann aber sein das ich jetzt auf die schnelle falsch liege , müsste es selber probieren .

gruss Byte09

Sidey · 15 September 2019, 10:31:00

Hi,

Wenn das Attribut eventlogging den Wert 0 hat, dann sollten keine Events generiert werden.

Wenn das nicht so funktioniert, dann handelt es sich um einen Fehler.

Ich habe diesen Teil vor ein paar Tagen erst verändert.
Magst Du mal Testen, ob es mit der angepassten Version so funktioniert wie Du es erwartest?

update all https://raw.githubusercontent.com/RFD-FHEM/RFFHEM/dev-r34/controls_signalduino.txt

Grüße Sidey

Gesendet von meinem Moto Z (2) mit Tapatalk

Byte09 · 15 September 2019, 10:35:16

Zitat von: Sidey am 15 September 2019, 10:31:00
Hi,

Wenn das Attribut eventlogging den Wert 0 hat, dann sollten keine Events generiert werden.

Wenn das nicht so funktioniert, dann handelt es sich um einen Fehler.

Ich habe diesen Teil vor ein paar Tagen erst verändert.
Magst Du mal Testen, ob es mit der angepassten Version so funktioniert wie Du es erwartest?

update all https://raw.githubusercontent.com/RFD-FHEM/RFFHEM/dev-r34/controls_signalduino.txt

Grüße Sidey

Gesendet von meinem Moto Z (2) mit Tapatalk

ohne es jetzt probiert zu haben , wenn eine aahängigkeit mit dem verboselevel gegeben sein soll ( comandref ) müsste doch eine ensprechende prüfung vorhanden sein ?

sehe ich aber auf die schnelle nicht ?!

Code Auswählen

sub SIGNALduino_Log3($$$)
{
  
  my ($dev, $loglevel, $text) = @_;
  my $name =$dev;
  $name= $dev->{NAME} if(defined($dev) && ref($dev) eq "HASH");
  
  DoTrigger($dev,"$name $loglevel: $text");
  
  return Log3($name,$loglevel,$text);
}

so erzeugt er mE immer ein event ?!

oder liege ich jetzt ganz falsch ?

gruss Byte09

Sidey · 15 September 2019, 10:41:01

Hi Byte09,

Das hast Du durchaus richtig erkannt. Der Verbose Level hat bei der Eventgenerierung keinen Einfluss.

Welcher Satz in der Commandref, lässt eine Abhängigkeit vermuten?

Grüße Sidey

Gesendet von meinem Moto Z (2) mit Tapatalk

Byte09 · 15 September 2019, 10:43:19

Zitat von: Sidey am 15 September 2019, 10:41:01
Hi Byte09,

Das hast Du durchaus richtig erkannt. Der Verbose Level hat bei der Eventgenerierung keinen Einfluss.

Welcher Satz in der Commandref, lässt eine Abhängigkeit vermuten?

Grüße Sidey

Gesendet von meinem Moto Z (2) mit Tapatalk

habe ich aus einem Post de TE so entnommen... nicht selber geschaut [emoji102]

gruss Byte09

Gesendet von meinem ELE-L29 mit Tapatalk

edit : der im Anhang dargestellte

Nobbynews · 15 September 2019, 11:26:14

Hallo Sidey

Zitat von: Sidey am 15 September 2019, 10:31:00

Magst Du mal Testen, ob es mit der angepassten Version so funktioniert wie Du es erwartest?

update all https://raw.githubusercontent.com/RFD-FHEM/RFFHEM/dev-r34/controls_signalduino.txt

das ist bei mir schon so eingestellt:

Code Auswählen

http://fhem.de/fhemupdate/controls_fhem.txt
https://raw.githubusercontent.com/RFD-FHEM/RFFHEM/dev-r34/controls_signalduino.txt

Ich habe zur Sicherheit gerade noch einmal ein Update gemacht, leider ohne Änderung.

Norbert

Sidey · 15 September 2019, 16:04:43

OK, hätte ich auch sehen können.
Du hast die Version vom 9. September.

Sieht so aus, als ob Du einen Bug entdeckt hast.
Woran es genau liegt weiss ich aktuell leider noch nicht.

Grüße Sidey

Sidey · 16 September 2019, 08:15:03

Moin,

Ich habe den Fehler gefunden und behoben.

Über Rückmeldungen würde ich mich freuen:

Code Auswählen

Update all https://raw.githubusercontent.com/RFD-FHEM/RFFHEM/dev-r34/controls_signalduino.txt

Grüße Sidey

Nobbynews · 16 September 2019, 13:28:07

Hallo Sidey,

das Update habe ich eingespielt. Läuft!
Danke für die schnelle Arbeit.

Gruß
Norbert