Signalduino Entwicklung

[ernst1024]

Hallo,

habe seit gestern SIGNALduino installiert und mein Dank geht an den oder die Entwickler.

Eine Frage und ein kurzer Bericht. Frage: kann man das scannen nach neuen codes abschalten?

Hintergrund: Ich schalte meine Funksteckdosen (FSD) mit Hilfe von GenShellSwitch und einer app raspberry-remote. Das klappt wunderbar. Jetzt kam es aber vor, dass ich aus Bequemlichkeit auch schon mal die orig. Fernbedienung benutzt habe. Mit der Folge dass FHEM dies natürlich nicht mitbekommen hat und der Status der FSD nicht korrekt dargestellt wurde. Gut bei 3 FSD's nicht so das Problem, ein klick und es stimmt wieder.

Jetzt kommt SIGNALduino ins Spiel. Ich habe also den Homecode an der Fernbedienung abgeändert und gescannt. Dann, der besseren Zuordnung halber umbenannt und schalte so über ein notify die entsprechende FSD. Das klappt auch gut. Nur erzeugt "set FSD3 $EVENT" wiederum einen neuen Eintrag, diesmal halt mit dem richtigen Homecode, der ja gesendet wird um die entsprechende FSD zu schalten. Und genau das würde ich gerne vermeiden. Gibt es da Hoffnung?

Code Auswählen Erweitern


define IT_FSD3 IT 00FF0FF0FF 0F F0
attr IT_FSD3 IODev Myduino

define FB_FSD3 notify IT_FSD3 set FSD3 $EVENT
   

PS.  quasi als Nebeneffekt kann ich so die bisher unbenutzte vierte Taste der Fernbedienung auch nutzen.

[Ralf9]

Eine Frage und ein kurzer Bericht. Frage: kann man das scannen nach neuen codes abschalten?

Du kannst es mal mit den folgenden autocreate attributen versuchen:

Code Auswählen Erweitern

ignoreTypes
This is a regexp, to ignore certain devices, e.g. the neighbours FHT. You can specify more than one, with usual regexp syntax, e.g.
attr autocreate ignoreTypes CUL_HOERMANN.*|FHT_1234|CUL_WS_7
The word "Types" is somehow misleading, as it actually checks the generated device name.

Code Auswählen Erweitern

autocreateThreshold
A list of <type>:<count>:<interval> triplets. A new device is only created if there have been at least count events of TYPE type in the last interval seconds.
attr autocreateThreshold LaCrosse:2:30,EMT7110:2:60

Gruß Ralf

[Ralf9]

Code Auswählen Erweitern

set sduino disableMessagetype unsyncedMU
ändert leider nichts.

Der Eintrag der Config sieht immer noch gleich aus.

Code Auswählen Erweitern

config: MS=1;MU=1;MC=1

Hast Du für "set disableMessagetype unsyncedMU" und "get config"
die set- und get-Schaltflächen beim sduino benutzt?

Gruß Ralf

[Burny4600]

@Ralf

Hast Du für "set disableMessagetype unsyncedMU" und "get config"
die set- und get-Schaltflächen beim sduino benutzt?

Ja das hatte ich.

Heute wo ich ein Update von FHEM durchgeführt habe wurden die zugehörigen Dateien für den Signalduino wieder ausgetauscht.
Jetzt hat der Befehl "set disableMessagetype unsyncedMU" auch eine Änderung hervor gerufen.

Der Signalduino ließt MC Daten ein, aber diese werden nicht als Senorwerte geschrieben.

Ergänzend noch das zugehörige Log:

[Ralf9]

@RalfJa das hatte ich.

Heute wo ich ein Update von FHEM durchgeführt habe wurden die zugehörigen Dateien für den Signalduino wieder ausgetauscht.
Jetzt hat der Befehl "set disableMessagetype unsyncedMU" auch eine Änderung hervor gerufen.

Der Signalduino ließt MC Daten ein, aber diese werden nicht als Senorwerte geschrieben.

Ergänzend noch das zugehörige Log:

Hat die "41_OREGON.pm" noch die aktuelle Version?

Code Auswählen Erweitern

$Id: 41_OREGON.pm 34476 2016-02-09 21:00:00 wherzig

