Signalduino Entwicklung

[Ellert]

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.

Wenn keine Unique ID vorhanden ist, können die Geräte unter Linux mit

/dev/serial/by-path/

zuverlässig eingebunden werden, man darf nur den Steckplatz nicht wechseln.

[noice]

Auch  ei diesen China Clones mit ftdi Chip ist Vorsicht angebracht ... hab hier 5 Stück mit gleicher id die sich aber auch nicht ändern lies.
Hab mir dann mal diesen zugelegt... http://pages.ebay.com/link/?nav=item.view&id=121696427044&alt=web .. ist zwar etwas teurer aber kommt schnell und die id ist änderbar




Mobil erstellt daher kurz gehalten

[noice]

Wenn keine Unique ID vorhanden ist, können die Geräte unter Linux mit

/dev/serial/by-path/

zuverlässig eingebunden werden, man darf nur den Steckplatz nicht wechseln.

Bei reboot des rasp werden allerdings auch die usb Ports neu zugewiesen ...

Mobil erstellt daher kurz gehalten

[Sidey]

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.

Ah stimmt, das hatte ich übersehen, Du hast recht. Die Mach list greift ja auch, wenn das Modul bereits geladen wurde.
Da müsste eigentlich noch eine Prüfung rein wie (If Modul not loaded) ...., dann wäre es viel besser zu kontrollieren.

Die Regex für die Match List hatte ich etwas abgeschwächter definiert, damit auch Daten die nicht an der 7. POSITION ein F haben mal an das Modul gelangen.
Bislang kennen wir ja nur drei Sensoren, bei denen das zutrifft, aber das muss ja nicht für alle gelten.

Was man bräuchte, wäre ja eine Erweiterung der Regex die auf 000000 und FFFFF prüft. Mit ^ kann man ja negieren, aber ich weiss gerade nicht, wie man ein und realisiert...

Bei was könnte ich Dir helfen? 

Bei den commandrefs,  die haben glaube ich noch Fehler.

Könnte sein, dass ich den im 00_Signalduino bereits gefunden habe.
Bei den anderen könnte noch was sein.
Ich glaube für minsecs fehlt noch die Beschreibung...
Und dann wären da halt noch die Warnings im 14_un Modul, dem man wohl auch besser die Nummer 90 verpasst.

Mehr ist es glaube ich nicht.
Bezüglich Firmware, habe ich gestern mal was bei mir probiert. Bis jetzt sieht es schon mal nicht schlechter aus als vorher.

Grüße Sidey

[Ellert]

Bei reboot des rasp werden allerdings auch die usb Ports neu zugewiesen ...

Mobil erstellt daher kurz gehalten

Der Tip kommt von hier http://forum.fhem.de/index.php/topic,40211.msg324973.html#msg324973

und wird hier diskutiert http://forum.fhem.de/index.php/topic,36062.msg289419.html#msg289419
und hier http://forum.fhem.de/index.php/topic,24651.msg325186.html#msg325186.

Ich selbst habe es nicht getestet.

[Ellert]

Der Handsender ISC HS 434/6 für einen Garagentorantrieb wird jetzt vom SignalDuino empfangen http://forum.fhem.de/index.php/topic,38831.msg339634.html#msg339634.

Weitere Einzelheiten hier http://forum.fhem.de/index.php/topic,42373.msg345546.html#msg345546

@Sidey: Vielen Dank für die super Unterstützung.

[pejonp]

...
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!

...

Hallo Sidey, Hallo Ralf

hoffentlich vergesse ich keine Antwort.

Abstürze vom Signalduino hatte ich auch schon. Mit den beiden letzten Versionen nicht mehr. Der Banana Pi war da mehr betroffen als der C1-Ondroid. An beiden hängt ein Nano V3.0 mit ID 1a86:7523 QinHeng Electronics HL-340 USB-Serial adapter (ohne S/N).

Die CTW-600 Signale wurden dann erfasst wenn der Sender der WX-2008 (868MHz) gesendet hat. Im Log habe ich dort Einträge mit Temp, Windrichtung und Uhrzeit eingetragen. Einen regex Filter habe ich nicht drin.

Mit Regex bearbeite ich nur die Ausgabe vom HTTPMOD-Modul (Solar).

Einmal wurde mir beim Hideki eine 31 als Sensortyp angezeigt, ansonsten kommt immer die 30.

