Open HomeAutoUser opened 5 years ago
Guten Morgen! Darf ich fragen warum du das nun als privates Repo erstellt hast? Habe ich etwas falsch gemacht? Oder was falsches geschrieben?
Schade nur, dass unsere bisherige Diskussion damit weg ist(?)
Gruß Bismosa
[edit] Habe gerade gesehen, dass du den KeeLoq_NLF rausgenommen hast? Der ist doch eigentlich öffentlich? Hier sind die Routinen von Microchip direkt beschrieben: http://read.pudn.com/downloads153/sourcecode/middleware/669769/keeloq%20-C_DECRYPT/91041a_c.pdf
Hier wird dazu auch einiges geschrieben (muss aber zugeben, dass ich kein Wort verstehe :-) ) https://www.emsec.ruhr-uni-bochum.de/media/crypto/attachments/files/2011/03/africacrypt2009_keeloq.pdf
The Non-Linear Function While the NLF could also be realized by means of Boolean functions, performing table-look-ups as described in the following is common practice. Defining a look-up table by the hexadecimal constant LUT = 0x3A5C742E, its j-th bit is equivalent to one output bit OUT of the non-linear function NLF(x4,x3,x2,x1,x0). The index j ∈ {0, 1,... , 31} thereby equals the decimal representation of the input bits x4 to x0, i.e., j = 24 · x4 + 23 · x3 + 2 2 · x2 + 21 · x1 + 20 · x0. The implementation of the NLF can be crucial for the susceptibility to SPA, as will be shown in Sect. 5.
[/edit]
Servus beinand,
mir fehlt nun auch die Historie. :-( Ich habe zum Glück die Mailbenachrichtigungen. Was ist/war der Grund warum der alte Faden weg ist?
Ich habe nun heute das SignalDuino Modul upgedated und die FW des CUL upgedated. Da ich einen MiniCul habe, ist die aktuellste Version diese hier: "SIGNALduino_miniCUL_3321rc5.hex".
In der User Info steht bei einem meiner Jaros: messages can be received and send! Sollte das nun auch gehen, oder noch nicht? Irgendwie kann ich Euren teils extrem tiefen Gesprächen nicht folgen. Ich hatte nur in dem Ursprungsfaden gelesen (Ralf9):
Mit meiner V 3.3.2.1-rc8 Firmware sollte es jetzt schon funktionieren,
Ich gehe mal davon aus, dass der MinuCul noch auf die RC8 warten muss, richtig?
Jetzt wird es spannend... Ich glaube, so ganz passt das noch nicht mit dem neuen Setup.
Habe eine andere (noch nicht benutzte) FB gedrückt und bekomme nun folgendes Device angelegt:
define SIGNALduino_unknown_87 SIGNALduino_un SIGNALduino_unknown_87
attr SIGNALduino_unknown_87 IODev SignalDuinoV1
attr SIGNALduino_unknown_87 room SIGNALduino_un
attr SIGNALduino_unknown_87 stateFormat {ReadingsVal('SIGNALduino_unknown_87', 'state', '').' | '.ReadingsTimestamp('SIGNALduino_unknown_87', 'state', '-');;}
Hallo, da die rechtliche Seite gesehen werden muss und wackelig ist, so habe ich einen Cut gemacht. Es geht um die Funktionalität und nicht die „Verbreitung“ von eventuellen Schlüsseln welche dafür gedacht sind, nur vom Hersteller genutzt zu werden.
Wer sich damit beschäftigt findet Schlüssel um das Modul zu nutzen. Aus Sicherheit und Rücksichtnahme entschloss ich mich dann den Schritt zu gehen.
Keines falls ist es etwas persönliches! Es dient zur Sicherheit aller und das man nicht ausversehen etwas verbreitet.
Wenn ihr die Schlüssel eingebt, dann gibt es keine Einschränkung. Fest verankert ist nur sehr wackelig.
... anderenfalls Ordnung und restart tut gut :)
Das unbekannte Gerät kann ich nicht nachvollziehen. Was ist da anders?
Edit: u87 ... Geräte werden angelegt wenn meine Zuordnung zu Modulen erfolgt. Hast du das Modul Signalduino geupdatet?
Das unbekannte Gerät kann ich nicht nachvollziehen. Was ist da anders?
Edit: Es wird nicht als Jaro Gerät erkannt :-(
Edit: u87 ... Geräte werden angelegt wenn meine Zuordnung zu Modulen erfolgt. Hast du das Modul Signalduino geupdatet?
Ja, ich habe das Modul auf v3.3.3-dev upgedated. War das ein Fehler? :-(
Ist dann der KeeLoq_NLF zukünftig als Attribute drin zum selber Setzen?
@gandi1791
Ja, ich habe das Modul auf v3.3.3-dev upgedated. War das ein Fehler? :-(
Nein war es nicht. Das es kann passieren wenn ein Modul in der Entwicklung ist, das man somit ausversehen sich die Änderungen zurück schreibt.
Du musst 1) in der Hash Datei bei der ID 87
preamble => 'P87#', # prepend to converted message
clientmodule => 'SD_Jaro',
eintragen
2) in der 00_SIGNALduino.pm unter
my $clientsSIGNALduino = ":IT:" ......
."SD_Jaro:"
und unter
my %matchListSIGNALduino = (
"28:SD_Jaro" => '^P87#.*',
hinzufügen.
@HomeAutoUser Danke für die Erklärung. Mache ich dann heute Abend.
Hallo,
danke für die Erklärung. Es war ja auch eine Version dazwischen, wo versehentlich die Keys enthalten waren. Hast du den Diskussionsfaden noch? Gerade die To-Do Liste und meine letzten Kommentare....das wäre Schade. Ich bin unterwegs. Melde mich frühestens Sonntag Abend wieder.... Gruß Bismosa
So, SDuino läuft wieder. Danke nochmal.
Die FB wird wieder gelesen. Ist denn nun mit den Keys das Senden jetzt möglich? Dann würde ich morgen mal einen Motor neu anlernen.
Soll ich die Anleitung noch ins Englische übersetzen?
Hallo und guten Morgen, kann mir von euch mal jemand helfen, habe da irgendwo noch ein Problem. Habe das aktuelle Modul 14_SD_Jaro.pm von gestern benutzt und wie folgt konfiguriert:
define Jaro SD_Jaro 48226 sduino attr Jaro Channels 1 attr Jaro IODev sduino attr Jaro KeeLoq_NLF 0x3XXXXXXE attr Jaro MasterLSB 0x1XXXXXX5 attr Jaro MasterMSB 0x2XXXXXXb attr Jaro Repeats 3 attr Jaro Serial_send 12345600 attr Jaro ShowLearn 1 attr Jaro UI Mehrzeilig
Signalduino habe ich die Version 3.3.2.1-rc8 SIGNALduino cc1101, und die Version des FHEM-Moduls 3.3.3-dev_30.12.
Wenn ich nun die Rollläden mit der FErnbedienung fahre bekomme ich im FHEM-Log 2019.02.01 20:02:06 3: sduino: Unknown code u40#DEEFF7385F7FC, help me! 2019.02.01 20:02:06 3: sduino: Unknown code u40#DDFEE70BEFF8, help me!
Vielleicht kann mir da ja jemand helfen. Gruß Markus
@meier81 guten Tag, die Lösung von dir ist hier https://github.com/HomeAutoUser/Jaro/issues/1#issuecomment-459753550. Du musst maximal noch das development auskommentieren in der hash Datei.
Eine Nutzung zum senden ist bisher noch nicht möglich, da eine Anpassung in der FW erst noch integriert werden muss.
MfG
Hallo zusammen!
@meier81 Hallo Markus! Willkommen im Team!
Ich habe nun die neue Version probiert. Hier "hagelt" es allerdings noch ein paar PERL-Fehler:
2019.02.03 19:44:54 1: PERL WARNING: Argument "0x3XXXXXXE" isn't numeric in right bitshift (>>) at ./FHEM/14_SD_Jaro.pm line 540.
2019.02.03 19:44:54 1: PERL WARNING: Use of uninitialized value in concatenation (.) or string at ./FHEM/00_SIGNALduino.pm line 821.
(Unkenntlich gemacht)
2019.02.03 21:00:02 3: SIGNALduino: SD_Jaro_Parse device with rawData=53978F08A000759400
2019.02.03 21:00:02 1: PERL WARNING: Use of uninitialized value in concatenation (.) or string at ./FHEM/14_SD_Jaro.pm line 635, <GEN103> line 7252.
2019.02.04 08:30:01 3: SIGNALduino: SD_Jaro_Parse device with rawData=E4C8A17EA000759100
2019.02.04 08:30:01 1: PERL WARNING: Use of uninitialized value in concatenation (.) or string at ./FHEM/14_SD_Jaro.pm line 635, <GEN103> line 9745.
@HomeAutoUser Verstehe ich es jetzt also richtig, dass durch den Neustart die letzte Diskussion vollständig verschollen ist? (Nein...nicht vollständig...das Internet vergisst nichts...) Aber zumindest so nicht mehr verfügbar ist? Ich habe jetzt über githubarchive und der BigQuery API meine letzten Kommentare wiedergefunden:
Set-Commands:
Learn und UpDown als Gruppe macht eigentlich keinen Sinn. Das wird ja nur bei einzelnen Kanälen gemacht.
Das gleiche gilt auch für Gruppensteuernug. Hier braucht es auch weder learn noch UpDown...also könnten hier auch die Symbole direkt ausgeblendet bzw. gar nicht erstellt werden
ERLEDIGT! Danke :-)
Ich kann es gerade nicht testen...aber das Verhalten nach dem Erstellen des Devices ist nun: UI = Mehrzeilig Channels = 1
Ändert sich das, wenn mehrere Kanäle empfangen worden sind?
Ich glaube wir hatten mal darüber gesprochen, ob wir ohne "Serial_Send" nicht UI -> keine und sobald Senden möglich ist erst die UI anzeigen (?)
Set ist ja auch erst ab dann möglich...
Ich könnte mir vorstellen, dass viele es übersehen, dass 16 Kanäle gesteuert werden können. Wenn "Kompaktdarstellung" würde ich auf UI Einzeilig gehen...oder dann alle (?)
Kann aber auch sein, dass wir das schon mal anders besprochen hatten...
Diese sets machen noch Schwierigkeiten:
set jaro down gruppe
Resultiert in:
ERROR: channel gruppe is not support! (check2 failed)
set jaro down 1,2,3,gruppe
Resultiert in:
ERROR: your command down is not support! (not in list)
ERLEDIGT! Danke :-)
Bei folgenden Attributen:
ChannelFixed | ch3
Channels | 16
Habe ich nur set-commands für ch3. D.h. die angezeigten Commands sind nicht gültig.
command chX is not support! (not in list)
ShowIcons
Anstelle der Beschriftung Icons anzeigen. (Standard 0)
Ist derzeit Standard "1"...finde ich auch gut so :-)
DOKU: (Ist ja auch schon ein guter Stand!
ChannelFixed
Auswahl des fix eingestellten Kanals.
Greift nur, wenn UI = Einzeilig
Repeats
Text ...
ERLEDIGT! Danke :-)
Wenn die Empfänger nicht immer reagieren, kann die Anzahl der Sendewiederholungen erhöht werden.
Beispiel: define <NAME> SD_Jaro 28
28 ist ja zu "kurz". Beispiel 12345600 wäre vielleicht passender (?) ERLEDIGT! Danke :-)
Serial_send
Eine 8-stellige Serialnummer zum Senden. Sie MUSS eindeutig im ganzen System sein. OHNE Attribut Serial_send erhält der User keine Setlist --> nur Empfang möglich!
Beispiel: 123456
123456 ist nicht 8-Stellig :-) Besser die funktionierende "12345600" benutzen. ERLEDIGT! Danke :-)
user_info | messages can be received! user_modus | limited_functions
Muss das auch in die Commandref? Eigentlich fehlt eine Beschreibung, was "limited functions" nun bedeutet. (Ich habe noch keine "Serial_send" gesetzt).
Serial_send Bist Du hier jetzt eigentlich schon schlauer, was hier "erlaubt" ist?
Ich hatte oben ja schonmal geschrieben:
10153984 = 9AF000 13602816 = CF9000 12345600 = BC6100
Also müsste die Umwandlung in Hex immer mit "00" am Ende sein (?)
Und der Vollständigkeit halber noch mein letzter Kommentar:
Huhu, ich kann es ja nicht lassen:
Wir könnten ja auch eine Serial_send selbst festlegen. Einfach die nächste Möglichkeit...das jemand dieses als FB hat ist ja sehr unwahrscheinlich.
Beispiele:
FB (Dez) | Hex | Hex next | Dez |
---|---|---|---|
10153984 | 9AF000 | 9AF100 | 10154240 |
13602816 | CF9000 | CF9100 | 13603072 |
12345600 | BC6100 | BC6200 | 12345856 |
Also zu den Dezimal immer 256 addieren...dann könnte das gut klappen ;-) Was meinst Du?
Alternativ (wenn meine Theorie stimmt) könnte man auch die Eingabe des Sendekanals in Dezimal 5-Stellig machen. Dann kann man bei dem Hex-Wert davon noch "00" hinzufügen und müsste auch immer gültige Werte erhalten (?)
Dezimal | Hex | Hex+"00" | Dez
-- | -- | -- | -- 10000 | 2710 | 271000 | 2560000 10001 | 2711 | 271100 | 2560256 10002 | 2712 | 271200 | 2560512 10003 | 2713 | 271300 | 2560768 10004 | 2714 | 271400 | 2561024 10005 | 2715 | 271500 | 2561280 10006 | 2716 | 271600 | 2561536 10007 | 2717 | 271700 | 2561792 10008 | 2718 | 271800 | 2562048 10009 | 2719 | 271900 | 2562304 10010 | 271A | 271A00 | 2562560 10011 | 271B | 271B00 | 2562816 10012 | 271C | 271C00 | 2563072 10013 | 271D | 271D00 | 2563328 10014 | 271E | 271E00 | 2563584 10015 | 271F | 271F00 | 2563840 10016 | 2720 | 272000 | 2564096
Noch eine Idee: Wenn man in FHEM auf der Raumseite ist, hat man keinen Indikator, dass etwas empfangen wurde. (Ich weiß auch nicht, ob man das benötigt...) Wie wäre es, wenn man nach dem Empfang die zuletzt empfangenen Befehl durch Fettschrift bzw. anders hinterlegtes Symbol darstellt?
Würdet ihr so etwas benötigen?
Gruß Bismosa
Hallo @bismosa,
1) PerlWarning muss ich am Rechner nachvollziehen.
2) ChannelFix, entweder ich habe einen Kanal fest oder du verstehst etwas anderes darunter. Wenn ich nur einem Fest senden möchte, so benötige ich den Rest nicht.
3) Status Limited unsw. Können wir in die Doku übernehmen vollständigshalber.
4) Serial_send immer 00 enden. Muss es nicht, weil im Code die folgenden Channels „drangehangen“ werden.
5) Serial_send automatisch setzen nein. Der User sollte es selbst bestimmen können weil du nicht jedes Nutzungsverhalten kennst.
6) Raumseite etwas darstellen beim Empfang. Das kann jeder User selbst mit stateformat.
Resultierend Punkt 4/5/6 ist somit abgehakt ;)
Hallo,
da muss ich leider etwas wiedersprechen:
ChannelFix, entweder ich habe einen Kanal fest oder du verstehst etwas anderes darunter. Wenn ich nur einem Fest senden möchte, so benötige ich den Rest nicht.
Nein, das bezieht sich auf die Einstellung:
ChannelFixed | ch3
Channels | 16
Dann werden alle 16 Channels angezeigt...aber das Attribut "ChannelFixed" verhindert, dass andere Kanäle bedient werden können.
Serial_send immer 00 enden. Muss es nicht, weil im Code die folgenden Channels „drangehangen“ werden.
Das muss (wenn das Senden funktioniert) getestet werden. Soweit ich es von den anderen Projekten kenne, funktioniert es nicht vernünftig, wenn es nicht mit "00" endet.
Serial_send automatisch setzen nein. Der User sollte es selbst bestimmen können weil du nicht jedes Nutzungsverhalten kennst.
Können wir ja nochmal diskutieren, wenn wir wissen, ob jede funktioniert. Mir ging es auch nicht um das feste setzen, sondern darum dem User einen Vorschlag (änderbar) zu machen...
Das kann jeder User selbst mit stateformat.
Ich glaube nicht (ich habe es jetzt aber nicht geprüft). Da wir hier ja die Bedienung darstellen (?)
Gruß Bismosa
@ bismosa
Ich glaube nicht (ich habe es jetzt aber nicht geprüft). Da wir hier ja die Bedienung darstellen (?)
Setze den stateformat auf ein Reading oder den State und hänge die Zeit dran :) so siehst du im Raum was passiert.
ChannelFixed
Die Verhinderung der Ansteuerung ist ggf und du siehst die Channels im Reading letzter Zustand. Ich kann dir absolut nicht folgen. Wenn ich was fest (fix) mache, reicht es mir den Wert zu sehen wenn ich eh die anderen nicht steuern kann. Die Icon siehst du nur nicht aber die letzten Readings solltest du noch sehen.
Hallo! Bin jetzt erst am Rechner und konnte das Testen:
Setze den stateformat auf ein Reading oder den State und hänge die Zeit dran :) so siehst du im Raum was passiert.
Jup. Das geht aber nur, wenn UI = aus
ChannelFixed | ch3 Channels | 16
Ich glaube ich habe das schlecht erklärt: Mir geht es nur darum, wenn 16 Channels UND ChannelFixed (das ja in dem Moment ignoriert wird) gleichzeitig bei UI = Mehrzeilig aktiv ist, sehe ich die komplette UI (Alle 16 Kanäle) aber kann nur den noch gesetzten "ChannelFixed" bedienen. Also eigentlich nur eine "Idiotensperre", wenn man vergisst dieses Attribut wieder zu entfernen...
Mir ist gerade aufgefallen, das noch irgendwas mit dem Decodieren nicht mehr stimmt. Wenn ich Kanal 10 STOP betätige:
2019.02.04 20:25:32 3: SIGNALduino: SD_Jaro_Parse device with rawData=C6DDA9BD9000F59240
2019.02.04 20:25:32 5: ######## DEBUG PARSE - START ########
2019.02.04 20:25:32 5: SIGNALduino: SD_Jaro_Parse - RAWMSG =
2019.02.04 20:25:32 5: SIGNALduino: SD_Jaro_Parse - bitData = 110001101101110110101001101111011001000000000000111101011001001001000000
2019.02.04 20:25:32 5: SIGNALduino: SD_Jaro_Parse encoded <- | -> decrypts
2019.02.04 20:25:32 5: SIGNALduino: SD_Jaro_Parse Grp 0-7 |digitS/N| counter | ch | serial | bt |Grp 8-15
2019.02.04 20:25:32 5: SIGNALduino: SD_Jaro_Parse - bitData = 11000110 11011101 10101001 10111101 1001 000000000000111101011001 0010 01000000
2019.02.04 20:25:32 5: SIGNALduino: SD_Jaro_Parse - bitData = |-> must be calculated! <-| 1001 100110101111000000000000 0100 00000010
2019.02.04 20:25:32 5: SIGNALduino: SD_Jaro_Parse - group_value_text 8-15 (1) = 10
2019.02.04 20:25:32 5: ######## DEBUG PARSE - for LSB & MSB Keys ########
2019.02.04 20:25:32 5: SIGNALduino: SD_Jaro_Parse - HopCode = 3180706659
2019.02.04 20:25:32 5: SIGNALduino: SD_Jaro_Parse - decrypts (1) = 699334665
2019.02.04 20:25:32 5: SIGNALduino: SD_Jaro_Parse - decrypts (2) = 1773076489
2019.02.04 20:25:32 5: SIGNALduino: SD_Jaro_Parse - rx_device_key_lsb = 875375598
2019.02.04 20:25:32 5: SIGNALduino: SD_Jaro_Parse - rx_device_key_msb = 1949117422
2019.02.04 20:25:32 5: SIGNALduino: SD_Jaro_Parse - Decoded (HopCode,MSB,LSB) = 3797329056
2019.02.04 20:25:32 5: SIGNALduino: SD_Jaro_Parse - Decoded (bin) = 11100010010101101010010010100000
2019.02.04 20:25:32 5: SIGNALduino: SD_Jaro_Parse Grp 0-7 |digitS/N| counter
2019.02.04 20:25:32 5: SIGNALduino: SD_Jaro_Parse - Decoded (bin split) = 11100010 01010110 1010010010100000
2019.02.04 20:25:32 5: ######## DEBUG only with LSB & MSB Keys ########
2019.02.04 20:25:32 5: SIGNALduino: SD_Jaro_Parse - channelpart1 (group 0-7) = 11100010
2019.02.04 20:25:32 5: SIGNALduino: SD_Jaro_Parse - group_value_text 0-7 (2) = 2,6,7,8
2019.02.04 20:25:32 5: SIGNALduino: SD_Jaro_Parse - group_value_text 0-15 (3) = 2,6,7,8,10
2019.02.04 20:25:32 5: SIGNALduino: SD_Jaro_Parse - last_digits (bin) = 01010110 (only 4 bits 0110 = decrypts ch reversed 1001)
2019.02.04 20:25:32 5: SIGNALduino: SD_Jaro_Parse - last_digits (channel from encoding) = 7
2019.02.04 20:25:32 5: SIGNALduino: SD_Jaro_Parse - countervalue (receive) = 42144
2019.02.04 20:25:32 5: ######## DEBUG without LSB & MSB Keys ########
2019.02.04 20:25:32 5: SIGNALduino: SD_Jaro_Parse - decrypts button = stop
2019.02.04 20:25:32 5: SIGNALduino: SD_Jaro_Parse - decrypts ch + serial = 162463753 (at each channel changes)
2019.02.04 20:25:32 5: SIGNALduino: SD_Jaro_Parse - decrypts ch + serial (bin) = 1001101011110000000000001001
2019.02.04 20:25:32 5: SIGNALduino: SD_Jaro_Parse - decrypts serial = 10153984 (for each channel)
2019.02.04 20:25:32 5: SIGNALduino: SD_Jaro_Parse - decrypts serial (bin) = 100110101111000000000000 (for each channel)
2019.02.04 20:25:32 5: SIGNALduino: SD_Jaro_Parse - decrypts channel (from serial | bin) = 1001
2019.02.04 20:25:32 5: SIGNALduino: SD_Jaro_Parse - decrypts channel (from serial) = 10
2019.02.04 20:25:32 5: SIGNALduino: SD_Jaro_Parse - decrypts channelpart2 (group 8-15) = 00000010
2019.02.04 20:25:32 5: SIGNALduino: SD_Jaro_Parse - decrypts channel_control = 2,6,7,8,10
2019.02.04 20:25:32 5: SIGNALduino: SD_Jaro_Parse - user_modus = all_functions
2019.02.04 20:25:32 5: SIGNALduino: SD_Jaro_Parse - user_info = none
2019.02.04 20:25:32 5: ######## DEBUG END ########
2019.02.04 20:25:33 1: di_Fenster_unknowncode Event: UNKNOWNCODE u40#7244AC84DFFE14DB7C
2019.02.04 20:25:33 3: SIGNALduino: SD_Jaro_Parse device with rawData=C6DDA9BD9000F59240
2019.02.04 20:25:33 5: ######## DEBUG PARSE - START ########
2019.02.04 20:25:33 5: SIGNALduino: SD_Jaro_Parse - RAWMSG =
2019.02.04 20:25:33 5: SIGNALduino: SD_Jaro_Parse - bitData = 110001101101110110101001101111011001000000000000111101011001001001000000
2019.02.04 20:25:33 5: SIGNALduino: SD_Jaro_Parse encoded <- | -> decrypts
2019.02.04 20:25:33 5: SIGNALduino: SD_Jaro_Parse Grp 0-7 |digitS/N| counter | ch | serial | bt |Grp 8-15
2019.02.04 20:25:33 5: SIGNALduino: SD_Jaro_Parse - bitData = 11000110 11011101 10101001 10111101 1001 000000000000111101011001 0010 01000000
2019.02.04 20:25:33 5: SIGNALduino: SD_Jaro_Parse - bitData = |-> must be calculated! <-| 1001 100110101111000000000000 0100 00000010
2019.02.04 20:25:33 5: SIGNALduino: SD_Jaro_Parse - group_value_text 8-15 (1) = 10
2019.02.04 20:25:33 5: ######## DEBUG PARSE - for LSB & MSB Keys ########
2019.02.04 20:25:33 5: SIGNALduino: SD_Jaro_Parse - HopCode = 3180706659
2019.02.04 20:25:33 5: SIGNALduino: SD_Jaro_Parse - decrypts (1) = 699334665
2019.02.04 20:25:33 5: SIGNALduino: SD_Jaro_Parse - decrypts (2) = 1773076489
2019.02.04 20:25:33 5: SIGNALduino: SD_Jaro_Parse - rx_device_key_lsb = 875375598
2019.02.04 20:25:33 5: SIGNALduino: SD_Jaro_Parse - rx_device_key_msb = 1949117422
2019.02.04 20:25:33 5: SIGNALduino: SD_Jaro_Parse - Decoded (HopCode,MSB,LSB) = 3797329056
2019.02.04 20:25:33 5: SIGNALduino: SD_Jaro_Parse - Decoded (bin) = 11100010010101101010010010100000
2019.02.04 20:25:33 5: SIGNALduino: SD_Jaro_Parse Grp 0-7 |digitS/N| counter
2019.02.04 20:25:33 5: SIGNALduino: SD_Jaro_Parse - Decoded (bin split) = 11100010 01010110 1010010010100000
2019.02.04 20:25:33 5: ######## DEBUG only with LSB & MSB Keys ########
2019.02.04 20:25:33 5: SIGNALduino: SD_Jaro_Parse - channelpart1 (group 0-7) = 11100010
2019.02.04 20:25:33 5: SIGNALduino: SD_Jaro_Parse - group_value_text 0-7 (2) = 2,6,7,8
2019.02.04 20:25:33 5: SIGNALduino: SD_Jaro_Parse - group_value_text 0-15 (3) = 2,6,7,8,10
2019.02.04 20:25:33 5: SIGNALduino: SD_Jaro_Parse - last_digits (bin) = 01010110 (only 4 bits 0110 = decrypts ch reversed 1001)
2019.02.04 20:25:33 5: SIGNALduino: SD_Jaro_Parse - last_digits (channel from encoding) = 7
2019.02.04 20:25:33 5: SIGNALduino: SD_Jaro_Parse - countervalue (receive) = 42144
2019.02.04 20:25:33 5: ######## DEBUG without LSB & MSB Keys ########
2019.02.04 20:25:33 5: SIGNALduino: SD_Jaro_Parse - decrypts button = stop
2019.02.04 20:25:33 5: SIGNALduino: SD_Jaro_Parse - decrypts ch + serial = 162463753 (at each channel changes)
2019.02.04 20:25:33 5: SIGNALduino: SD_Jaro_Parse - decrypts ch + serial (bin) = 1001101011110000000000001001
2019.02.04 20:25:33 5: SIGNALduino: SD_Jaro_Parse - decrypts serial = 10153984 (for each channel)
2019.02.04 20:25:33 5: SIGNALduino: SD_Jaro_Parse - decrypts serial (bin) = 100110101111000000000000 (for each channel)
2019.02.04 20:25:33 5: SIGNALduino: SD_Jaro_Parse - decrypts channel (from serial | bin) = 1001
2019.02.04 20:25:33 5: SIGNALduino: SD_Jaro_Parse - decrypts channel (from serial) = 10
2019.02.04 20:25:33 5: SIGNALduino: SD_Jaro_Parse - decrypts channelpart2 (group 8-15) = 00000010
2019.02.04 20:25:33 5: SIGNALduino: SD_Jaro_Parse - decrypts channel_control = 2,6,7,8,10
2019.02.04 20:25:33 5: SIGNALduino: SD_Jaro_Parse - user_modus = all_functions
2019.02.04 20:25:33 5: SIGNALduino: SD_Jaro_Parse - user_info = none
2019.02.04 20:25:33 5: ######## DEBUG END ########
2019.02.04 20:25:33 1: di_Fenster_unknowncode Event: UNKNOWNCODE u40#7244AC84DFFE14DB7C
2019.02.04 20:25:33 3: SIGNALduino: SD_Jaro_Parse device with rawData=C6DDA9BD9000F59240
2019.02.04 20:25:33 5: ######## DEBUG PARSE - START ########
2019.02.04 20:25:33 5: SIGNALduino: SD_Jaro_Parse - RAWMSG =
2019.02.04 20:25:33 5: SIGNALduino: SD_Jaro_Parse - bitData = 110001101101110110101001101111011001000000000000111101011001001001000000
2019.02.04 20:25:33 5: SIGNALduino: SD_Jaro_Parse encoded <- | -> decrypts
2019.02.04 20:25:33 5: SIGNALduino: SD_Jaro_Parse Grp 0-7 |digitS/N| counter | ch | serial | bt |Grp 8-15
2019.02.04 20:25:33 5: SIGNALduino: SD_Jaro_Parse - bitData = 11000110 11011101 10101001 10111101 1001 000000000000111101011001 0010 01000000
2019.02.04 20:25:33 5: SIGNALduino: SD_Jaro_Parse - bitData = |-> must be calculated! <-| 1001 100110101111000000000000 0100 00000010
2019.02.04 20:25:33 5: SIGNALduino: SD_Jaro_Parse - group_value_text 8-15 (1) = 10
2019.02.04 20:25:33 5: ######## DEBUG PARSE - for LSB & MSB Keys ########
2019.02.04 20:25:33 5: SIGNALduino: SD_Jaro_Parse - HopCode = 3180706659
2019.02.04 20:25:33 5: SIGNALduino: SD_Jaro_Parse - decrypts (1) = 699334665
2019.02.04 20:25:33 5: SIGNALduino: SD_Jaro_Parse - decrypts (2) = 1773076489
2019.02.04 20:25:33 5: SIGNALduino: SD_Jaro_Parse - rx_device_key_lsb = 875375598
2019.02.04 20:25:33 5: SIGNALduino: SD_Jaro_Parse - rx_device_key_msb = 1949117422
2019.02.04 20:25:33 5: SIGNALduino: SD_Jaro_Parse - Decoded (HopCode,MSB,LSB) = 3797329056
2019.02.04 20:25:33 5: SIGNALduino: SD_Jaro_Parse - Decoded (bin) = 11100010010101101010010010100000
2019.02.04 20:25:33 5: SIGNALduino: SD_Jaro_Parse Grp 0-7 |digitS/N| counter
2019.02.04 20:25:33 5: SIGNALduino: SD_Jaro_Parse - Decoded (bin split) = 11100010 01010110 1010010010100000
2019.02.04 20:25:33 5: ######## DEBUG only with LSB & MSB Keys ########
2019.02.04 20:25:33 5: SIGNALduino: SD_Jaro_Parse - channelpart1 (group 0-7) = 11100010
2019.02.04 20:25:33 5: SIGNALduino: SD_Jaro_Parse - group_value_text 0-7 (2) = 2,6,7,8
2019.02.04 20:25:33 5: SIGNALduino: SD_Jaro_Parse - group_value_text 0-15 (3) = 2,6,7,8,10
2019.02.04 20:25:33 5: SIGNALduino: SD_Jaro_Parse - last_digits (bin) = 01010110 (only 4 bits 0110 = decrypts ch reversed 1001)
2019.02.04 20:25:33 5: SIGNALduino: SD_Jaro_Parse - last_digits (channel from encoding) = 7
2019.02.04 20:25:33 5: SIGNALduino: SD_Jaro_Parse - countervalue (receive) = 42144
2019.02.04 20:25:33 5: ######## DEBUG without LSB & MSB Keys ########
2019.02.04 20:25:33 5: SIGNALduino: SD_Jaro_Parse - decrypts button = stop
2019.02.04 20:25:33 5: SIGNALduino: SD_Jaro_Parse - decrypts ch + serial = 162463753 (at each channel changes)
2019.02.04 20:25:33 5: SIGNALduino: SD_Jaro_Parse - decrypts ch + serial (bin) = 1001101011110000000000001001
2019.02.04 20:25:33 5: SIGNALduino: SD_Jaro_Parse - decrypts serial = 10153984 (for each channel)
2019.02.04 20:25:33 5: SIGNALduino: SD_Jaro_Parse - decrypts serial (bin) = 100110101111000000000000 (for each channel)
2019.02.04 20:25:33 5: SIGNALduino: SD_Jaro_Parse - decrypts channel (from serial | bin) = 1001
2019.02.04 20:25:33 5: SIGNALduino: SD_Jaro_Parse - decrypts channel (from serial) = 10
2019.02.04 20:25:33 5: SIGNALduino: SD_Jaro_Parse - decrypts channelpart2 (group 8-15) = 00000010
2019.02.04 20:25:33 5: SIGNALduino: SD_Jaro_Parse - decrypts channel_control = 2,6,7,8,10
2019.02.04 20:25:33 5: SIGNALduino: SD_Jaro_Parse - user_modus = all_functions
2019.02.04 20:25:33 5: SIGNALduino: SD_Jaro_Parse - user_info = none
2019.02.04 20:25:33 5: ######## DEBUG END ########
Eine Gruppe ist definitiv nicht angesteuert. Ich vermute das ist im Zusammenhang mit dem KeeLoq_NLF.
Gruß Bismosa
@bismosa ich denke fast die PERLWARNINGs waren schon auch vorher drin aber bin mit nicht sicher. Versuche gerad diese hin und her zu testen wodurch diese provoziert werden.
@bismosa @gandi1791 @meier81 bitte nun testen.
Ich habe den Fehler ChannelFix auch behoben. Bitte @bismosa nicht so viel auf einmal, denn sonst werden die Fäden länger und ich weiß garnet so wir anfangen sollen ;-) Eher pö a pö hihi
Huhu!
Bitte @bismosa nicht so viel auf einmal,
Sorry. Wollte nur zeigen, dass ich (wenn ich schon zum Glück nicht zum Programmieren komme) wenigstens versuche ausführlich zu testen...das muss dann auch raus, damit ich das nicht wieder vergesse bzw in meiner Zettelwirtschaft verwurste. Werde mir aber Mühe geben :-)
Ich komme leider erst morgen wieder zum testen...stay tuned :-)
Gruß Bismosa
@bismosa @gandi1791 @meier81 bitte nun testen.
Beim Reload gab's diese Meldungen:
Too many arguments for main::SD_Jaro_decrypt at ./FHEM/14_SD_Jaro.pm line 379, near "$name)"
Too many arguments for main::SD_Jaro_decrypt at ./FHEM/14_SD_Jaro.pm line 381, near "$name)"
Too many arguments for main::SD_Jaro_encrypt at ./FHEM/14_SD_Jaro.pm line 387, near "$name)"
Too many arguments for main::SD_Jaro_decrypt at ./FHEM/14_SD_Jaro.pm line 701, near "$name)"
Too many arguments for main::SD_Jaro_decrypt at ./FHEM/14_SD_Jaro.pm line 705, near "$name)"
Too many arguments for main::SD_Jaro_decrypt at ./FHEM/14_SD_Jaro.pm line 709, near "$name)"
Im UI=Einzeilig Modus (ohne ChannelFixed) bekomme ich bei jedem Kanal/jeder Aktion folgende Fehlermeldung links oben angezeigt:
ERROR: your command OptionValue is not support! (not in list)
Sonst passt es von meiner Seite.
Hallo, die Fehler kommen nur, weil kein vollständiger Neustart gemacht wird. Teste bitte mal mit FHem restart und dann reload.
Die Commands bei FixChannel versuche ich zu reproduzieren.
Hallo @HomeAutoUser,
Hallo, die Fehler kommen nur, weil kein vollständiger Neustart gemacht wird. Teste bitte mal mit FHem restart und dann reload.
Danke, das half. Sorry, aber das hier ist meine erste größere Mitarbeit bei einem Projekt wie diesem. Bisher habe ich FHEM soweit nur genutzt. MIt den ganzen FHEM Handlings Themen bin ich noch nicht 100% vertraut. Man möge mir verzeihen :-)
Guten Morgen,
ich habe jetzt wieder getestet. Dabei habe ich noch ein paar PERL Warnings bekommen.
2019.02.06 09:59:35 4: ######## DEBUG SET - START ########
2019.02.06 09:59:35 1: PERL WARNING: Use of uninitialized value $ioname in concatenation (.) or string at ./FHEM/14_SD_Jaro.pm line 278.
2019.02.06 09:59:35 4: : SD_Jaro_Set - cmd=ch1 cmd2=stop
2019.02.06 09:59:35 1: PERL WARNING: Use of uninitialized value $ioname in concatenation (.) or string at ./FHEM/14_SD_Jaro.pm line 289.
2019.02.06 09:59:35 4: : SD_Jaro_Set - v1 -> one channel via setlist | button=stop buttonbits=0100 channel=1
2019.02.06 09:59:36 1: PERL WARNING: Use of uninitialized value $ioname in concatenation (.) or string at ./FHEM/14_SD_Jaro.pm line 393.
2019.02.06 09:59:36 1: PERL WARNING: Use of uninitialized value $ioname in concatenation (.) or string at ./FHEM/14_SD_Jaro.pm line 394.
2019.02.06 09:59:36 1: PERL WARNING: Use of uninitialized value $ioname in concatenation (.) or string at ./FHEM/14_SD_Jaro.pm line 395.
2019.02.06 09:59:36 1: PERL WARNING: Use of uninitialized value $ioname in concatenation (.) or string at ./FHEM/14_SD_Jaro.pm line 396.
2019.02.06 09:59:36 1: PERL WARNING: Use of uninitialized value $ioname in concatenation (.) or string at ./FHEM/14_SD_Jaro.pm line 397.
2019.02.06 09:59:36 1: PERL WARNING: Use of uninitialized value $ioname in concatenation (.) or string at ./FHEM/14_SD_Jaro.pm line 398.
2019.02.06 09:59:36 1: PERL WARNING: Use of uninitialized value $ioname in concatenation (.) or string at ./FHEM/14_SD_Jaro.pm line 399.
2019.02.06 09:59:36 1: PERL WARNING: Use of uninitialized value $ioname in concatenation (.) or string at ./FHEM/14_SD_Jaro.pm line 400.
2019.02.06 09:59:36 1: PERL WARNING: Use of uninitialized value $ioname in concatenation (.) or string at ./FHEM/14_SD_Jaro.pm line 401.
2019.02.06 09:59:36 1: PERL WARNING: Use of uninitialized value $ioname in concatenation (.) or string at ./FHEM/14_SD_Jaro.pm line 402.
2019.02.06 09:59:36 1: PERL WARNING: Use of uninitialized value $ioname in concatenation (.) or string at ./FHEM/14_SD_Jaro.pm line 403.
2019.02.06 09:59:36 1: PERL WARNING: Use of uninitialized value $ioname in concatenation (.) or string at ./FHEM/14_SD_Jaro.pm line 404.
2019.02.06 09:59:36 1: PERL WARNING: Use of uninitialized value $ioname in concatenation (.) or string at ./FHEM/14_SD_Jaro.pm line 417.
2019.02.06 09:59:36 1: PERL WARNING: Use of uninitialized value $ioname in concatenation (.) or string at ./FHEM/14_SD_Jaro.pm line 418.
2019.02.06 09:59:36 1: PERL WARNING: Use of uninitialized value $ioname in concatenation (.) or string at ./FHEM/14_SD_Jaro.pm line 419.
2019.02.06 09:59:36 1: PERL WARNING: Use of uninitialized value $ioname in concatenation (.) or string at ./FHEM/14_SD_Jaro.pm line 420.
2019.02.06 09:59:36 1: PERL WARNING: Use of uninitialized value $ioname in concatenation (.) or string at ./FHEM/14_SD_Jaro.pm line 421.
2019.02.06 09:59:36 4: : SD_Jaro_Set - sendMSG = P87#000110100000110001001110110110010000011100101000011000111101001000000000P#R3
2019.02.06 09:59:36 4: ######## DEBUG SET - END ########
2019.02.06 09:59:36 1: PERL WARNING: Use of uninitialized value $ioname in concatenation (.) or string at ./FHEM/14_SD_Jaro.pm line 425.
2019.02.06 09:59:36 3: : jaro set ch1 stop
2019.02.06 09:59:37 4: ######## DEBUG SET - START ########
2019.02.06 09:59:37 4: : SD_Jaro_Set - cmd=ch8 cmd2=stop
2019.02.06 09:59:37 4: : SD_Jaro_Set - v1 -> one channel via setlist | button=stop buttonbits=0100 channel=8
2019.02.06 09:59:37 4: : SD_Jaro_Set - sendMSG = P87#011111101111011101011001110001001110011100101000011000111101001000000000P#R3
2019.02.06 09:59:37 4: ######## DEBUG SET - END ########
Dies passiert nur nach einem Neustart und wenn kein IODev gesetzt ist (Habe ich auf meinem Testsystem nicht). Danach erst wird automatisch IODev=1 gesetzt und die Fehler verschwinden.
Vielleicht diese Zeile:
my $ioname = $hash->{IODev}{NAME};
Durch diese ersetzten ?
my $ioname = AttrVal($name, "IODev", "");
Aber eigentlich sollte dieser Fall auch nie (im Echtbetrieb) auftreten...ist auch auf meinem Echtsystem nicht passiert :-)
Gruß Bismosa
Hi Jungs,
kam jetzt heute auch mal zum testen, hab hier eine TDRC08 Fernbedienung, habe mal alles durchgespielt, hoch, stop, runter, Einzel- und Gruppenbefehle, Fernbedienung hat sich auch automatisch angelegt mit der Serial, sieht soweit alles gut aus. Im Log hab ich jetzt erstmal keine Fehlermeldungen, hab eigentlich nur folgende Meldungen (sind natürlich unterschiedlich, aber vom Aufbau alle gleich):
SIGNALduino: SD_Jaro_Parse device with rawData=E21F52C50000A77100
Gibt es ansonsten für mich hier noch was zu testen oder kann ich euch hier noch etwas helfen? Das mit dem senden habe ich jetzt mal noch nicht getestet, mein letzter Stand ist das da noch etwas in der SIGNALduino-Software fehlt.
Muss euch aber vorab echt schon mal ein super Lob aussprechen, echt klasse Arbeit.
Gruß Markus
Hallo @all :-) Ich habe soeben mal das modul wieder geupdatet und bitte euch nun das zum testen zu nutzen. 1) Bitte obacht geben! Erst die alten Devices löschen und dann das neue modul ersetzen. 2) In der Hash Datei bitte den Name bei der ID 89 anpassen an SD_JARO und ebenso in der 00_SIGNALduino.pm unter my $clientsSIGNALduino bzw. my %matchListSIGNALduino ebenso.
Grund der Änderung, weil ich das Modul groß geschrieben habe weil es nun auch zum Empfang der Roto Devices geeignet ist. (wenn man die Schlüssel finden sollte.... weil es nach dem selben Prinzip arbeitet)
@meier81
SIGNALduino: SD_Jaro_Parse device with rawData=E21F52C50000A77100
die Meldung ist nur eine Ausgabe welche ich auf einen höheren verbose Level setzen werde.
@bismosa wie hast du den Zustand bekommen ohne IODEV? Das wird IMMER automatisch von FHEM beim Empfang angelegt.
EDIT: @bismosa
Mir ist gerade aufgefallen, das noch irgendwas mit dem Decodieren nicht mehr stimmt. Wenn ich Kanal 10 STOP betätige:
was meinst du damit genau??
So, hab dann mal noch schnell heute morgen vor dem arbeiten gehen das Update gemacht und mal so auf die Husche probiert und getestet, sieht weiterhin alles gut aus, jedenfalls was meine 8-Kanal Fernbedienung betrifft. Ich finde für´s empfangen sieht die Sache echt gut aus, werde heute Mittag nochmal ein wenig probieren. Was fehlt denn jetzt noch zum senden? Ihr sagtet da müsste noch etwas in der SIGNALduino-Firmware angepasst werden?
Gruß Markus
Huhu!
Wow...das sind aber viele Änderungen :-) Ich habe nur leider keine Roto-Fernbedienung zum testen...
In der Hash Datei bitte den Name bei der ID 89 anpassen an SD_JARO und ebenso in der 00_SIGNALduino.pm unter my $clientsSIGNALduino bzw. my %matchListSIGNALduino ebenso.
Ich gehe davon aus, das Du die ID87 meinst? Im Bereich "%matchListSIGNALduino" habe ich bisher noch gar nichts stehen. Was muss da rein?
Leider funktioniert bei mir autocreate nicht mehr. Ich muss nachher nochmal nachschauen, ob ich irgendwo einen Fehler gemacht habe...nach dem manuellen anlegen wird aber problemlos empfangen.
wie hast du den Zustand bekommen ohne IODEV? Das wird IMMER automatisch von FHEM beim Empfang angelegt.
Nö. Ich habe auf meinem Testsystem kein IODEV und habe jetzt gerade frisch (nach Anleitung) das Device erstellt. (define SD_JARO_Device1 SD_JARO 12345678 JaroLift) Dabei ist das IODEV Optional....und somit kein IODEV vorhanden und die PERL-Warnings sind wieder da. Aber das sollte ja auf einem Normalem System mit IODEV und autocreate dann kein Problem sein (?).
Mir ist gerade aufgefallen, das noch irgendwas mit dem Decodieren nicht mehr stimmt. Wenn ich Kanal 10 STOP betätige:
was meinst du damit genau??
Mir wurde z.B. bei Kanal 10 STOP die Kanäle: 2,6,7,8 und 10 erkannt. Aber es war nur Kanal 10. Ist aber seit den letzten Änderungen wieder ok und ist nicht erneut aufgetreten.
Ich denke, du hast extra zum testen einige Ausgaben noch unter "Verbose 3" drin?
Gruß Bismosa
@bismota
Also autocreate hat bei mir einwandfrei funktioniert, jetzt auch richtig, vorher wurde immer die Fernbedienung in einen Raum Names SD_JARO angelegt, jetzt kommt die Fernbedienung in den Raum der (wenn gesetzt) für autocreate definiert wurde, ist bei mir z.B.
attr autocreate device_room Testbereich->Autocreate
ID meinte er glaube ich auch die ID87, bin ich auch heute morgen beim suchen drüber gestolpert.
Wegen dem IODev frage ich mich aber auch warum du keines hast, das legt er bei mir gleich automatisch mit an. Ich drücke 2-3 Mal auf der Fernbedienung die Tasten und dann habe ich ein neues SD_JARO-Device mit den Attributen IODev und room. Habe es eben nochmals ausprobiert, funktioniert genau wie eben beschrieben. Ich glaube das könnte bei dir an dem fehlenden Eintrag in der Hash-Datei liegen, siehe hier: https://github.com/HomeAutoUser/Jaro/issues/1#issuecomment-459753550
Da weiß er wahrscheinlich nicht welchem Modul er das neue Gerät zuordnen soll.
Was fehlt denn jetzt noch zum senden? Ihr sagtet da müsste noch etwas in der SIGNALduino-Firmware angepasst werden?
Es fehlt nichts mehr, Sidey hat es inzwischen angepasst https://github.com/RFD-FHEM/SIGNALDuino/commit/98c834127fbb1edafeef9d611de4a45e6b10c4bb
Ihr habt nun 3 Möglichkeiten:
@HomeAutoUser
$hash->{Match} = "^P(?:87|88)#.*";
Hast Du vor das Protokoll 88 mit zu integrieren? Dann passt als Modulname SD_Rollo evtl besser
$a[0] = $hash->{READINGS}{DDSelected}{VAL};
Dafür gibt es ReadingsVal
Hallo @Ralf9
Hast Du vor das Protokoll 88 mit zu integrieren? Dann passt als Modulname SD_Rollo evtl besser
in der jetzigen Fassung des Modules ist Roto mit drin und daher hatte ich damals JARO genommen für JA = JaroLift & RO = Roto :-D Wenn es unbedingt gewünscht ist, dann tausche ich es auch noch gern. Fakt ist, das Modul ist für Devices welches nach dem selbigen Prinzip arbeiten mit Keeloq Schlüsseln. Vorausgesetzt man besitzt die Schlüssel ansonsten kann man nur das "freie" verarbeiten.
EDIT: @Ralf9 wie ist der Stand der jetzigen rekonstruktion des letzten fehlenden Bits? Ist das variabel 0 bzw. 1 oder stur 0? Bei allem hin und her verlor ich den Durchblick.
Hallo!
Also autocreate hat bei mir einwandfrei funktioniert
Ich glaube das könnte bei dir an dem fehlenden Eintrag in der Hash-Datei liegen, siehe hier: https://github.com/HomeAutoUser/Jaro/issues/1#issuecomment-459753550
Ich konnte es jetzt leider erst mit meinen anderen Fernbedienungen testen. Also: Der Jarolift-Dongle hatte kein autocreate ausgelöst. Alle meine Fernbedienungen schon. Ich weiß aber nicht warum...denn nun nach einem (erneutem) Neustart von FHEM hat es nun auch mit meinem Jarolift-Dongle geklappt. Also erledigt ;-)
Auch habe ich jetzt die Eintragungen (aber erst nach dem Autocreate)
_my %matchListSIGNALduino = (_
` "28:SD_Jaro" => '^P87#.*',`
Nachgeholt. Sorry. Hatte das nach der "alten Anleitung" aus dem alten Faden gemacht, da gab es das noch nicht. Somit ist der Part auch schon beantwortet und erledigt ;-)
Wegen dem IODev frage ich mich aber auch warum du keines hast
Ich habe kein Empfänger an meinem Testsystem. Daher sind die Devices nicht per autocreate sondern manuell von mir erstellt worden. Da ist das IODEV optional...und ich hatte keins angegeben (geht halt nicht, wenn man keinen Empfänger hat)
EDIT: @Ralf9 wie ist der Stand der jetzigen rekonstruktion des letzten fehlenden Bits? Ist das variabel 0 bzw. 1 oder stur 0? Bei allem hin und her verlor ich den Durchblick.
Zumindest in der "v3.3.3-dev_30.12." geht dies noch nicht. (Hier ist es immer 0)
Gruß Bismosa
n'Abend
So, Modul upgedated. Hash Datei angepasst. 00_SIGNALduino.pm angepasst. Alte Devices gelöscht. shutdown restart reload 14_SD_JARO.pm
Autocreate funtkioniert. Readings werden sauber gelesen. Keeloq, LSB und MSB gesetzt > senden möglich
UI=einzeilig gesetz Aber dann...Fehler beim Senden! :-(
ERROR: your command OptionValue is not support! (not in list)
Sonst konnte ich keine Fehler mehr sehen/entdecken.
Klasse Arbeit! Vielen Dank!
Nabend @gandi1791
Aber dann...Fehler beim Senden! :-(
Was genau hast du ausgeführt an Kommandos bzw was steht im Logfile für ein Set? Ich vermute, es gibt derzeit noch differenzen aber dafür muss ich Input erhalten was Ihr genau gemacht habt ;-)
grüße
@bismosa zwecks deinem IO Fehlers, bitte versuche es nochmal bei dem jetzigen Code. Ich möchte mal sehen wo die erste Zeile ist, wo er herummeckert :-) Den "Bug" können wir auch noch abfangen.
Stand nach dem Anlegen bei dir in der GeräteDef IODev drin und war leer oder war dies nicht drin als der Fehler auftrat?
MfG
Was genau hast du ausgeführt an Kommandos bzw was steht im Logfile für ein Set?
UI=einzeilig Dropdown in der UI auf Kanal 1,2,3 oder 4 und Klick auf eines der Symbole (egal welches). Leider kein Eintrag im Log :-(
Hab mir das Roto nochmals angeschaut
In den Handsendern für die Rolläden ist ein HCS301 Rolling Code Chip verbaut.
Das Funkprotokoll ist hier in der technischen Doku zu finden:
http://ww1.microchip.com/downloads/en/DeviceDoc/21143C.pdf
demnach passt es hier mit rein. Sind beim Roto die Schlüssel auch bekannt?
wie ist der Stand der jetzigen rekonstruktion des letzten fehlenden Bits
Das letzte Bit wird anhand des vorderen Teils von one oder zero rekonstruiert. Hier ist ein Beispiel
MS;P1=1524;P2=-413;P3=388;P4=-3970;P5=-815;P6=778;P7=-16024;D=...35626262626262626712323...
one => [1,-2], ergibt 35
zero => [2,-1], ergibt 62
Hier fängt das letzte halbe Bit mit 6 an, also ist es zero.
@gandi1791
Leider kein Eintrag im Log :-(
sehr komisch! Du müsstest mindestens im Logfile den set erhalten. Wenn du sogar auf verbose 4 im Device attrib stellst, sollte das erscheinen
2019.02.07 22:19:04 4: ######## DEBUG SET - START ########
2019.02.07 22:19:04 4: sduino_dummy: SD_JARO_Set - cmd=OptionValue cmd2=up
2019.02.07 22:19:04 4: sduino_dummy: SD_JARO_Set - v3 -> group on setlist (not modified) | button=up buttonbits=1000 channel=OptionValue
2019.02.07 22:19:04 4: sduino_dummy: SD_JARO_Set - v3 -> group on setlist (modified) | button=up buttonbits=1000 channel=OptionValue
2019.02.07 22:19:04 4: sduino_dummy: SD_JARO_Set - sendMSG = P87#11000100000001000111011000101110111111111111011101011001000100000000P#R3
2019.02.07 22:19:04 4: ######## DEBUG SET - END ########
2019.02.07 22:19:04 3: sduino_dummy: SD_JARO_10153984 set OptionValue up
@Ralf9 ist das rekonstruieren nur bei Dir in der Software verankert oder auch bei Sidey? Bei dem Protokoll ist es nämlich sehr interessant, da ich sonst einen Kanal nicht erhalte, weil dieser im letzten Bit hängt.
Diese RAWMSG
MS;P0=-428;P1=393;P2=-3984;P3=-810;P4=795;P6=-16292;P7=1536;D=12134040404040131340404013401340401313131340401313404040134013404013131313404040404040404040404040131313134013401313404013404013404040404040404016701010101010101010101010;CP=1;SP=2;R=229;O;m2;
müsste dann so rekonstruiert aussehen
MS;P0=-428;P1=393;P2=-3984;P3=-810;P4=795;P6=-16292;P7=1536;D=121340404040401313404040134013404013131313404013134040401340134040131313134040404040404040404040401313131340134013134040134040134040404040404040136701010101010101010101010;CP=1;SP=2;R=229;O;m2;
EDIT: Die Schlüssel von roto sind nicht bisher bekannt aber das Modul ist vorbereitet. Der user kann sich auch hinstellen und den Key austesten bis zum Treffer :-D
sehr komisch! Du müsstest mindestens im Logfile den set erhalten.
tut mir Leid, soweit kommt das System wohl gar nicht.
Wenn ich über die Set Liste oder im Mehrzeilig Modus sende ist alles ok.
ist das rekonstruieren nur bei Dir in der Software verankert oder auch bei Sidey?
Hier ist mein Pullrequest: https://github.com/RFD-FHEM/RFFHEM/pull/494
@gandi1791 sehr eigenartig. Da fehlt mir jetzt die Idee. Was steht bei dir im Reading User_info?
Was steht bei dir im Reading User_info?
messages can be received and send!
@gandi1791 Hab egestern auch das gleiche Problem gehabt, werde heute die aktuelle Version einspielen und dann nochmal testen, gebe dann Rückmeldung hier.
Bezüglich dem senden habe ich noch ein paar Probleme. Ich habe bei mir das Attribut Serial_senden
mit der Serial 12345600. Hoffe das ist so richtig, so war es jedenfalls mal bei den Bastelbudenbuben. Habe dann das anlernen probiert, tut sich aber nichts. Jetzt wollt eich mal fragen welche der beiden Anlernversionen hinterlegt ist, die Version hoch/runter und dann stop? Die brauche ich bei mir nämlich, habe ja die neueren Geräte. Habe es aber auch schon händig probiert mit hoch/runter senden und danach ein stop, ging leider auch nicht. Habe dann die Sendewiederholung auf 3 gestellt, auch keine Verbesserung.
Um Versionsunterschiede auszuschließen hab ich die folgenden Versionen eingesetzt:
14_SD_Jaro.pm
von gestern hier aus dem GitHub von HomeAutoUser
Laut den internals vom SIGNALduino sieht es hier wie folgt aus:
version | V 3.3.2.1-rc8 SIGNALduino cc1101 - compiled at Feb 1 2019 17:47:01
versionmodul | v3.3.3-dev_30.12.
Hoffe das sind soweit die richtigen Dateien.
Hallo!
Stand nach dem Anlegen bei dir in der GeräteDef IODev drin und war leer oder war dies nicht drin als der Fehler auftrat?
Gerade nochmal ausprobiert mit der Version von gestern:
define jaro1 SD_Jaro 123456
wird akzeptiert. Es werden die Attribute:
Channels | 1 | deleteattr |
---|---|---|
ShowLearn | 1 | deleteattr |
UI | Mehrzeilig | deleteattr |
room | SD_Jaro | deleteattr |
gesetzt. Kein IODEV!
2019.02.08 11:22:47 3: No I/O device found for jaro1
Wenn ich das Beispiel aus der Doku verwende:
define SD_JARO_Device1 SD_JARO 12345678 JaroLift
Werden keine Attribute und kein IODEV gesetzt.
Nach einem FHEM Neustart sind die Devices auch alle wieder weg...
wrong syntax: define SD_JARO
zwecks deinem IO Fehlers, bitte versuche es nochmal bei dem jetzigen Code. Ich möchte mal sehen wo die erste Zeile ist, wo er herummeckert :-) Den "Bug" können wir auch noch abfangen.
Ich hatte das aktuelle Update...gestern gab es kein Update?
@gandi1791 @HomeAutoUser
Ich kann das Problem mit der einzeiligen UI ebenfalls nachvollziehen.
Das passiert nur, wenn addGroups nicht gesetzt ist und zwar in der Zeile:
return "ERROR: your command $cmd is not support! (not in list)" if ($ret !~ /$cmd/ && $addGroups eq "");
@meier81 versionmodul | v3.3.3-dev_30.12.
Das sollte noch nicht funktionieren. Wohl nur, wenn du neu kompilierst oder die "V 3.3.2.1-rc8" verwendest. Aber die Version habe ich auch noch nicht gefunden...bin mir auch nicht sicher, ob es diese für einen Arduino/CC1101 gibt.
Gruß Bismosa
Habe nun eben auch das Anlernen erfolglos probiert... :-( Ich verwende, wie meier81, die Version V 3.3.2.1-rc8. Versionsmodul: v3.3.3-dev_30.12. Ich frage auch mal: Wie ist der LEARN "Funkspruch"? Lt. meiner Anleitung benötige ich AUF/AB gleichzeitig, danach STOP. Ist das beim LEARN so hinterlegt?
Das passiert nur, wenn addGroups nicht gesetzt Yepp. Mit Attribut gesetzt, ist der Fehler weg.
Hallo! Mögt ihr mir mal bitte verraten, wo ich die V3.3.2.1-rc8 finden kann? Gibt es diese für den nanoCC1101?
Danke. Gruß Bismosa
V3.3.2.1-rc8 https://forum.fhem.de/index.php/topic,82379.0.html
Ich könnte Tipps gebrauchen, wie ich an den KeeLoq_NLF ran kommen kann. Mit der mit Google Suche habe ich nichts gefunden.
Hallo!
@Ralf9 Danke! Da hatte ich wohl Tomaten auf den Augen :-) Das andere: https://github.com/madmartin/Jarolift_MQTT/blob/master/KeeloqLib/src/KeeloqLib.cpp Zeile 8 (ohne UL am Ende) :-)
Gruß Bismsoa
Hallo!
Musste das jetzt auch mal direkt mit dem Senden ausprobieren. So wie es für mich aussieht, ist das "Sync Signal" am Anfang nicht vollständig: Oben mit dem SignalDUINO unten mit der Fernbedienung... (Die schwarzen Striche oben sind nur durch das verschieben in Audacity...haben nichts mit dem Signal zu tun) So sieht das vollständige Signal vom SignalDUINO aus: Der Sync wird scheinbar auch nicht zwischen den Wiederholungen gesendet.
Daher reagieren die Empfänger wohl noch nicht.
Ich frage auch mal: Wie ist der LEARN "Funkspruch"?
"Derzeit" ist der Lern Funkspruch noch die sogenannte "alte Variante". Es gab wohl mal Fernbedienungen mit einer zusätzlichen Taste, die dann einen anderen Funkspruch gesendet hat...der andere Weg ist UPDOWN gefolgt von Stop. Dies wurde aber bisher noch nicht im Code berücksichtigt. (Daher auch die Integration von UpDowwn).
Gruß Bsimsoa
Wenn ich mit sendmsg was sende bekomme ich die folgenden RAW Sendebefehl, wie sieht er bei Dir aus?
sendmsg msg=P87#010011100111111101101011110100000000000000000000011001011111000100000000P#R3
sduinoD/set: sending via SendMsg: SR;R=3;P0=1520;P1=-400;P2=400;P3=-4000;P4=-800;P5=800;P6=-16000;D=01212121212121212121212121235124515124242451512424242424242451242451245124242424512451515151515151515151515151515151515151515124245151245124242424245151512451515151515151516;
Brainstorming...