Signalduino Entwicklung

[Sidey]

Was dieser Empfänger alles aufnimmt.
Das müssen Teile von meinen Nachbarn sein.

Nur mit den eigenen Sensoren hat das Teil noch seine Macken.

Hi Burny,

ich hab mir dein Log mal angesehen... ohne zu wissen, was diese Nachrichten sendet wird es schwierig.
Die Manchester Daten sehen ja prinzipiell nicht übel aus, aber ein Oregon Device ist das meiner Meinung nach nicht, was da sendet.

Welche Sensoren hast Du denn, die Du gerne empfangen würdest?

Edit:

Code Auswählen Erweitern


2015-11-27 13:18:33-MC;LL=-1036;LH=922;SL=-565;SH=457;D=FFFFFF5F1426100A040E41C27700;C=459;


Das müsste ein Oregon V3 Sensor sein.


Muss noch mal ergänzen:



Grüße Sidey

[Ralf9]

Hi Burny,

Welche Sensoren hast Du denn, die Du gerne empfangen würdest?

Hallo  Sidey,

er verwendet die folgenden Oregon Sensoren:
PCR800
THGR810
THWR800
UVN800
WGR800

Ich habe dazu folgendes gefunden, da sind die Sensoren alle dabei. Die Sensoren verwenden demnach die Protokoll Versionen 2.1 und 3.
http://wmrx00.sourceforge.net/Arduino/OregonScientific-RF-Protocols.pdf

Gruß Ralf

[Ralf9]

Wäre es sinnvol das SIGNALduino-Modul so zu ändern, dass ein Event beim Beschreiben von DMSG erzeugt wird, wenn ein Protokoll erkannt wird, für das es (noch) kein Modul gibt?

Ich habe dies in den dev-r32 Branch eingebaut.
Wie aktualisiere ich nun die controls_signalduino.txt, damit das update wieder funktioniert?

Gruß Ralf

[Sidey]

Ich habe dies in den dev-r32 Branch eingebaut.

Ähm, Du hast doch jetzt eingebaut, wenn eine Nachricht mit u beginnt.
Ganz unabhängig davon, ob ein Modul den kram verarbeitet oder nicht.

Wäre besser auf das Ergebnis von dispatch zu reagieren finde ich. Oder den event immer setzen, dann kann man auch immer darauf triggern.


Grüße Sidey

[Ralf9]

Ähm, Du hast doch jetzt eingebaut, wenn eine Nachricht mit u beginnt.
Ganz unabhängig davon, ob ein Modul den kram verarbeitet oder nicht.

Wäre besser auf das Ergebnis von dispatch zu reagieren finde ich. Oder den event immer setzen, dann kann man auch immer darauf triggern.

Den Nachrichten, die mit u beginnen ist doch kein Modul zugeordent. Wenn dann einer Nachricht die mit u beginnt ein Modul zugeordnet wird, dann wird doch aus dem "u" z.B. ein "P"

Das event immer zu setzen finde ich nicht so gut, das erzeugt nur unnötige Last in fhem und beim doif. Der gesetzte event erzeugt auch bei jedem Dispatcher Aufruf im "Event monitor" einen zusätzlichen Eintrag.

Gruß Ralf

[Sidey]

Hi Ralf,

Dispatch wird doch immer aufgerufen, wenn es eine Nachricht gibt.
Dispatch gibt meiner Meinung nach auch zurück, ob die Nachricht verarbeitet werden konnte.

Was genau erzeugt da nun mehr Last?
Irgendwas habe ich vermutlich über sehen.

Grüße Sidey

[Sidey]

Hi Ralf,

Dispatch wird doch immer aufgerufen, wenn es eine Nachricht gibt.
Dispatch gibt meiner Meinung nach auch zurück, ob die Nachricht verarbeitet werden konnte.

Was genau erzeugt da nun mehr Last?
Irgendwas habe ich vermutlich über sehen.

Grüße Sidey

[Ralf9]

Dispatch wird doch immer aufgerufen, wenn es eine Nachricht gibt.
Dispatch gibt meiner Meinung nach auch zurück, ob die Nachricht verarbeitet werden konnte.

