Signalduino Entwicklung

[RappaSan]

Guten Morgen Sidey (und natürlich auch alle anderen).

Stimmt, da bin ich ja noch eine Antwort schuldig...

Zur Zeit klappt alles so, wie es soll - Funksteckdosen und Oregon THGR228N.
Fein!
Der Oregon-Sensor hat sich mit anderer ID zurückgemeldet, nachdem ich gestern Abend die Batterien für 1 Minute entfernt und wieder eingelegt hatte. ID in der config geändert - fertig.
Signalduino hat im Gegensatz zu FHEMduino auch keine Probleme mit dem Empfang der Daten. Da gibt's keine Lücken mehr (wenn der Sensor nicht rumspinnt).

Wenn ich nun noch sehe, was es alles an Sensoren um mich herum noch gibt... wow...
Und das Gute ist: So wie ihr hier an die Sache rangeht dauert es nicht mehr lange, dann werden die Signale auch richtig ausgewertet.

Großes Lob an alle Entwickler hier - tolle Arbeit, tolles Teamwork.

[Hauswart]

Mit in der FHEM Version 5.7 wäre natürlich cool 

[Sidey]

Hi Rappasan,

Vielen Dank für das Lob.
Es gibt eine Menge an Signalen, ja.
Ich war auch überrascht, was da alles rumfunkt.
Dachte erst das wäre rauschen, aber,dafür sind die Signale zu gleichmäßig.

Bezüglich deines Oregon Sensors.
Du kannst den Sensor auch nur über die Kanalnummer anlegen lassen. Dazu ist das Attribut longid im signalduino auf 0 zu setzen. Du kannst auch für einzelne Sensoren definieren, dazu dann aber mehr in der Commandref.

Der Nachteil ist dann nur, dass Du Sensoren mit dem gleichen Kanal nicht unterscheiden kannst.

Grüße Sidey

[Ralf9]

Im Log kommen noch Warnungen.
2015.10.15 22:35:34 1: PERL WARNING: substr outside of string at ./FHEM/14_SD_WS07.pm line 100.

Ich empfange auch 2 WS07 Sensoren. Ich habe keine, wahrscheinlich aus der Nachbarschaft. Da kann aber etwas nicht stimmen.

Hallo pejonp,

Ich habe mir den log angeschaut, da sind für die WS07 Sensoren keine gültige Nachrichten dabei.
Die Warnungen hängen mit den fehlerhaften Nachrichten der WS07 Sensoren zusammen.
Da sind noch ein paar optimierungen notwendig. Es werden z.T. noch mehr Nachrichten als nötig zu den Modulen geschickt.

Ich habe bei mir ein paar Optimierungen und Ergänzungen vorgenommen. Damit wird die Nachrichtenverarbeitung effizienter und das log wird deutlich reduziert.
Ich werde es dann in den neuen dev branch einchecken.

Gruß Ralf

[Ralf9]

Bezüglich deiner Frage zur Optimierung:
Hauptsächlich möchte ich erst mal den RAM optimieren. Der fragmentiert leider mit der Zeit und dann stürzt der Arduino ab.

ich hatte auch schon ein paar Abstürze. Gibt es nach einem Absturz eine andere Möglichkeit als den Arduino kurz stromlos zumachen.
Der Arduino hängt an einem Banana Pi.

Gruß Ralf

[Sidey]

Hiho,


Bei den WS07 hätte ich jetzt gedacht, dass ein Gerät die gleiche Codierung verwendet.
Ohne zu wissen, was da übertragen wird,  wird es schwer das zu interpretieren.

Zu den abstürzen, eigentlich sollte es so ablaufen:
Der Arduino stürzt ab, nach spätestens  5 Minuten merkt Fhem, dass der Arduino nicht mehr reagiert.
Danach wird der USB port neu initialisiert.
Dabei müsste mittels Der ein Reset ausgelöst werden.

Wenn das mit dem DTR nicht klappt ist blöde.
Was passiert, wenn Du den set reset Befehl aufrufst?

Sidey

[Ralf9]

Wenn das mit dem DTR nicht klappt ist blöde.
Was passiert, wenn Du den set reset Befehl aufrufst?

Der Reset Befehl hat keine Auswirkung, er hat keine Befehle mehr angenommen.
Ein reboot vom Banana pi hat auch nichts gebracht.

Gruß Ralf

[hjgode]

Der Reset Befehl hat keine Auswirkung, er hat keine Befehle mehr angenommen.
Ein reboot vom Banana pi hat auch nichts gebracht.

Gruß Ralf

