Firmata Update für Firmware-Versionen ab 2.7

[hugo.crank]

Moin,
sorry hatte das absolut nicht durchdrungen. da ja eh ein Wiz6100 drauf steckt geh ich einfach auf den resetpin und nutze die funktion. das sollte ja eigentlich reichen. ich teste das mal.

[slawekking]

Hallo,

ich wollte zwei Arduinos (NANO und Uno) an einem Raspi 3 laufen lassen um den PH Wert und das Redox Potential zu messen. Muss getrennt sein das ganze, auf einem leider nicht möglich.

Leider bekomme ich das Fehlverhalten, dass beide Controller nicht gleichzeitig lauffähig sind. Nach einem Neustart oder Reset aus Fhem springt einer der Controller in Fhem immer zwischen connected und initialized. Anschließend bleibt es bei initialized wobei nur 2 Analog Ports Angezeigt werden die nicht passen. Bei jedem DEF vom Port wird error initializing: pin beim state angezeigt.

Ich habe die : DRIVER_VERSION 0.64, firmware_version V_2_05.

Im Anhang sind Logs die vielleicht weiterhelfen können .

Einer von euch eine Idee?

Gruss

Christoph
                     

[JensS]

Hallo Christoph,

hast du schon mal probiert, die Arduinos per ID einzubinden?
https://wiki.fhem.de/wiki/Trick_der_Woche#CUL_.26_CO_.C3.BCber_Serial_ID-einbinden

Gruß Jens

[slawekking]

Hallo Jens,

danke für den Hinweis. Habe es gerade ausprobiert.

Leider hat es nicht geholfen. Immer noch das gleiche Fehlerbild.

Gruss

Christoph

[JensS]

Hängen beide Arduinos direkt am Pi oder per USB-Hub?https://www.raspberrypi.org/documentation/hardware/raspberrypi/usb/README.md

[slawekking]

Die beiden Adruinos hängen direkt am Raspberry Pi 3. Es sind die einzigen Verbraucher die am Raspberry hängen. Beide haben auch unterschiedliche IDs.

[Joe9]

Wenn sich ein Eingangspin ändert, wird mittels FIRMATA ein Telegramm mit allen Pinzuständen gesendet und alle FHEM-FRM_IN-Geräte werden aktualisiert.

Leider ändert sich dann auch der Readings-Zeitstempel der Pins, die sich nicht geändert haben.

Eine Aktualisierung des Zeitstempes nur bei den geänderten Pins wäre recht hilfreich bei Szenarien wie: der Zustand von mehreren Türen und Fenstern wird übertragen und man will den Zeitpunkt des betroffenen Gerätes feststellen.

Ist so eine Änderung prinzipiell möglich, oder sprechen von mir nicht bedachte Effekte dagegen?
Wir Aufwändig wäre so eine Änderung (nach meiner Vermutung sollte es nur das Modul FRM_IN betreffen)?

Eine Alternative zu dem obigen Vorschlag wäre die Nutzung des neuen Attributes timestamp-on-change-reading in Verbindung mit dem Attribut event-on-change-reading.
Leider funktioniert diese Variante aus ungeklärten Gründen nicht.

[jensb]

@slawekking
Dein Beitrag liegt zwar schon etwas zurück, aber vielleicht hilft es weiter: In deinem Log sind immer wieder USB Reconnects zu sehen. Selbst wenn die Arduinos die einzigen Komponenten am RPi sind könnte es ein Spannungsversorgungsproblem sein. Was passiert, wenn du einen USB-Hub mit Spannungsversorgung dazwischen schaltest?

Grüße,
Jens

[Joe9]

FRM_IN mit korrekten Zeitstempeln pro PIN bei keiner Änderung

Also ich konnte das obige Problem jetzt selbst lösen.
Für Interessierte:
Im Modul 20_FRM_IN.pm muss in Zeile 158 lediglich der Funktionsaufruf  main::readingsBulkUpdate in  main::readingsBulkUpdateIfChanged  geändert werden.

Vielleicht hat der Modulverantwortliche Zeit und Muße, das Verhalten zu prüfen und ggf. zu übernehmen.

Viele Grüße

[jensb]

@Joe9

Wenn sich ein Eingangspin ändert, wird mittels FIRMATA ein Telegramm mit allen Pinzuständen gesendet und alle FHEM-FRM_IN-Geräte werden aktualisiert.
Leider ändert sich dann auch der Readings-Zeitstempel der Pins, die sich nicht geändert haben.

Firmata ist relativ sparsam und sendet den Zusand von Digitaleingängen nur bei Änderungen, allerdings Portweise, also immer für 8 Eingänge. Daraus resultiert das von dir beobachtete Verhalten.

Eine Aktualisierung des Zeitstempes nur bei den geänderten Pins wäre recht hilfreich bei Szenarien wie: der Zustand von mehreren Türen und Fenstern wird übertragen und man will den Zeitpunkt des betroffenen Gerätes feststellen.
Ist so eine Änderung prinzipiell möglich, oder sprechen von mir nicht bedachte Effekte dagegen?