Durch diesen Eintrag in der matchlist können doch alle Nachrichten verarbeitet werden. Ich welchen Fällen gibt der Dispatch zurück, daß er eine Nachricht, für die es kein Modul gibt,  nicht verarbeiten konnte?

Code Auswählen Erweitern

"X:SIGNALduino_un" => '^[uP]\d+#.*',

Hast Du Dir das schon mal im event monitor angeschaut?


Nachtrag (anderes Thema):

spricht was dagegen bei der "sub SIGNALduino_Read($)"
bei dem folgenden logging  ein "if($debug);" anzuhängen, damit das loglevel 5 übersichtlicher wird?

Code Auswählen Erweitern

Log3 $name, 5, "SIGNALduino/RAW READ: $SIGNALduinodata/$buf";

Gruß Ralf

[Burny4600]

@Sidey

Verwende aktuell die SIGNALduino Version V 3.2.0-b3 SIGNALduino - compiled at Nov 13 2015 21:39:55.
Anbei noch einige Infos aus meinen Logs.
Vielleicht hilft es.

[Burny4600]

Teil 1 fhem-2015-11.z01

[Burny4600]

Teil 2 fhem-2015-11.z02

[Ralf9]

Wie aktualisiere ich nun die controls_signalduino.txt, damit das update wieder funktioniert?

ich habe mal die "build_controls_list.pl" ausgeführt, aber irgendwas passt nicht:

Code Auswählen Erweitern

/dev-r32> perl build_controls_list.pl
invalid top directory at /usr/lib/perl5/5.18.1/File/Find.pm line 472.

Gruß Ralf

[hjgode]

ich habe mal die "build_controls_list.pl" ausgeführt, aber irgendwas passt nicht:

Code Auswählen Erweitern

/dev-r32> perl build_controls_list.pl
invalid top directory at /usr/lib/perl5/5.18.1/File/Find.pm line 472.

Gruß Ralf

Das build_controls_list.pl habe ich verbrochen.

Du must das Verzeichnis mit den FHEM Dateien angeben. Bei mir liegt das build_controls_list.pl zusammen mit der Datei controls_signalduino.txt und anderen in einem Verzeichnis oberhalb von einem FHEM Verzeichnis:

Code Auswählen Erweitern

build_controls_list.pl
CHANGED
controls_signalduino.txt
FHEM<dir>
LICENSE
README.md


Im FHEM Verzeichnis liegen die SignalDuino Modul Dateien und das firmware Verzeichnis:

Code Auswählen Erweitern


00_SIGNALduino.pm 
14_SD_AS.pm   
14_SIGNALduino_RSL.pm 
firmware<dir>
14_Hideki.pm       
14_SD_WS07.pm 
90_SIGNALduino_un.pm

Das ist die Struktur wie man sie von github bekommt.

Das build_controls_list.pl wird dann aus dem Verzeichnis oberhalb von FHEM unter Angabe des FHEM Verzeichnis (aber nicht Dein FHEM Server Verzeichnis, sondern das SignalDuino FHEM Verzeichnis wo Du den geänderten Code hast) aufgerufen:

Code Auswählen Erweitern

perl ./build_controls_list.pl FHEM

und sollte dann sowas ausgeben:

Code Auswählen Erweitern


DEL FHEM/14_Cresta.pm
DEL FHEM/14_SIGNALduino_AS.pm
DEL FHEM/14_SIGNALduino_ID7.pm
DEL FHEM/14_SIGNALduino_un.pm
DEL FHEM/firmware/SIGNALduino_nano328.hex
DEL FHEM/firmware/SIGNALduino_promini328.hex
DEL FHEM/firmware/SIGNALduino_uno.hex
UPD 2015_11_10_09:03:52 7779    FHEM/14_SIGNALduino_RSL.pm
UPD 2015_29_11_07:00:26 12128   FHEM/14_Hideki.pm
UPD 2015_29_11_07:00:26 12225   FHEM/90_SIGNALduino_un.pm
UPD 2015_29_11_07:00:26 52639   FHEM/firmware/SIGNALduino_nano328.hex
UPD 2015_29_11_07:00:26 52639   FHEM/firmware/SIGNALduino_uno.hex
UPD 2015_29_11_07:00:26 54484   FHEM/firmware/SIGNALduino_promini328.hex
UPD 2015_29_11_07:00:26 72795   FHEM/00_SIGNALduino.pm
UPD 2015_29_11_07:00:26 8939    FHEM/14_SD_WS07.pm
UPD 2015_29_11_07:00:26 9830    FHEM/14_SD_AS.pm

