Signalduino Entwicklung

[Sidey]

Hi Ralf,

spricht aus deiner Sicht etwas dagegen, den Zweig proto7 nach rawIn zu überführen?
Soweit ich das sehe, funktioniert die Implementierung und wir könnten das zusammenführen.

GGf. notwendige Korrekturen können ja weiterhin erfolgen, sofern notwendig.


Grüße Sidey

[Ralf9]

spricht aus deiner Sicht etwas dagegen, den Zweig proto7 nach rawIn zu überführen?

nein spricht nichts dagegen.

Gruß Ralf

[Sidey]

Wenn man in FHEM anstatt des Devices auch einfach die IP+Port angeben kann, dann sollte zuminderst die Sache mit socat schon funktionieren.

Wozu Du da socat benötigst weiss ich jetzt nicht.
Den SIGNALDuino würde man z.B. so definieren:

Code Auswählen Erweitern

define sdnet SIGNALduino 10.2.11.200:45000

Dann versucht FHEM die Verbindung zu dieser Adresse mit angegebenem Port via TCP.
Dort könnte z.B. der ESP8226 lauschen.

Zu den Speichergrößen kann ich dir auf Anhieb nichts sagen, denke aber, dass das klappen sollte.

Die einfachste Variante wäre, den ESP8226 als reines Übertragungsgerät anzubinden.
Also z.B. einen Nano mit dem Signalduino Code drauf und den ESP8226 an die Seriellen Ports angehangen.

Im Signalduino code müssten nach meiner ersten Einschätzung nur ein paar AT Kommandos für das Initialisieren eingebaut werden.
Anschließend dürfte dann die Kommunikation schon laufen.
Aus meiner Sicht ist das eine realistische und leicht zu implementierende Variante. Hast Du einen ESP8226 und kannst das mal ausprobieren?

Grüße Sidey

[Ralf9]

Über Ws5100 wird wohl auf nem Arduino Uno/Nano/Mini auch nix gehen, das RAM ist ja schon ziemlich ausgelastet

Braucht der Ws5100 überhaupt viel RAM,

Code Auswählen Erweitern

The W5100 includes fully hardwired, market-proven TCP/IP stack and integrated Ethernet MAC & PHY. 
Hardwired TCP/IP stack supports TCP, UDP, IPv4, ICMP, ARP, IGMP and PPPoE
which has been proven in various applications for several years. 16Kbytes internal buffer is included for data transmission.
No need of consideration for handling Ethernet Controller, but simple socket programming is required

Das Ethernet hat auch den Vorteil, daß man die debug Ausgabe über eine Telnet Session ausgeben kann.

Gruß Ralf

[Ralf9]

Hallo Sidey,

mir ist aufgefallen, daß Du in den regex bei Hexziffern [A-Fa-f0-9] verwendest.
Die Nachrichten die vom dispatcher verarbeitet werden sind doch alles Hexziffern.
Die Hexziffern werden damit erzeugt

Code Auswählen Erweitern

