Problem m. Signalduino; FHEM Oberfläche "hängt"/wird blockiert->ziemlich Gelöst!

[DerStephan]

Hallo Ralf!

Wenn ich der einzige bin mit dem Problem, muss es ja an meinen Gerätschaften liegen! Da muss ich dann mal Teil für Teil durchgehen. 3A Netztteil für den Raspi ist schon bestellt, dann ist der Arduino dran. Die Atmels werden glaub ich nicht gefälscht, bleiben noch FT232 und der Quarz für den Atmel als potentielle Fehlerquellen. Gibts irgendwo eine Quelle für gute Nano's?

Dort hatte ich die Initialisierungsphase als log angehängt (noch mit einer älteren Signalduino-Version)

Code Auswählen Erweitern



2016.06.03 21:02:40 1: Including fhem.cfg
2016.06.03 21:02:40 3: telnetPort: port 7072 opened
2016.06.03 21:02:41 3: WEB: port 8083 opened
2016.06.03 21:02:41 3: WEBphone: port 8084 opened
2016.06.03 21:02:41 3: WEBtablet: port 8085 opened
2016.06.03 21:02:41 2: eventTypes: loaded 100 events from ./log/eventTypes.txt
2016.06.03 21:02:41 3: sduino3: IDlist MS 0 1 13 14 15 17 2 22 23 25 3 32 33 35 38 4 6 7
2016.06.03 21:02:41 3: sduino3: IDlist MU 16 20 21 24 26 27 28 29 30 31 34 36 37 39 5 8 9
2016.06.03 21:02:41 3: sduino3: IDlist MC 10 11 12 18
2016.06.03 21:02:41 3: Opening sduino3 device /dev/serial/by-id/usb-FTDI_FT232R_USB_UART_A9YDP7FJ-if00-port0
2016.06.03 21:02:41 3: Setting sduino3 serial parameters to 57600,8,N,1
2016.06.03 21:02:41 3: sduino3 device opened
2016.06.03 21:02:41 1: define: /dev/serial/by-id/usb-FTDI_FT232R_USB_UART_A9YDP7FJ-if00-port0@57600
2016.06.03 21:02:41 1: init: /dev/serial/by-id/usb-FTDI_FT232R_USB_UART_A9YDP7FJ-if00-port0@57600
2016.06.03 21:02:45 1: PERL WARNING: Use of uninitialized value in string ne at ./FHEM/00_SIGNALduino.pm line 1720, <$fh> line 68.
2016.06.03 21:03:09 2: CUL_TCM97001 Unknown device CUL_TCM97001_37, please define it
2016.06.03 21:03:38 2: CUL_TCM97001 Unknown device CUL_TCM97001_37, please define it
2016.06.03 21:03:38 2: autocreate: define AURIOL_37 CUL_TCM97001 CUL_TCM97001_37
2016.06.03 21:03:38 2: autocreate: define FileLog_AURIOL_37 FileLog ./log/AURIOL_37-%Y.log AURIOL_37
2016.06.03 21:03:38 2: autocreate: define SVG_AURIOL_37 SVG FileLog_AURIOL_37:temp4hum4:CURRENT
2016.06.03 21:03:45 3: sduino3: Possible commands: ViRtXFSPCG
2016.06.03 21:03:45 1: PERL WARNING: Use of uninitialized value in numeric eq (==) at ./FHEM/00_SIGNALduino.pm line 856.
2016.06.03 21:03:45 3: sduino3: Firmwareversion: V 3.2.0-b12 SIGNALduino - compiled at Feb 13 2016 21:34:09

2016.06.03 21:03:45 1: Including ./log/fhem.save
2016.06.03 21:03:45 1: configfile: AURIOL_37 already defined, delete it first
FileLog_AURIOL_37 already defined, delete it first
SVG_AURIOL_37 already defined, delete it first

2016.06.03 21:03:45 2: Messages collected while initializing FHEM: configfile: AURIOL_37 already defined, delete it first FileLog_AURIOL_37 already defined, delete it first SVG_AURIOL_37 already defined, delete it first
2016.06.03 21:03:45 0: Featurelevel: 5.7
2016.06.03 21:03:45 0: Server started with 13 defined entities (fhem.pl:11545/2016-05-29 perl:5.020002 os:linux user:fhem pid:514)




Ich bleibe dran und melde mich, wenn ich die Komponenten ausgetauscht habe.

Stephan

[Ralf9]

Dort hatte ich die Initialisierungsphase als log angehängt (noch mit einer älteren Signalduino-Version)

In dem log fehlen die MU-Nachrichten. Ein log mit verbose 4 wäre aussagekräftiger.

Gruß Ralf

[Sidey]

Hallöchen,

habe den Thread zufällig entdeckt.

Also das der Signalduino oft meldet, dass er initalized ist, das ist normal.
Das wird jedesmal gesetzt (um ein Event zu generieren), wenn eine Nachricht empfangen wurde. Liest sich im Log leider etwas missverständlich.

Zum Thema Initalisieren nach dem Starten.