Gruss

Josef

[Ralf9]

Code Auswählen Erweitern


2015-11-27 13:18:33-MC;LL=-1036;LH=922;SL=-565;SH=457;D=FFFFFF5F1426100A040E41C27700;C=459;


Das müsste ein Oregon V3 Sensor sein.
Muss noch mal ergänzen:

Hallo Sidey,

Ich hab mir die Oregon Protokollbeschreibung mal angeschaut
http://wmrx00.sourceforge.net/Arduino/OregonScientific-RF-Protocols.pdf

Code Auswählen Erweitern

The preamble consists of "1" bits, 24 bits (6 nibbles) for v3.0 sensors
and 16 bits (4 nibbles) for v2.1 sensors (since a v2.1 sensor bit stream
contains an inverted and interleaved copy of the data bits, there is in
fact a 32 bit sequence of alternating "0" and "1" bits in the preamble).

A sync nibble (4-bits) which is "0101" in the order of transmission. With
v2.1 sensors this actually appears as "10011001". Since nibbles are sent
LSB first, the preamble nibble is actually "1010" or a hexadecimal "A
".

Man müsste doch für v2.1 und v3 eine gemeinsame Protokoll ID verwenden können und in einer "sub SIGNALduino_OSV23" anhand der Preamble+Sync zwischen v2.1 und v3 unterscheiden können, oder mache ich da einen Denkfehler?

Hier ist die Preamble+Sync v3
1111 1111 1111 1111 1111 1111 0101  in Hex:  FFFFFF5

Hier ist die Preamble+Sync v2.1
01010101 01010101 01010101 01010101 10011001  in Hex: 55555555AA

Code Auswählen Erweitern


sub SIGNALduino_OSV23()
{
my ($name,$bitData,$id) = @_;

my $preambleSyncV21 = '0101010101010101010101010101010110011001';
my $preambleSyncV3 = '1111111111111111111111110101';

if (index($bitData, $preambleSyncV21) != -1) {  # Valid OSV2.1 detected

else if (index($bitData, $preambleSyncV3 != -1) {  # Valid OSV3 detected


Gruß Ralf

[Sidey]

Man müsste doch für v2.1 und v3 eine gemeinsame Protokoll ID verwenden können und in einer "sub SIGNALduino_OSV23" anhand der Preamble+Sync zwischen v2.1 und v3 unterscheiden können, oder mache ich da einen Denkfehler?

Hi Ralf,

Auf der Signalseite unterscheiden sich v2 und v3 nur geringfügig. Da hast Du recht.
Somit müssten v3 Nachrichten schon heute prinzipiell passen.

So wie v2 heute erkannt wird, lässt sich das auch auf v3 erweitern. Es ist allerdings zu.bedenken, dass die Preamble auch dazu genutzt wird, dass der Empfänger seinen Pegel anpasst. Deshalb ist nicht damit zu rechnen, dass der Empfänger alle Bits von der Preamble auch empfängt.

Kannst ja noch mal in den code schauen. Ich habe zuerst das Sync Nibble gesucht und anschließend die davorliegende Sequenz analysiert.
Die Toleranzgrenze liegt glaube ich bei 24 Bit.

Bei v3 würde ich diese vermutlich auf 11 oder 12 setzen.
Das viel größere Problem dürfte aber sein, dass das Oregon Modul die Daten nicht unbedingt so erwartet, wie sie empfangen werden.

Grüße Sidey


Grüße Sidey