Es wurde was erkannt,

Code Auswählen Erweitern

2016.03.14 20:04:30 5: sduino dispatch 581A8904B070C000000034D9
2016.03.14 20:04:30 3: OREGON: Unknown device WGR800_b0, please define it
2016.03.14 20:04:30 2: autocreate: define WGR800_b0 OREGON WGR800_b0
aber es werden nur recht wenige brauchbare MC-Nachrichten empfangen. Falls zuwenige brauchbare MC-Nachrichten empfangen werden, kannst Du mal versuchen ob es mit der Firmware dev32-b12 besser wird.

Nachtrag:
hier

Code Auswählen Erweitern

update all https://raw.githubusercontent.com/RFD-FHEM/RFFHEM/dev-dooya/controls_signalduino.txt
ist die
V 3.2.0-b12 SIGNALduino - compiled at Feb 13 2016 21:34:09
dabei

Gruß Ralf

[Sidey]

Warum jetzt eigendlich opened?
Ist für mich nicht logisch.

Das ist ein FHEM Standardwert. Nutzt man andere Standardwerte, funktionieren manche internen Funktionen von FHEM nicht
Da ich möglichst viele Standardfunktionen nutzen möchte, hatte ich das geändert.
Ich muss dass wohl noch im Wiki nachpflegen.

Dieser Eintrag sieht jetzt auch nicht mehr sauber aus.

Ist ein Formatierungsfehler. Ich werde es korrigieren. Das größere Problem sehe ich aber beim MC Decoder.
Den wollte ich verbessern und es ist wohl eher schlechter geworden

Grüße Sidey

[Ralf9]

Das größere Problem sehe ich aber beim MC Decoder.
Den wollte ich verbessern und es ist wohl eher schlechter geworden

Bei dem log von Burny4600 ist mir aufgefallen, daß bei einigen MC-Nachrichten das Ende nicht richtig erkannt wurde:

MC;LL=-1045;LH=899;SL=-564;SH=413;D=FFFFFF5891200D0E030000002C9BFFFFFE;C=437;
hier ist dies "FFFFFE" am Ende zuviel.

MC;LL=-557;LH=-1047;SL=416;SH=-124;D=FFFFFEB122401A1C06000000593700;C=431;
hier ist dies "00" am Ende zuviel.

Gruß Ralf

[Sidey]

Bei dem log von Burny4600 ist mir aufgefallen, daß bei einigen MC-Nachrichten das Ende nicht richtig erkannt wurde:

MC;LL=-1045;LH=899;SL=-564;SH=413;D=FFFFFF5891200D0E030000002C9BFFFFFE;C=437;
hier ist dies "FFFFFE" am Ende zuviel.

Das  FFFFFE am Ende müsste von der Wiederholung stammen.
Problem ist nur, dass es nur 21 x 1er Bits sind. Wir hätten aber 24 gebraucht.

BFFFFFE wären 24x 1er Bits.
1011 1111 1111 1111 1111 1111 1110

Kannst Du vielleicht mal schauen, ob man in der OSV3 Funktion nach 24x1er Bits suchen könnte und das als Ende markiert.

MC;LL=-557;LH=-1047;SL=416;SH=-124;D=FFFFFEB122401A1C06000000593700;C=431;
hier ist dies "00" am Ende zuviel.

Wo kommt das nur her, hmmmm.....


Grüße Sidey

[Ralf9]

Das  FFFFFE am Ende müsste von der Wiederholung stammen.

Das Problem dabei ist aber, daß es laut der Protokollbeschreibung beim OSV3 keine Wiederholung gibt..

Es ist wahrscheinlich am Besten, wenn Du erstmal die dev32-b12 Firmware in die master tust. 

Gruß Ralf

[Sidey]

Hi Ralf,

guter Hinweis. Das hatte ich übersehen.

Das würde bedeuten, dass ich hier im Speicher vermutlich etwas verdoppele.....

Das mit der b12 ist eine gute Idee. Obwohl da auch nicht alles rund läuft.

Ein paar Anhaltspunkte was nicht optimal gelöst ist, habe ich schon. Allerdings tappe ich im großen und Ganzen noch im Dunkeln, warum das mit älteren FW Versionen besser gewesen sein soll.