Also, wenn der SIGNALduino dauerhaft was empfängt und das empfangene dauernd an FHEM übergibt, dann ist es denkbar, dass das Initialisieren nicht funktioniert.
Wir könnte dazu tatsächlich, das Auswerten von Signalen komplett deaktivieren und nach der Initialisierung wieder aktivieren.
Das würde dein Problem bestimmt lösen. Geht bei der Initialisierung etwas schief, läuft die Signalauswertung halt bis zum Nächsten Reset vom Arduino nicht.
Ich denke, das ist vertretbar.

Grüße Sidey

[DerStephan]

Hallo Sidney,

ja, ich glaube, genau das passiert hier. Zu viele Geräte auf 433 MHz 

Wenn Du sowas einbauen könntest, wäre das ne klasse Sache! Ich schätze mal, früher oder später könnten auch andere mit dem Problem konfrontiert werden?!

Viele Grüße,

Stephan

[Sidey]

Hi,

Hatte ich direkt mit meinem Post auch eingebaut.

Einfach mal ein Update der devr32 Version machen und mir berichten.

Grüße Sidey

[DerStephan]

Super Sache! Thx

Ich habe leider beim Updaten noch ein Problem:  ich bekomme nach dem Update: update all https://raw.githubusercontent.com/RFD-FHEM/RFFHEM/dev-r32/controls_signalduino.txt

immer die Version "V 3.2.0-b24 SIGNALduino - compiled at May 14 2016 00:06:40"

Irgendwas mache ich noch falsch. Hat jemand einen Tipp für mich?

Viele Grüße,

Stephan

[Sidey]

Wenn Du die neue Firmware flashen willst, dann musst Du den set flash Befehl anwenden.

Um das beschriebene Problem zu lösen ist ein Flashen allerdings nicht erforderlich. Schadet aber auch nicht.


Grüße Sidey

[DerStephan]

Hallo Sidney,

ja, dass ein flash hinterher kommen muss, war mir schon klar(und habe ich auch gemacht), ich dachte halt, dass es eine neue Firmware gäbe. 

Ich habs jetzt mal grob getestet, leider immer noch das selbe Problem: es geht erst, wenn ich die MU's deaktiviere. Ich werde morgen weiter schauen, ob ich Unterschiede finde im Verhalten.

Viele Grüße,

Stephan

[Sidey]

Seltsam... hmm

[DerStephan]

Hi Sidney!

Meine Vermutung ist, dass der Signalduino nach seiner Initialisierung sofort mit dem "abfeuern" seiner Nachrichten beginnt und zwar so schnell, dass FHEM es (zumindest auf dem Raspberry) nicht schafft, ihn in der Konfiguration zu integrieren, bevor der Nachrichtenstrom einsetzt.

Ich habe hier auch ein paar nanoCul's im Einsatz mit Arduinos aus der selben Serie wie dem Signalduino-Nano. Dort tritt das Problem nicht auf. Ich habe mal versucht, herauszufinden, wo der Unterschied liegen könnte. Dabei ist mir aufgefallen, dass der NanoCul nach dem Anschluss an den die USB Schnittstelle von sich aus anscheinend keine Daten an die serielle Schnittstelle schickt. Jedenfalls zeigt der Serielle Monitor nichts an.

<Spekulationsmodus an> Kann es sein, dass der NanoCUL erst auf einen Befehl vom Host (FHEM) wartet, um die Datenaussendung zu beginnen? Das könnte erklären, warum dort das Problem nicht auftaucht: Nach dem Einstecken initialiert sich die Schnittstelle auf dem Nanocul und wartet dann quasi auf FHEM, bis es mit der Einbindung fertig ist und schickt erst dann Datensignale, wenn FHEM es dazu aufgefordert hat. <Spekulationsmodus aus>

Mein Gedanke ist deshalb, die Firmware so zu modifizieren, dass der Signalduino erst einige Sekunde nach seiner "Erstinitialisierung" nach dem Einstecken  mit der Ausgabe von Nachrichten über die serielle Schnittstelle beginnt (wenn FHEM komplett durch ist mit seiner Initialisierung des Signalduino). Wäre sowas machbar (und sinnvoll)?

Viele Grüße,

Stephan

[DerStephan]

By the way: Gerade ist mir im Log aufgefallen:  Kann der Signalduino jetzt auch Revolt?

Code Auswählen Erweitern


2016.06.11 16:23:31.028 4: sduino: Matched MS Protocol id 45 -> revolt
2016.06.11 16:23:31.028 4: sduino: Decoded MS Protocol id 45 dmsg i491C88 length 24



Dann kann ich den NanoCul ja in Rente schicken, wenn der Signalduino dieses Format auch beherrscht (plus die vielen anderen) 

[Sidey]

Das mit dem Delay könnte man so machen. Da muss ich mal nachdenken, wie man das mit relativ wenig Rechenpower realisieren könnte, dass nicht jedesmal geprüft wird, ob der uC gerade gestartet wurde.


Kannst Du mal mit Verbose 5 einen Startvorgang mitloggen. Eigentlich hätte ich erwartet, dass das Abschalten des Interrupts die Lösung schlechthin ist.
Zu Revolt: Naja ich habe etwas implementiert, das vielleicht das Revolt Protokoll ist. Scheinbar liege ich da ja nicht so falsch.
Wenns klappt, dann wird ein IT Device angelegt. Unter Umständen brauchst Du aber die angpasste IT Version von Ralf9.

Grüße Sidey