Die Anforderung nur bei tatsächlicher Änderung ein Ereignis zu generieren bzw. den Zeitstempel zu aktualisieren wird immer wieder benötigt. Die von dir gewünschte Funktion ist aber bereits weitgehend implementiert (siehe 20_FRM_IN.pm Zeile 135ff: "my $changed = ..."). Sie unterdrückt aktuell bereits die Event-Generierung.

Im Modul 20_FRM_IN.pm muss in Zeile 158 lediglich der Funktionsaufruf  main::readingsBulkUpdate in  main::readingsBulkUpdateIfChanged  geändert werden.

Das ist auch ein Lösungsansatz. Effektiver wäre es aber die Zeile 158 um 1 Zeile nach oben zu verschieben, denn dann muss FHEM nicht noch einmal herausfinden, was das Modul schon weiß. Ich werde mir das aber noch genauer ansehen.

Eine Alternative zu dem obigen Vorschlag wäre die Nutzung des neuen Attributes timestamp-on-change-reading in Verbindung mit dem Attribut event-on-change-reading.
Leider funktioniert diese Variante aus ungeklärten Gründen nicht.

Die readingFnAttributes sind im FHEM-Kern verankert und sollten daher unabhängig vom Modul funktionieren.

Grüße,
Jens

[matthias soll]

Hallo zusammen, ich hoffe hier kann mir jemand weiterhelfen.
Ich habe aktuell ca. alle 2 tage einen totalabsturz von meinem fhem (über ssh nichtmehr zu erreichen).
Mein atmega firmata server lief ca. 4 jahre perfekt mit ConfigurableFirmatafor5100rev1.ino V_2_06 (using Protocol Version: V_2_06)
jetzt habe ich plötzlich fehlermeldungen im log:

2018.10.31 02:48:46 1: OWXCOUNT_BinValues getpage: OWC1: invalid CRC, 117 248 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0xfc 0x90 0x3c 0x01 0x00 0x00 0x00 0x00 0x75 0xf8
2018.10.31 04:58:46 1: OWXCOUNT_BinValues getpage: OWC: invalid CRC, 226 164 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0
2018.10.31 14:38:36 1: OWTHERM: Dachboden has returned invalid data of length 10
2018.10.31 14:38:36 1: OWXTHERM_BinValues:  Dachboden: invalid data length, 0 instead of 9 bytes,  0 
2018.10.31 14:38:40 1: OWTHERM: Heizungsspeicher has returned invalid data of length 10
2018.10.31 14:38:40 1: OWXTHERM_BinValues:  Heizungsspeicher: invalid data length, 0 instead of 9 byte

Kann mir jemand einn tip geben wo ich suchen kann?

[jensb]

@matthias soll
Für mich sieht das auf den 1. Blick nicht wie ein Firmata-Problem aus. Dein Logging zeigt die Nutzung von OneWire-Devices. Bei OneWire hat sich bezogen auf 4 Jahre einiges geändert. Schau dich bitte mal im Bereich 1Wire um. Wenn das nicht hilft könntest du in diesem Bereich eine Anfrage starten. Zum Weiterhelfen solltest du auch angeben, ob du die neuste FHEM-Version verwendest bzw. wann du zuletzt ein Update gemacht hast und ob der Fehler z.B. unmittelbar nach dem Update aufgetreten ist. In Frage kommt aber auch ein Hardware-Problem (z.B. Verkabelung), denn scheibar kommen ja noch Daten, nur sind die nicht stimmig (CRC-Fehler).

Grüße,
Jens

[matthias soll]

Danke für deine Tipps,
du hast recht das Problem ist am 24.10. das erste mal aufgetreten.
Die Software Module sind aber alle viel älter.
Ich denke ich werde erstmal den Bus verkürzen bzw. erstmal die Zähler abklemmen.
Und dann sehe ich mich im onewire Bereich um.
Gruß
Matthias

[jensb]

@Joe9 und alle, die sich für den Reading-Zeitstempel von FRM_IN interessieren

Joe9 hatte hier angeregt, den Zeitstempel des Readings nicht bei jedem Datenempfang sondern nur bei Zustandsänderung zu aktualisieren. Das ist in der beigefügten Testversion umgesetzt. Weder beim Neustart von FHEM noch beim Firmata-Verbindungsaufbau konnte ich bei der neuen Modulversion Änderungen des Zeitstempels feststellen. Mit verbose=5 für das FRM_IN-Modul kann man die empfangenen Zustandsmeldungen protokollieren, um sich selbst ein Bild davon zu machen.

Außerdem funktionieren nun auch die get-Kommandos für alarm, reading und state. Auch die Modulhilfe wurde aktualisiert.

Abhängig von den Rückmeldungen zur Testversion wird die neue Modulversion gegen Ende der Woche per FHEM Update zur Verfügung stehen.

Wer einen Grund kennt, die beschriebene Filterung nicht durchzuführen, sollte ihn bitte hier posten.

Grüße,
Jens

[jensb]

Die neue Version von FRM_IN ist ab 10.12.2018 per FHEM Update verfügbar.

Grüße,
Jens