Grüße Sidey

[RappaSan]

Hallo Sidey,
"FHEM Standardwert opened":
Bei mir steht aber für einen funktionierenden CUL im STATE "Initialized".

[Sidey]

Hallo Rappasan,


das CUL Modul nutzt auch nicht die Standardfunktionen, sondern eigene. Schau dir z.B. das Mysensors Modul an, das verwendet die Standardfunktionen.


Grüße Sidey

[Ralf9]

Hallo Sidey,

bei Bedarf kann ich im 00_SIGNALduino.pm für die ca 7 Oregon v3 Sensoren eine Hash Liste anlegen, in der zu den ID die Länge hinterlegt ist.
Dann ist es egal, wenn die Nachrichten zu lang sind.

Hast Du bei der aktuellen dev32 Version die set- und get-Befehle durchgetestet ob noch alles funktioniert?

Gruß Ralf

[sash.sc]

Hallo leute. Wollte mal dazwischen hauen. Habe seit dem letzten Firmware Update des Signal Duino auf die 3.2.0 hf1 öfters das Problem, dass fhem abstürzt. Habe auch mal in der log Datei nachgeschaut. Da steht nix auffälliges drin. Habe den Duino mal auf inaktiv gesetzt und seit dem ist Ruhe.

Kann jemand was dazu sagen?

Hatte vorher die 3.1.8 drauf gehabt

Gruß Sascha

Von mobil gesendet daher kurze Antwort

[michiatlnx]

Hallo, das kann ich bestätigen seit dem Letzten Update hängt sich fhem nach ein paar Stunden auf und nur ein kurzes entfernen und einstecken des sduino Sticks läuft es wieder, bis er wieder hängt.

Was ich dazu herausgefunden habe:
fhem hängt sich nach ein paar Stunden auf, (Perl Prozess auf 100%, am sduino 2 LED rotes Dauer leuchten), mit der Version von:
https://raw.githubusercontent.com/RFD-FHEM/RFFHEM/master/controls_signalduino.txt
V 3.2.0-hf1 SIGNALduino - compiled at Mar 4 2016 22:41:08

Seit dem läuft auch mein TFA Temp Sensor mit dem CUL_TX nicht mehr, die anderen schon wie Oregon und SD_WS07.

Leider ist auch kein Betrieb mit dieser Version möglich, von:
https://raw.githubusercontent.com/RFD-FHEM/RFFHEM/dev-r32/controls_signalduino.txt
V 3.2.0-b14 SIGNALduino - compiled at Mar 4 2016 22:13:07
2016.03.17 17:23:57 1: reload: Error:Modul 00_SIGNALduino deactivated:
Too many arguments for main::RemoveInternalTimer at ./FHEM/00_SIGNALduino.pm line 1516, near ""SIGNALduino_HandleWriteQueue")"
BEGIN not safe after errors--compilation aborted at ./FHEM/00_SIGNALduino.pm line 2093, <$fh> line 313.
2016.03.17 17:23:57 0: Too many arguments for main::RemoveInternalTimer at ./FHEM/00_SIGNALduino.pm line 1516, near ""SIGNALduino_HandleWriteQueue")"
BEGIN not safe after errors--compilation aborted at ./FHEM/00_SIGNALduino.pm line 2093, <$fh> line 313.

Ein Downgrade/restore (flash und Perl Module) auf die vorher laufende Version ist auch nicht mehr möglich.
Der sduino wird nicht mehr im fhem initialisiert.
2016.03.17 17:53:54 1: define: /dev/serial/by-id/usb-FTDI_FT232R_USB_UART_A600D0WR-if00-port0@57600
2016.03.17 17:53:54 1: init: /dev/serial/by-id/usb-FTDI_FT232R_USB_UART_A600D0WR-if00-port0@57600
2016.03.17 17:54:06 1: Cannot init /dev/serial/by-id/usb-FTDI_FT232R_USB_UART_A600D0WR-if00-port0, ignoring it (sduino)

Zur Zeit läuft der sduino mit V 3.2.0-hf1 und ich muss ihn alle paar Stunden reconnecten.