sprintf('%X'
damit kann doch nichts anderes als Hexziffern vorkommen, oder habe ich da was übersehen?

anstatt

Code Auswählen Erweitern

"^s[A-Fa-f0-9]+"
müsste auch

Code Auswählen Erweitern

^s.+
reichen

anstatt

Code Auswählen Erweitern


"^P7#[A-Fa-f0-9]{6}F[A-Fa-f0-9]{2}"
müsste auch

Code Auswählen Erweitern

"^P7#.{6}F.{2}"
reichen

Gruß Ralf

[Sidey]

Hi Ralf,

da man ja nie weiss, wie man die Module noch verwendet, schadet es nichts an der Eingangsseite eines Modules genau zu prüfen, ob valide Daten ankommen.
Stimmen die nicht, dann stürzt FHEM im ungünstigsten Falle komplett ab und das wollen wir ja nicht.

Deshalb bei Modulen (wir haben hier aus meiner Sicht mehere Module) immer an den Eingangsschnittstellen prüfen, welche Daten valide sind.
So ist jedem der das Logische Modul z.B. nutzen möchte auch gleich klar, dass er nur Hexadezimale Werte übergeben kann.
Sollte mal was anderes ankommen, warum auch immer, wird es erst gar nicht angenommen.

Grüße Sidey

[Ralf9]

spricht aus deiner Sicht etwas dagegen, den Zweig proto7 nach rawIn zu überführen?
Soweit ich das sehe, funktioniert die Implementierung und wir könnten das zusammenführen.

GGf. notwendige Korrekturen können ja weiterhin erfolgen, sofern notwendig.

Hallo Sidey,

Ich habe in der  "14_SD_WS07.pm" bei den minsecs noch einen Fehler gefunden.
In der Zeile 167 fehlt vor

Code Auswählen Erweitern

$def->{lastMSG} = $rawData;
$def->{bitMSG} = $bitData2;

die folgende Zeile:

Code Auswählen Erweitern

$hash->{lastReceive} = time();

Gruß Ralf

[Ralf9]

Da mir das mit der whiteIdList so noch nicht so richtig gefällt, habe ich es gestern bei mir etwas umgeschrieben.
In einer sub IdList werden mit foreach alle ids durchlaufen und dann je nach Nachricht (MS,MU und MC) in 3 Hash verteilt.
Die whiteIdList wird dabei berücksichtigt.
Es ist fast fertig, ich weiß aber nicht wie ich überprüfen kann ob ein hash wie z.B. %muIdList Daten enthält.

Ich habs inzwischen selber hinbekommen. Mit if (keys %muIdList) kann ich abfragen ob der Hash Werte enthält.

Die 3 Hashlisten werden beim define und set whitelist attribut aktualisiert:
Ohne Whitelist:

Code Auswählen Erweitern

2015.10.13 21:44:00 3: IDlist MS  6, 3, 7, 2, 17, 15, 14, 20, 22, 4, 1, 0, 23, 13
2015.10.13 21:44:00 3: IDlist MU  8, 21, 9, 16, 5
2015.10.13 21:44:00 3: IDlist MC  11, 18, 10, 12

Mit Whitelist

Code Auswählen Erweitern

2015.10.13 22:38:20 3: Calling Getting Attr sub with args: set whitelist_IDs = 8,3,5,12,0,7
2015.10.13 22:38:20 3: IDlist MS  3, 7, 0
2015.10.13 22:38:20 3: IDlist MU  8, 5
2015.10.13 22:38:20 3: IDlist MC  12

ok, wenn pro Nachrichtentyp eine eigene Liste her soll, dann können wir drei Listem erstellen. Wir brauchen dann weiterhin nur einen hash.

Wenn Du bei der Aufteilung in 3 Hashlisten keine Vorteile siehst, und Du lieber nur eine Liste hast, können wir es gerne so lassen wie es jetzt ist

Gruß Ralf

[Sidey]

Ich habs inzwischen selber hinbekommen. Mit if (keys %muIdList) kann ich abfragen ob der Hash Werte enthält.

Die 3 Hashlisten werden beim define und set whitelist attribut aktualisiert:

Also es gibt jetzt 4 Hashes oder? Eienr der alles enthält und dann noch mal einzelne für MU, MS und MC?

Wenn Du bei der Aufteilung in 3 Hashlisten keine Vorteile siehst, und Du lieber nur eine Liste hast, können wir es gerne so lassen wie es jetzt ist

Ich sehe tatsächlich keinen Vorteil den Protokollhash dynamisch in drei zu zerlegen, nur um dann die IDs daraus zu extrahieren.

Viel besser fände ich es, einfach nur drei Listen anzulegen, welche die IDs enthalten. Dann weden nicht so viel Daten verdoppelt, sondern nur die Indexe in einer Liste abgelegt.

Code Auswählen Erweitern

keys %muIdList gibt ja auch nur eine Liste der IDs für die Schleife zurück. Da kann man die auch gleich erstellen.

Grüße Sidey

[Ralf9]

Hallo Sidey

Die 3 Hashlisten enthalten natürlich nur die IDs

Code Auswählen Erweitern

sub SIGNALduino_IdList()
{
my ($name, $aVal) = @_;

%msIdList = ();
%muIdList = ();
%mcIdList = ();

my %WhitelistIDs;
my $wflag = 0;
if (defined($aVal) && length($aVal)>0)
{
%WhitelistIDs = map { $_ => 1 } split(",", $aVal);
#my $w = join ', ' => map "$_" => keys %WhitelistIDs;
#Log3 $name, 3, "Attr whitelist $w";
$wflag = 1;
}
my $id;
foreach $id (keys %ProtocolListSIGNALduino)
{
next if ($id eq 'id');
if ($wflag == 1 && !defined($WhitelistIDs{$id}))
{
Log3 $name, 5, "skip ID $id";
                next;
}

if (defined($ProtocolListSIGNALduino{$id}{format}) && $ProtocolListSIGNALduino{$id}{format} eq "manchester")
{
$mcIdList{$id} = '';
}
elsif (exists $ProtocolListSIGNALduino{$id}{sync})
{
$msIdList{$id} = '';
}
else
{
$muIdList{$id} = '';
}
}

        my $ms = join ', ' => map "$_" => keys %msIdList;
        my $mu = join ', ' => map "$_" => keys %muIdList;
my $mc = join ', ' => map "$_" => keys %mcIdList;
Log3 $name, 3, "IDlist MS  $ms";
Log3 $name, 3, "IDlist MU  $mu";
        Log3 $name, 3, "IDlist MC  $mc";
}

Gruß Ralf

[Sidey]

Moin Ralf,

Die 3 Hashlisten enthalten natürlich nur die IDs

Na wozu dann einen Hash erstellen, wenn nur eine Liste notwendig ist.
Ein Hash ist doch nur notwendig, wenn paare gespeichert werden sollen
'1' -> "daten'...

eine Liste enthält dagegen nur Werte und die foreach Schleife brauch ja auch eine Liste.

Also eher sowas anlegen:

Code Auswählen Erweitern


my @msIdList = ();
my @muIdList = ();
my @mcIdList = ();

Und das ganze im hash des IO Gerätes abspeichern, sonst gelten die Daten ja für alle definierten Geräte zugleich.

Code Auswählen Erweitern


$hash{$name}{MSEnabledLst}= \@msIdList;
$hash{$name}{MSEnabledLst}= \@muIdList;
$hash{$name}{MSEnabledLst}= \@mcIdList;


In der Foreach sollte dann sowas funktionieren, da bin ich mir bezüglich Syntax nicht ganz sicher

Code Auswählen Erweitern


foreach $id (@{$hash{$name}{MSEnabledLst}})


Grüße Sidey

[hjgode]

Braucht der Ws5100 überhaupt viel RAM,

Code Auswählen Erweitern

The W5100 includes fully hardwired, market-proven TCP/IP stack and integrated Ethernet MAC & PHY. 
Hardwired TCP/IP stack supports TCP, UDP, IPv4, ICMP, ARP, IGMP and PPPoE
which has been proven in various applications for several years. 16Kbytes internal buffer is included for data transmission.
No need of consideration for handling Ethernet Controller, but simple socket programming is required

Das Ethernet hat auch den Vorteil, daß man die debug Ausgabe über eine Telnet Session ausgeben kann.

Gruß Ralf

Um den Ws5100 auf dem Arduino Uno nutzen zu können muss man aber die entsprechenden Libraries einbinden, und die verbrauchen eben Speicher.

Aktuell 'braucht' RF_Receiver:
Sketch uses 18,532 bytes (60%) of program storage space. Maximum is 30,720 bytes.
Global variables use 935 bytes (45%) of dynamic memory, leaving 1,113 bytes for local variables.

Wenn man nur den WebClient in RF_Receiver 'importiert' und initialisiert kommt man auf:
Sketch uses 30,160 bytes (98%) of program storage space. Maximum is 30,720 bytes.
Global variables use 1,282 bytes (62%) of dynamic memory, leaving 766 bytes for local variables. Maximum is 2,048 bytes.

und dann habe ich noch kein Web-Afrage erstellt geschweige denn Socket per Udp eingebunden.

Dagegen braucht der ESP8266 'nur' die SoftwareSerial Library und dann muss man halt viel Strings und Buffer verarbeiten. Das gilt aber nur, solange man die AT Commands benutzt (http://wiki.iteadstudio.com/ESP8266_Serial_WIFI_Module#AT_Commands), sobald man eine ESP8266 Libaray einsetzt wird diese auch wieder viel Speicher 'verbrauchen'. Bequemlichkeit hat halt seinen Preis.

Man könnte nun auf einen Arduino Mega umsteigen, die Dinger sind aber original eigentlich zu teuer (mehr als ein Pi), plus das Ws5100 Shield.
Statt dem Ws5100 einen ENJ einzusetzen, bringt auch nix. Kostet zwar weniger, benötigt aber auch Libraries.

~Josef

[hjgode]

Erst mal danke für die schnelle Antwort.

Fehlt da noch ne Änderung? oder geht da kein autocreate?

015-10-15 06:22:25 SIGNALduino sduino UNKNOWNCODE u7#5980C8F36
2015-10-15 06:22:25 SIGNALduino sduino UNKNOWNCODE r0
2015-10-15 06:22:25 SIGNALduino sduino UNKNOWNCODE u7#5980C8F36
2015-10-15 06:22:25 SIGNALduino sduino UNKNOWNCODE r0
2015-10-15 06:22:25 SIGNALduino sduino UNKNOWNCODE u7#5980C8F36

~Josef

der EAS800Z ist aktuell nicht drin, aber das Einbauen dürfte kein Problem sein.

Einfach  in der 00_SIGNALduino.pm

Code Auswählen Erweitern

."SD_WS07:"
in die $clientsSIGNALduino Liste anhängen und

Code Auswählen Erweitern

"9:SD_WS07" => "^P7#[A-Fa-f0-9]+",
in die matchlist kopieren

Und dann noch die "14_SD_WS07.pm" vom dev-proto7 ins FHEM Verzeichnis kopieren

Gruß Ralf

[hjgode]

Uuuups, ich seh gerade dass Sidey den dev-proto7 in dev-rawIn zurückgeführt hat.

Werde ich gleich mal gegen Eurochron testen (der Rest geht dann hoffentlich auch noch).

~Josef

EDIT: ging leider nicht mit WS07. Ich habe mir erlaubt 00_Signalduino.pm anzupassen und nach einem Test wieder nach dev-rawIn hochzuladen.

EDIT2: Soviele Änderungen habe ich doch gar nicht gemacht wie mir unter GitHub angezeigt werden. Basis war die 00_SignalDuino.pm die ich kurz vorher via "update force https://raw.githubusercontent.com/RFD-FHEM/RFFHEM/dev-rawIn/controls_signalduino.txt" geholt hatte.
Eventuell müssen wir das noch mal zurückrudern.

EDIT3: ich habe mein commit zurückgenommen und warte auf 'grünes Licht' für mein nächstes "update force https://raw.githubusercontent.com/RFD-FHEM/RFFHEM/dev-rawIn/controls_signalduino.txt".
Kann es sein dass 'update force' was anderes geholt hat als bei Git unter dev-rawIn gelegen hat?
Wie gesagt, ich habe erst ein update force gemacht und dann die 00_SignalDuino.pm angepasst weil da kein WS07 drin war. Dann habe ich die geänderte Version hochgeladen und gesehen, dass da bei Github viel mehr Änderungen drin waren als ich gemacht habe.
Egal, ich habe mein commit zurückgenommen.

Im aktuellen 00_SignalDuino.pm vermisse ich den Block für WS07 innerhalb von %ProtocolListSIGNALduino.
Deshalb lasse ich das noch nicht auf meinen FHEM server los. Auf dem Server läuft derzeit meine angepasste Version. Bei mir sieht das so aus und läuft:

Code Auswählen Erweitern

        "7"    =>                       ## weather sensors like EAS800z
        {
            name                        => 'weatherID7',       
                        id              => '7',
                        one                             => [1,-4],
                        zero                    => [1,-2],
                        sync                    => [1,-8],               
                        clockabs        => 484,                 
                        format                  => 'twostate', 
                        preamble                => 'P7#',               # prepend to converted message 
                        clientmodule    => 'SD_WS07',   
                        modulematch     => '^P7#......', # not used now
                        length_min      => '35',
                        length_max      => '40',

                },

Dazu habe ich den aktuellen "7" Block auskommentiert:

Code Auswählen Erweitern

#       "7"    =>                       ## unkown Protocol
#        {
#            name                       => 'unknown1 may TX70DHT',
...

[Kuzl]

Wozu Du da socat benötigst weiss ich jetzt nicht.
Den SIGNALDuino würde man z.B. so definieren:

Code Auswählen Erweitern

define sdnet SIGNALduino 10.2.11.200:45000

Socat könnte man benützen, wenn man den Signalduino z.b. an einen anderen Raspberry Pi hängt. Der ESP mit der Bridge müsste eigentlich kurze Zeit nach dem Reset ohne ein Kommando funktionieren und alles übertragen.
Einen ESP hab ich daheim, einen Nano nicht.
Läuft das auch auf einem Pro-Mini?

Kuzl