So das waren erst mal meine Antworten. Vielen Dank für die gute Arbeit. Wenn ich mal etwas testen soll sagt einfach Bescheid.

Tschüß Jörg

[Ralf9]

Ah stimmt, das hatte ich übersehen, Du hast recht. Die Mach list greift ja auch, wenn das Modul bereits geladen wurde.
Da müsste eigentlich noch eine Prüfung rein wie (If Modul not loaded) ...., dann wäre es viel besser zu kontrollieren.
Die Regex für die Match List hatte ich etwas abgeschwächter definiert, damit auch Daten die nicht an der 7. POSITION ein F haben mal an das Modul gelangen.

Ich denke als Workaround für die master/stable Version reicht es, wenn Du die genaue regex vom Modul auch in die  Matchlist schreibst.

Bei den commandrefs,  die haben glaube ich noch Fehler.

Bei der commandrefs bin ich keine große Hilfe, mit der Syntax (html?)der commandref habe ich mich bis jetzt nur sehr wenig beschäftigt.

Was mir aufgefallen ist, das in den pm-Dateien noch Umlaute drin sind. Beim öffnen unter Linux mit kwrite, bekomme ich die folgende Fehlermeldung:

Code Auswählen Erweitern

.. wurde als UTF-8 kodiert geöffnet, enthält aber ungültige Zeichen
Ich habe sie bei mir schon durch ae, oe, ue ersetzt.

Und dann wären da halt noch die Warnings im 14_un Modul, dem man wohl auch besser die Nummer 90 verpasst.

Bei der Umbenennung von 14_un nach 90_un sehe ich keine Vorteile, ich dachte Du wolltest in der aktuellen Version nichts größeres mehr ändern,
nur noch Fehler beheben und die commandrefs ergänzen.

Gruß Ralf

[Sidey]

Was mir aufgefallen ist, das in den pm-Dateien noch Umlaute drin sind. Beim öffnen unter Linux mit kwrite, bekomme ich die folgende Fehlermeldung:

Code Auswählen Erweitern

.. wurde als UTF-8 kodiert geöffnet, enthält aber ungültige Zeichen
Ich habe sie bei mir schon durch ae, oe, ue ersetzt.

Stimmt, könnte man als ü etc schreiben.

Bei der Umbenennung von 14_un nach 90_un sehe ich keine Vorteile, ich dachte Du wolltest in der aktuellen Version nichts größeres mehr ändern,
nur noch Fehler beheben und die commandrefs ergänzen.

Naja, dann wird es nach allen anderen erst aufgerufen, da die Nummer vor dem Modulnamen ja die Reihenfolge bedingt.
Wenn man also ein spezifisches Modul hat, kann man es mit 14_ beginnen lassen und dispatcht dort hin.
Die Match Regex für das _un Modul könnte dann alles was mit P\d anfängt abgreifen ohne gefahr zu laufen, dass ein anderes Modul die Daten nicht mehr abbekommt.
Damit die unknown Meldung verschwindet, setzt man in dem _un Modul entgegen der Idee einen Returnwert und gut ist.

Grüße Sidey

[Ralf9]

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

Ich habe den nano mal unter Windows 7 eingesteckt, da kommt aber eine Fehlermeldung, daß ein Treiber fehlt.
Dies ist mir zu aufwendig, nur zum Testen extra einen Treiber zu installieren.

Wenn Du einen Nano kaufen willst und sicher sein willst, kannst Du eigentlich nur Originalen vertrauen.

Wenn ich einen Nano mit einem CH340 oder fake FTDI bekomme, kann ich ihn immer noch mit dem W5100 verwenden, da brauche ich den usb nur zum flashen. Die debug ausgabe mache ich da in einer telnet session.

Gruß Ralf

[Ralf9]

Naja, dann wird es nach allen anderen erst aufgerufen, da die Nummer vor dem Modulnamen ja die Reihenfolge bedingt.
Wenn man also ein spezifisches Modul hat, kann man es mit 14_ beginnen lassen und dispatcht dort hin.
Die Match Regex für das _un Modul könnte dann alles was mit P\d anfängt abgreifen ohne gefahr zu laufen, dass ein anderes Modul die Daten nicht mehr abbekommt.
Damit die unknown Meldung verschwindet, setzt man in dem _un Modul entgegen der Idee einen Returnwert und gut ist.