Vielleicht hilft Dir usbreset (vorher mit listusb.sh das Gerät ermitteln, welches zurückgesetzt werden soll.
Hab ich bei stackoverflow gefunden. usbreset must Du noch kompilieren.

~Josef

[Ralf9]

Vielleicht hilft Dir usbreset (vorher mit listusb.sh das Gerät ermitteln, welches zurückgesetzt werden soll.
Hab ich bei stackoverflow gefunden. usbreset must Du noch kompilieren.

Hallo Josef,

Danke für den Tip mit dem usbreset, werde ich mal testen, wenn der Arduino mal wieder abstürzt.
Mit listusb,sh bekomme ich nichts brauchbares.
Mit lsusb bekomme ich:

Code Auswählen Erweitern

Bus 003 Device 003: ID 0403:6001 Future Technology Devices International, Ltd FT232 USB-Serial (UART) IC


Der usbreset Befehl müsste dann so heißen:

Code Auswählen Erweitern

sudo ./usbreset /dev/bus/usb/003/003 

Gruß Ralf

[Sidey]

Hallo zusammen,

ich weiss gar nicht, wie ich auf alle Fragen und Beiträge jetzt richtig antworten soll...


Naja, ich fang einfach mal an und hoffe ich vergesse nichts.

Zum Anhang von pejonp

Bezüglich ID7 Protokoll. Da wundere ich mich jetzt gerade sehr.
Zunächst ist es so, dass hier nur 0 bits erkannt wurden. So eine Nachricht ist wohl offensichtlich müll, wenn die nur aus 0 oder 1 besteht, so etwas sollte ich wohl abfangen.
Der Fehler liegt aber wo anders, das ist ein weather1 Protokoll.

2015.10.15 22:46:30 4: SIGNALduino/msg READ: MS;P0=603;P1=-1839;P2=-3795;P3=-9114;D=03010201020201010201010101020102010101010102010102020101020101010201010202;CP=0;SP=3;O;
2015.10.15 22:46:30 4: Found matched Protocol id 7 -> weatherID7
2015.10.15 22:46:30 5: Starting demodulation at Position 6
2015.10.15 22:46:30 5: converted Data to (P7#000000)
2015.10.15 22:46:30 5: sduino dispatch P7#000000
2015.10.15 22:46:30 4: SD_WS07_Parse  SD_WS07 (P7#000000) length: 6
2015.10.15 22:46:30 3: SD_WS07 converted to bits: 00000000 0 000 000000000000 
2015.10.15 22:46:30 3: SD_WS07_T decoded protocolid: 7 sensor id=00, channel=1, temp=0, hum=0, bat=low
2015.10.15 22:46:30 4: Found matched Protocol id 0 -> weather1
2015.10.15 22:46:30 5: Starting demodulation at Position 2
2015.10.15 22:46:30 5: converted Data to (s590A09913000)
2015.10.15 22:46:30 5: sduino dispatch s590A09913000

Ich sag jetzt mal. Grundproblem erkannt. Eine Lösung muss ich mir noch ausdenken.
Allerdings deckt dieser Fehler noch Folgeprobleme auf. Die ich nicht verstehe.
Es wird "P7#000000" an dispatch übergeben und dispatch übergibt die Nachticht an das SD_WS07 Modul.
Nur das Modul hat folgende Match regex, die obige Nachticht hätte filtern müssen:

Code Auswählen Erweitern

$hash->{Match}     = "^P7#[A-Fa-f0-9]{6}F[A-Fa-f0-9]{2}";

Ich habe dazu mal zwei bugs notiert:
https://github.com/RFD-FHEM/RFFHEM/issues/37
https://github.com/RFD-FHEM/RFFHEM/issues/36

Auch ein ganz komischer Fall bezüglich CTW-600

Code Auswählen Erweitern


2015.10.15 23:07:09 5: sduino dispatch u9#FFA581D8610205036A0360
2015.10.15 23:07:09 3: sduino: Unknown code u9#FFA581D8610205036A0360, help me!


Das hätte an das SIGNALduino_un Modul gehen müssen... Hast Du das Log mit einer regex gefiltert oder ähnliches gemacht?
Was die Daten von WX-2008 angeht, da weiss ich nicht, wo das um 2. Log enthalten ist. Oder sind das die Daten die als CTW600 erkannt werden?

----------------------------------------------------
@Hauswart:
Ja für FHEM 5.7 ist geplant, dass er enthalten ist. Ich hoffe ich schaffe es bis da hin noch ein paar Fehlerchen zu beseitigen.

----------------------------------------------------
@Ralf9:

Dass es mit dem Abstürzen solche Folgen hat, war mir bislang nicht bewusst. Ich habe keinen bananapi, aber wenn er sich nicht von selbst wieder erholt ist der signalduino ja quasi unbrauchbar für ernsthafte dinge.
Da müsste ich wohl doch schleunigst an die Firmware ran. Nur beides schaffe ich zeitlich vermutlich nicht.
Könntest Du bei den FHEM Modulen vielleicht was übernehmen?

Grüße Sidey

[Ralf9]

Es wird "P7#000000" an dispatch übergeben und dispatch übergibt die Nachticht an das SD_WS07 Modul.
Nur das Modul hat folgende Match regex, die obige Nachticht hätte filtern müssen:

Code Auswählen Erweitern

$hash->{Match}     = "^P7#[A-Fa-f0-9]{6}F[A-Fa-f0-9]{2}";

Das dürfte daran liegen, daß in der %matchListSIGNALduino nur

Code Auswählen Erweitern

"10:SD_WS07" => "^P7#[A-Fa-f0-9]+",
steht. Wenn die Match regex im Modul nicht passt, dann wird in der matchListSIGNALduino weiter gesucht.
Als Workaround kannst Du in die %matchListSIGNALduino die selbe genaue regex reinschreiben wie im Modul.

Ich habe es bei mir mit einer regex Abfrage vor dem dispatch Aufruf gelöst:

Code Auswählen Erweitern

my $modulematch;
if (defined($ProtocolListSIGNALduino{$id}{modulematch})) {
                                $modulematch = $ProtocolListSIGNALduino{$id}{modulematch};
}
                                if (!defined($modulematch) || $dmsg =~ m/$modulematch/) {
SIGNALduno_Dispatch($hash,$rmsg,$dmsg);
$message_dispatched=1;
}
Damit kann dann bei den IDs bei denen vor dem dispatch genauer geprüft werden soll, in der ProtocolListSIGNALduino bei modulematch eine genaue regex eingetragen werden.
Bei den restlichen IDs wo eine einfache prüfung auf die preample reicht, wird modulematch auskommentiert.

Ohne die regex Prüfung vor dem dispatch werden fehlerhafte Nachrichten erst in der clientlist und dann noch in der matchlist überprüft. Dann wird eine unknown code Meldung ausgegeben.

Auch ein ganz komischer Fall bezüglich CTW-600

Code Auswählen Erweitern


2015.10.15 23:07:09 5: sduino dispatch u9#FFA581D8610205036A0360
2015.10.15 23:07:09 3: sduino: Unknown code u9#FFA581D8610205036A0360, help me!


Die Unknown code Meldung wird auch erzeugt, wenn in einem Modul ein "return undef" steht.

@Ralf9:
Dass es mit dem Abstürzen solche Folgen hat, war mir bislang nicht bewusst. Ich habe keinen bananapi, aber wenn er sich nicht von selbst wieder erholt ist der signalduino ja quasi unbrauchbar für ernsthafte dinge.
Da müsste ich wohl doch schleunigst an die Firmware ran. Nur beides schaffe ich zeitlich vermutlich nicht.
Könntest Du bei den FHEM Modulen vielleicht was übernehmen?

Solange ich der einzigste mit solchen Abstürzen, die sich nicht von selbst erholen, bin und sie nur einmal in der Woche auftauchen, kann ich im Moment noch damit leben.

Bei was könnte ich Dir helfen? 

Gruß Ralf

[hjgode]

Hallo Josef,

Danke für den Tip mit dem usbreset, werde ich mal testen, wenn der Arduino mal wieder abstürzt.
Mit listusb,sh bekomme ich nichts brauchbares.
Mit lsusb bekomme ich:

Code Auswählen Erweitern

Bus 003 Device 003: ID 0403:6001 Future Technology Devices International, Ltd FT232 USB-Serial (UART) IC


Der usbreset Befehl müsste dann so heißen:

Code Auswählen Erweitern

sudo ./usbreset /dev/bus/usb/003/003 

Gruß Ralf

So ähnlich war es auch bei mir:

Code Auswählen Erweitern

sudo ./usbreset /dev/bus/usb/004/002

[hjgode]

Hallo Ralf und Sidey

Solange ich der einzigste mit solchen Abstürzen, die sich nicht von selbst erholen, bin und sie nur einmal in der Woche auftauchen, kann ich im Moment noch damit leben.

Ich hatte ähnliche Probleme mit zwei China Clone Nanos. Leider musste ich feststellen, dass dort diese Fake FTDI Chips verbaut waren (brachten unter Windows nur seriell: Not a genuine Device...). Der eine hat  nach einer Zeit die Kommunikation via USB ganz aufegegeben. Den kann ich nur noch über ISP flashen. Der andere hing sich sporadisch weg, die LEDs blinkten wie verrückt, keine vernünftige Kommunikation mehr. Im FHEM erscheint dann periodisch SigalDuino disappear/reappear oder eben dass gar keine Kommunikation mehr möglich war.

Nachdem dann der zweite von drei China Nanos defekt war, habe ich jetzt einen Clone mit CH340 dran. Einer ist OK, mehrere könnten man anhand von serial-by-id nicht auseinanderhalten.

Ein dritter, früher von derselben China Schmiede gekaufter Nano läuft stabil als nanoCUL433. Da ist wohl ein Original FTDI drauf.

Da ich mit dem Pollin AVR-Net-IO früher auch Probleme mit unerklärlichen Hängern habe ich dessen Code um eine Watchdog erweitert. Wahrscheinlich stimmt in der Ethernet-Lib für den ENJ Chip was nicht, eine Watchdog war für mich der einfache Weg. Nur ein
#include <avr/wdt.h>
...
wdt_enable(WDTO_2S);
...
und dann im code regelmäßig vor den zwei Sekunden
wdt_reset();
aufrufen.

Seit dem habe ich Ruhe bei dem AVR-NetIO code. Ist natürlich nicht die korrekte Vorgehensweise, wenn Code nicht funktioniert, aber die grossen Ethernet Libs kann ich schlecht entwanzen.

Siehe auch: https://tushev.org/articles/arduino/5/arduino-and-watchdog-timer

Gruss

Josef

[Ralf9]

Ich hatte ähnliche Probleme mit zwei China Clone Nanos. Leider musste ich feststellen, dass dort diese Fake FTDI Chips verbaut waren (brachten unter Windows nur seriell: Not a genuine Device...)

Hallo Josef,

kann ich auch unter Linux erkennen ob ein fake oder ein orginal  FTDI Chip drauf ist? Oder kann man das an der Beschriftung des FTDI Chip erkennen?
hier ist der, der ab und zu abstürzt:

Code Auswählen Erweitern

Bus 003 Device 003: ID 0403:6001 Future Technology Devices International, Ltd FT232 USB-Serial (UART) IC
usb-FTDI_FT232R_USB_UART_A9GFBXLP-if00-port0 -> ../../ttyUSB0


ich habe auch noch einen zweiten:

Code Auswählen Erweitern

Bus 003 Device 004: ID 0403:6001 Future Technology Devices International, Ltd FT232 USB-Serial (UART) IC
usb-FTDI_FT232R_USB_UART_A600G900-if00-port0 -> ../../ttyUSB0



Ich möchte mir bei ebay noch 1-2 nano mit FTDI Chip kaufen, kannst Du mir einen empfehlen?
Zusätzlich möchte ich mir noch dazu ein W5100 kaufen. Kann ich bei diesem auch die Arduino Ethernet liberarys verwenden?
http://www.ebay.de/itm/Mini-W5100-Ethernet-Shield-Network-Expansion-Board-For-Arduino-/201394383381?hash=item2ee40a6a15:g:KaoAAOSw3ydVsv2c

Gruß Ralf

[hjgode]

Hallo Ralf

Die FTDI chips kann man einfachsten unter Windows erkennen, dort geben sie per serial immer nur "Not a genuine device..." aus.

Es gab auch mal einen FTDI Windows Treiber der die Dinger einfach mal platt gemacht hat.

Der Aufdruck unterscheidet sich auch mehr oder weniger: http://hackaday.com/2014/02/19/ft232rl-real-or-fake/

Mit dem Mini W5100 habe ich keine Erfahrungen. Ich habe 'nur' ein 'original' W5100 Shield (China Clone der funktioniert, da kann man ja eigentlich nix falsch machen). Beim ENC28J60 bin ich vorsichtig, da gibt es wohl keine stabilen Arduino Libraries.

Wenn Du einen Nano kaufen willst und sicher sein willst, kannst Du eigentlich nur Originalen vertrauen. Ich habe letztens zwei Nano Clones gekauft bei denen die Abbildung den FTDI Chip zeigten. Geliefert wurde aber mit CH340. Da wird dann nur einen zuverlässig einem Port zugeordnet. Die Dinger haben keine Unique ID wie die FTDT232RL. Wenn man einen zweiten anschliesst hängt es von der Erkennung beim Booten ab, welchen serial Port sie bekommen.

gruss

~Josef