Das mit dem 90_un Modul funktioniert in der clientlist nur, wenn es durch ein definiertes device bereits geladen ist.
Und in der matchlist muß das 90_un Modul jedes mal extra geladen werden.
Warum muß es immer so kompliziert sein? In diesem Fall gibt es eine einfache Lösung die auch noch effizienter und ressorcenschonender ist.
Einfach so wie ich schon vorgeschlagen habe, eine genaue regex vor dem dispatch Aufruf.   

Siehe auch hier:

sollten nicht 'falsche' nachrichten so früh erkannt und ausgeschlossen werden das sie garnicht erst durch dispatch laufen? wenn du eine regex hast die das schafft schmeiss die nachrichten in der parseFn deines physikalischen moduls weg und dann ruf dispatch wie gedacht mit der übrig geblieben nachrichten auf.

Gruß Ralf

[Sidey]

Hmm, wieso das jetzt kompliziert ist verstehe ich nicht.

Ich habe die Datei jetzt umbenannt und musste die match regex angepasst.

Das _UN Modul fängt jetzt alles ab, was vorher nicht verarbeitet wurde und gibt ab verbose 4 ein paar Logmeldungen aus.

So sind die vielen Unknown Code Meldungen weg und alles was nicht nicht verarbeitet werfen konnte,  landet auch im UN Modul zu analysezwecke. Beide Anforderungen erst mal erfüllt.

Das war jetzt eine einfache Variante ohne eine neue Baustelle auf zu machen.
Gut, das umbenennen in 90 wäre nicht unbedingt notwendig gewesen, da es aktuell nicht in die clientlist gelangt.
Nachdem es dann einmal über die mach list geladen wurde ist es geladen und muss nicht mehr geladen werden.

Grüße Sidey

[hjgode]

Hallo Ralf

Code Auswählen Erweitern

Wenn ich einen Nano mit einem CH340 oder fake FTDI bekomme, kann ich ihn immer noch mit dem W5100 verwenden, da brauche ich den usb nur zum flashen. Die debug ausgabe mache ich da in einer telnet session.

Da ist es natürlich egal, solange der der Fake FT232L nicht abraucht. Hatte ich schon und konnte dann nur noch per ISP flashen. Wenn Du auch per ISP flashen kannst, ist es dann auch OK.

Man sollte halte nur eine CH340 an FHEM betreiben, sonst fällt eine feste Hardware Modul Zuordnung schwer.

~josef

[Ralf9]

Das _UN Modul fängt jetzt alles ab, was vorher nicht verarbeitet wurde und gibt ab verbose 4 ein paar Logmeldungen aus.
So sind die vielen Unknown Code Meldungen weg und alles was nicht nicht verarbeitet werfen konnte,  landet auch im UN Modul zu analysezwecke. Beide Anforderungen erst mal erfüllt.
Das war jetzt eine einfache Variante ohne eine neue Baustelle auf zu machen.

Hallo Sidey ,

ja, so sind die Unknown Code Meldungen auch weg. So ist es erstmal ausreichend.
Ich warte jetzt erst mal ab bis die aktuelle Version im master ist und es eine neue dev branch gibt.
Bei meiner Version hier habe ich einige Optimierungen und Ergänzungen vorgenommen, damit ist es auch effizienter und ressorcenschonender.
Dies kann dann evtl in die neue dev.

Gruß Ralf

[Ralf9]

da bei mir die Reichweite von Hama und Bresser Sensoren zu wünschen übrig lässt, überlege mir einen empfindlicheren Super-heterodyne Receiver zu kaufen.
http://www.ebay.de/itm/Super-heterodyne-ASK-OOK-RF-Wireless-Receiver-Module-433MHZ-112dBm-/181633631837?hash=item2a4a35465d:m:m8vDdzKEy6r6sIDvpbv9sBQ

Bei diesem Receiver ist auch ein applications Vorschlag dabei, bei dem alle Vcc und alle GND angeschlossen sind.
Ich habe bei mir nur einen VCC und einen GND angeschlossen, die restlichen habe ich offen gelassen. Kann dies einen Einfluß auf den Empfang haben?

Bei den Hama und Bresser ist bei nur einer Wand/Decke der Empfang ok. Bei 2 Wänden ist der Empfang nicht immer stabil, es kommt ab und zu vor, daß mal 1-2 Stunden von diesem nichts empfangen wird.

Gruß Ralf