FHEM Forum

FHEM - Hausautomations-Systeme => Sonstige Systeme => Thema gestartet von: jensb am 29 Dezember 2017, 21:35:33

Titel: Firmata Update für Firmware-Versionen ab 2.7
Beitrag von: jensb am 29 Dezember 2017, 21:35:33
Hallo,

Projekte mit Firmata oder ConfigurableFirmata ab Firmware-Version 2.7 funktionieren bis Ende 2017 nicht ohne Modifikationen mit FHEM. Hintergrund ist die fehlende Unterscheidung von Firmata-Protokoll-Version und Firmata-Firmware-Version. Während sich die Protokoll-Version nur selten ändert, gibt es gerade bei ConfigurableFirmata immer wieder neue Features und die wirken sich auf die Firmware-Version aus. Eine Lösung gibt es bereits seit Anfang 2016 und die besteht aus einem Update der Firmata-Treiber mit entsprechenden Anpassungen im Modul 10_FRM.pm. Das Update differenziert zwischen beiden Versionen und nimmt selbst bei Protokoll-Versionsänderungen Abwärtskompatibilität an, so dass auch zukünftige Firmata-Implementierungen wahrscheinlich ohne Änderungen funktionieren werden.

Die Firmata-Treiber und Firmata-Module wurden bisher von Norbert  (https://forum.fhem.de/index.php?action=profile;u=677) betreut. Leider hat Norbert schon länger keine Zeit mehr gefunden, die Firmata-Komponenten zu pflegen und es ist auch nicht gelungen, mit ihm Kontakt aufzunehmen. Das bedaure ich, denn die Zusammenarbeit mit Norbert habe ich sehr geschätzt. Nach Rücksprache mit Rudi können die Module von Norbert als verwaist betrachtet werden. Damit der Status Quo für Firmata ein Ende hat, werde ich die Betreuung der Firmata-Treiber, des FRM-Modul und 3 weitere Firmata-Module übernehmen. Wer Interesse hat, eines der übrigen Firmata-Modulen zu betreuen, kann das hier bekannt geben. Die folgende Liste gibt einen Überblick über die betroffenen Module:

FHEM/10_FRM.pm               ntruchsess -> jensb
FHEM/20_FRM_AD.pm            ntruchsess -> jensb
FHEM/20_FRM_ROTENC.pm        ntruchsess -> ?
FHEM/20_FRM_I2C.pm           ntruchsess -> ?
FHEM/20_FRM_IN.pm            ntruchsess -> jensb
FHEM/20_FRM_LCD.pm           ntruchsess -> ?
FHEM/20_FRM_OUT.pm           ntruchsess -> jensb
FHEM/20_FRM_PWM.pm           ntruchsess -> jensb
FHEM/20_FRM_RBG.pm           ntruchsess -> ?
FHEM/20_FRM_SERVO.pm         ntruchsess -> ?
FHEM/20_FRM_STEPPER.pm       ntruchsess -> ?
FHEM/lib/Device/Firmata/*    ntruchsess -> jensb


Das von mir vorbereitete Update-Paket aus Firmata-Treiber und FRM-Modul hat gegenüber der derzeitigen Version aus FHEM folgende Features:

Unterscheidung von Firmata Protokoll- und Firmware-Version

Verbessertes Init- und Reconnect-Verhalten

I2C IO-Fehler

Support für serielle Firmata Schnittstellen

Dokumentation

Modul FRM_AD

Modul FRM_OUT:

Modul FRM_PWM:

Das Update wird in 3 Schritten zur Verfügung gestellt:

Grüße,
Jens




UPDATE 09.01.2018

Auf Basis der erfolgten Rückmeldungen empfehle ich den Firmata-Anwendern, die aktuellen FHEM-Updates für das FRM-Modul und die Firmata-Treiber zu verwenden. Wer OneWire einsetzt, dem kann es helfen, zusätzlich dieses (https://forum.fhem.de/index.php/topic,81104.msg748728.html#msg748728) gepatchte OWX_FRM-Modul zu verwenden.

Dieser Thread soll vor allem das Update unterstützen und Funktionsprobleme lösen, die die alte Version nicht hatte. Davon gab es bisher nur einen Fall und der ist bereits in das Updates eingeflossen. Gerne können hier auch Wünsche diskutiert werden, um die neue Version noch weiter zu verbessern.

Durch das Update sind einige Beschreibungen in der Wiki überarbeitungsbedürftig, insbesondere können alle Anpassungen an FHEM und Firmata entfallen.

Was dieser Thread nicht kann, ist OneWire-spezifische Problem lösen, die schon vor dem Update bestanden haben. Bitte solche Punkte im OneWire-Bereich ansprechen.




UPDATE 17.01.2018

Wie bereits angekündigt gibt es nun die 2. Update-Runde mit ein paar kleinen Features. Ein Teil stammt aus Rückmeldungen dieses Threads.

Modul FRM:

Installationsvoraussetzung: perl-firmata 0.64 (über FHEM Update verfügbar)

Modul FRM_IN:

Installationsvoraussetzung: perl-firmata 0.64 (über FHEM Update verfügbar), Funktionsvorraussetzung: FRM mit Internal "pullup_pins"

Modul FRM_OUT:

Installationsvoraussetzung: abwärtskompatibel




UPDATE 03.02.2018

Die hier angefügten Module sind seit dem 27.01.2018 über das FHEM-Update verfügbar. Ich danke allen Beta-Testern für die Rückmeldungen.

Jens
Titel: Antw:Firmata Update für Firmare-Versionen ab 2.7
Beitrag von: JensS am 29 Dezember 2017, 23:29:28
Hallo Jens,

danke für dein En­ga­ge­ment :). Bin schon mächtig gespannt auf die Aktualisierung.

Gruß Jens
Titel: Antw:Firmata Update für Firmware-Versionen ab 2.7
Beitrag von: Maista am 30 Dezember 2017, 21:52:09
Hallo Jens
Danke für die Anpassungen!
Wäre schade gewesen wenn das nicht mehr aktuell gehalten worden wäre.
Wenn ich Zeit habe werde ich testen.

Guten Rutsch

Gerd
Titel: Antw:Firmata Update für Firmware-Versionen ab 2.7
Beitrag von: ThoTo am 30 Dezember 2017, 23:39:10
Vielen Dank dass du diese Module übernimmst!!!!
Hoffe die Firmata Probleme bei mir haben dann ein Ende :-)

LG Thomas
Titel: Antw:Firmata Update für Firmware-Versionen ab 2.7
Beitrag von: JensS am 01 Januar 2018, 12:37:37
Hallo Jens,

das Update und die Module habe ich eingespielt. Mein Testsystem mit einem USB-Firmata (FRMa) und einem Dummy-Netzwerk-Firmata (FRMb) stürzt mit folgender Log ab. Ich nutze ConfigurableFirmata 2.10 mit 00_OWX.pm.
2018.01.01 12:31:28 0: Server shutdown
2018.01.01 12:31:32 1: Including fhem.cfg
2018.01.01 12:31:32 3: telnetPort: port 7072 opened
2018.01.01 12:31:32 3: WEB: port 8083 opened
2018.01.01 12:31:32 3: WEBphone: port 8084 opened
2018.01.01 12:31:32 3: WEBtablet: port 8085 opened
2018.01.01 12:31:32 2: eventTypes: loaded 43 events from ./log/eventTypes.txt
2018.01.01 12:31:39 1: PERL WARNING: Use of uninitialized value in numeric comparison (<=>) at fhem.pl line 2028, <$fh> line 56.
2018.01.01 12:31:39 3: OWTHERM:  Device OWX_28_3EC1DA050000 defined.
2018.01.01 12:31:39 1: Including ./log/fhem.save
2018.01.01 12:31:39 1: Error: >FRMa:7< has no TYPE, but following keys: ><
2018.01.01 12:31:39 1: Error: >FRMb:6< has no TYPE, but following keys: ><
2018.01.01 12:31:39 3: Opening FRMa device /dev/ttyUSB0
2018.01.01 12:31:39 3: Setting FRMa serial parameters to 57600,8,N,1
2018.01.01 12:31:39 3: FRMa device opened
2018.01.01 12:31:39 3: FRMb: port 3034 opened
2018.01.01 12:31:39 0: Featurelevel: 5.8
2018.01.01 12:31:39 0: Server started with 21 defined entities (fhem.pl:15710/2017-12-27 perl:5.024001 os:linux user:root pid:18427)
2018.01.01 12:31:42 3: FRMa querying Firmata versions
@./FHEM/10_FRM.pm:main:530 : Unhandled attribute 'protocol_version_query' called

Gruß Jens
Titel: Antw:Firmata Update für Firmware-Versionen ab 2.7
Beitrag von: jensb am 01 Januar 2018, 12:51:41
Hallo Jens,

danke für den schnellen Test. Hier ein paar Fragen, damit ich die Ursache möglichst schnell eingrenzen kann:

(1) Stürzt FHEM komplett ab oder funktionieren "nur" die Firmata-Devices nicht?
(2) Tritt der Fehler auch auf, wenn "nur" die Firmata-Treiber aktualisiert sind?

Grüße,
Jens
Titel: Antw:Firmata Update für Firmware-Versionen ab 2.7
Beitrag von: JensS am 01 Januar 2018, 12:56:20
Das ganze System stürzt ab. Mit der originalen 10_FRM.pm läuft es - allerdings ohne OWX.
Titel: Antw:Firmata Update für Firmware-Versionen ab 2.7
Beitrag von: jensb am 01 Januar 2018, 13:00:00
Kann ich davon ausgehen, dass du einen Arduino an einem Raspberry per USB angeschlossen hast? Wenn nein, bitte Aufbau kurz beschreiben.

Bitte poste auch noch deine Config für die beiden FRM-Devices und das OWX, damit ich das nachstellen kann.

Grüße,
Jens
Titel: Antw:Firmata Update für Firmware-Versionen ab 2.7
Beitrag von: JensS am 01 Januar 2018, 13:07:00
Gut geraten - der Arduino hängt an einem NanoPi Neo2 mit Armbian Stretch.
Hier die config:attr global userattr cmdIcon devStateIcon devStateStyle icon sortby webCmd webCmdLabel:textField-long widgetOverride
attr global autoload_undefined_devices 1
attr global autosave 0
attr global exclude_from_update 10_FRM.pm Constants.pm Firmata.pm Platform.pm Protocol.pm
attr global logfile ./log/fhem-%Y-%m.log
attr global modpath .
attr global motd .
attr global statefile ./log/fhem.save
attr global updateInBackground 1
attr global verbose 3

define telnetPort telnet 7072 global

define WEB FHEMWEB 8083 global
attr WEB editConfig 1

define WEBphone FHEMWEB 8084 global
attr WEBphone stylesheetPrefix smallscreen

define WEBtablet FHEMWEB 8085 global
attr WEBtablet stylesheetPrefix touchpad

# Fake FileLog entry, to access the fhem log from FHEMWEB
define Logfile FileLog ./log/fhem-%Y-%m.log fakelog

define autocreate autocreate
attr autocreate filelog ./log/%NAME-%Y.log

define eventTypes eventTypes ./log/eventTypes.txt

# Disable this to avoid looking for new USB devices on startup
#define initialUsbCheck notify global:INITIALIZED usb create
#attr initialUsbCheck disable 1
define FRMa FRM /dev/ttyUSB0@57600
define in1 FRM_IN 3
attr in1 IODev FRMa
attr in1 activeLow yes
attr in1 internal-pullup on
attr in1 stateFormat reading
define out1 FRM_OUT 6
attr out1 IODev FRMa
attr out1 stateFormat value
define OWXa OWX FRMa:7
attr OWXa interval 200
define OWX_28_3EC1DA050000 OWTHERM DS18B20 3EC1DA050000
attr OWX_28_3EC1DA050000 IODev OWXa
attr OWX_28_3EC1DA050000 interval 20
attr OWX_28_3EC1DA050000 model DS18B20
attr OWX_28_3EC1DA050000 room OWX
attr OWX_28_3EC1DA050000 tempHigh 75
attr OWX_28_3EC1DA050000 tempLow 70
define FRMb FRM 3034 global
define OWX2 OWX FRMb:6
define I2CBus RPII2C 0
define I2CExpander I2C_MCP23008 0x20
attr I2CExpander IODev I2CBus
attr I2CExpander InterruptOut separate_active-high
attr I2CExpander OutputPorts A0,A2,A3,A4,A5,A6,A7
attr I2CExpander Pullup A0,A1
define I2Cnotify notify I2CExpander:PortA1:.* set I2CExpander PortA0 [I2CExpander:PortA1]
define I2Cget at +*00:00:02 get I2CExpander

Gruß Jens
Titel: Antw:Firmata Update für Firmware-Versionen ab 2.7
Beitrag von: jensb am 01 Januar 2018, 13:30:34
Das Update der Firmata-Treiber auf Version 0.63 ist seit 10:42 eingecheckt. Bei mir stürzt FHEM mit dem hier geposteten FRM-Modul aktuell nach dem Update auch ab. Ursache ist, dass der neue Firmata-Treiber mit noch nicht per FHEM-Update verteilt wird. Leider weiß ich nicht, wie lange das dauert. Überprüfen kann man die eigene Firmata Treiber-Version, indem man sich nach dem Update  im Unterverzeichnis "FHEM/lib/Device/Firmata" in Zeile 22 der Datei "Firmata.pm" den Wert hinter our $VERSION ansieht.

Wer es eilig hat, kann den neuen Firmata Treiber hier (https://svn.fhem.de/trac/browser/trunk/fhem/FHEM/lib/Device) aus dem SVN herunterladen.

Die neue Treiber-Version für sich allein sollte keinerlei Änderung bewirken. Dazu bedarf es zusätzlich der neuen Version des FRM-Moduls, das im 1. Post angehängt ist. Die neue Version des FRM-Moduls funktioniert aber ohne die Treiber-Updates nicht.

Die Änderungen der drei anderen aktualisierten Module FRM_AD, FRM_OUT und FRM_PWM sind von der Treiber-Aktualisierung unabhängig.

@dirigent Bitte überprüfe, ob du die Firmata Treiber-Updates schon hast. Wenn nicht, bitte aktualisieren und Test wiederholen.

Grüße,
Jens
Titel: Antw:Firmata Update für Firmware-Versionen ab 2.7
Beitrag von: JensS am 01 Januar 2018, 13:47:20
 :) Ok, habe die Dateien heruntergeladen und eingepflegt. Jetzt läuft es fehlerfrei, allerdings noch ohne OWX.
Gruß Jens
Titel: Antw:Firmata Update für Firmware-Versionen ab 2.7
Beitrag von: jensb am 01 Januar 2018, 14:01:00
Hallo Jens,

meinst du mit "allerdings noch ohne OWX", dass es fehlerfrei läuft, wenn du kein OWX-Device konfigurierst und Fehler macht, sobald du OWX dazu nimmst?

Wenn ja, versuch mir bitte möglichst viele Infos zu geben, z.B. bei allen relevanten Devices "verbose=5" einstellen, FHEM neu starten, Test durchführen und Log posten.  Ich habe selbst kein OneWire-Device an meinen Firmatas und kann das nicht ohne weiteres nachstellen. Änderungen im Zusammenhang mit OWX sollte es nicht geben. Was vorher funktioniert hat, sollte immer noch funktionieren.

Grüße,
Jens
Titel: Antw:Firmata Update für Firmware-Versionen ab 2.7
Beitrag von: JensS am 01 Januar 2018, 15:56:18
Das Problem ist, dass es vorher auch nicht funktionierte - seit es eine neue Firmata-OWX-Definition gibt:
define OWWa OWX FRMa:7
Das konnte ich bislang mit einer modifizierten 10_FRM.pm https://forum.fhem.de/index.php/topic,80409.0.html (https://forum.fhem.de/index.php/topic,80409.0.html) umgehen.
Zum Test genügte es, zwei Dummy-OWX an zwei Dummy-FRM anzulegen. Dann wurden den OWXes, mangels fehlender OWX-IODev-Attribute, das falsche FRM zugewiesen.

Gruß Jens

p.s. anbei die Logdatei
Titel: Antw:Firmata Update für Firmware-Versionen ab 2.7
Beitrag von: jensb am 01 Januar 2018, 19:08:09
Hallo Jens,

habe mir das Zusammenspiel von FRM und OWX mal angesehen. Die nun fehlende automatische IODev-Zuordnung hat überhaupt nichts mit Firmata zu tun, sondern ist auf die internen Abhängigkeiten der FHEM-Module OWX und FRM zurückzuführen: Die Änderungen an OWX haben zur Inkompatibilität mit FRM geführt.

Dein angepasstes FRM-Modul aus dem Thread https://forum.fhem.de/index.php/topic,80409.0.html (https://forum.fhem.de/index.php/topic,80409.0.html) kann ich als Grundlage für einen Patch verwenden, aber es muss noch leicht überarbeitet werden. Du könntest bei Bedarf bis dahin die Änderungen noch einmal genauso in die neue Version des FRM-Moduls einbauen.

Grüße,
Jens
Titel: Antw:Firmata Update für Firmware-Versionen ab 2.7
Beitrag von: JensS am 01 Januar 2018, 19:29:54
Hallo Jens, deine 10_FRM.pm habe ich modifiziert und nun klappt's auch mit dem Nachbarn ;D .
Habe die Datei https://forum.fhem.de/index.php/topic,80409.0.html (https://forum.fhem.de/index.php/topic,80409.0.html) auch gleich getauscht.
Anbei ein Log der funktionierenden Kombination OWX-FRM.

Vielen Dank!
Gruß Jens

p.s. Eine unverschämte Bitte: Kannst du ins FRM_IN ein Attribut debounce (ms) einbauen?
Titel: Antw:Firmata Update für Firmware-Versionen ab 2.7
Beitrag von: jensb am 01 Januar 2018, 21:24:37
ZitatKannst du ins FRM_IN ein Attribut debounce (ms) einbauen?
Prinzipiell ja, aber das geht z.B. auch mit einem notify, oder du machst aus reading on/off ein neuesReading 1/0 und verwendest event-aggregator.

Grüße,
Jens
Titel: Antw:Firmata Update für Firmware-Versionen ab 2.7
Beitrag von: JensS am 01 Januar 2018, 21:56:06
Ok, dann schaue ich mal.
Gruß Jens

Übrigens läuft FRM weiterhin fehlerfrei.
Titel: Antw:Firmata Update für Firmware-Versionen ab 2.7
Beitrag von: jensb am 01 Januar 2018, 22:52:37
Hallo Jens,

hier das überarbeitete FRM-Modul für die IODev-Zuordnung von OWX. Dein Ansatz steckt in Zeile 794. In der ursprünglichen Version hat FHEM von FRM keinen Vorschlag für ein IODev erhalten und deshalb ein zufällig "passendes" ausgewählt. Da ich nur die Konfiguration testen kann, bitte ich dich, einen Test mit Hardware durchzuführen. Möglicherweise reicht meine Änderung noch nicht aus. Dann bitte noch einmal Logs mit verbose=5 posten.

Grüße,
Jens
Titel: Antw:Firmata Update für Firmware-Versionen ab 2.7
Beitrag von: jensb am 02 Januar 2018, 09:12:13
Hallo Jens,

nochmal was zum Aspekt "debounce". Für Zeiten unterhalb von 1000 ms sollte man Entprellen besser mit Hardware umsetzten, da FHEM je nach aktiven Modulen und CPU-Leistung nicht immer spontan reagieren kann und das Ergebnis entsprechend schwammig wäre. Außerdem wird FHEM nicht mit schnellen Signaländerungen bombardiert, wenn schon vorher gefiltert wird. Firmata hat dieses Feature aber auch nicht. Was bleibt ist z.B. ein RC am Eingang.

Grüße,
Jens
Titel: Antw:Firmata Update für Firmware-Versionen ab 2.7
Beitrag von: ThoTo am 02 Januar 2018, 10:51:42
Zitat von: jensb am 01 Januar 2018, 22:52:37
hier das überarbeitete FRM-Modul für die IODev-Zuordnung von OWX. Dein Ansatz steckt in Zeile 794. In der ursprünglichen Version hat FHEM von FRM keinen Vorschlag für ein IODev erhalten und deshalb ein zufällig "passendes" ausgewählt. Da ich nur die Konfiguration testen kann, bitte ich dich, einen Test mit Hardware durchzuführen. Möglicherweise reicht meine Änderung noch nicht aus. Dann bitte noch einmal Logs mit verbose=5 posten.

Hallo Jens,

damit das Feedback in einem Thread landet, melde ich mich hier.
Habe die von dir aktualisierte 10_FRM.pm und 11_OWX_FRM.pm integriert und mein FHEM mit den 1Wire sensoren läuft :) :)
Keine Auffälligkeiten festgestellt.

Danke nochmal!

LG Thomas
Titel: Antw:Firmata Update für Firmware-Versionen ab 2.7
Beitrag von: JensS am 02 Januar 2018, 17:16:28
So, deine 10_FRM.pm und 00_OWX.pm.patch habe ich eingepflegt. Bis jetzt läuft's gut.
Debounce - die FRM_IN habe ich bis jetzt mit 1kOhm und 2,2mikroF entprellt - geht ja auch.
Bin jetzt erst mal weg.

Gruß Jens
Titel: Antw:Firmata Update für Firmware-Versionen ab 2.7
Beitrag von: ThoTo am 04 Januar 2018, 11:51:19
Rückmeldung nach über zwei Tagen: Läuft fehlerfrei und mein FHEM crasht nicht mehr.
Hab' ich den Watchdog umsonst gebaut  ;D ;D

LG Thomas
Titel: Antw:Firmata Update für Firmware-Versionen ab 2.7
Beitrag von: jensb am 04 Januar 2018, 13:14:47
Die aktualisierten Firmata-Module werden nun per FHEM Update zur Verfügung gestellt. Der Patch (https://forum.fhem.de/index.php/topic,82020.0.html) für 11_OWX_FRM.pm muss noch von @pahenning bewertet werden.

@dirigent + @ThoTo Danke für das Testen und die Rückmeldungen.

Grüße,
Jens
Titel: Antw:Firmata Update für Firmware-Versionen ab 2.7
Beitrag von: abc2006 am 04 Januar 2018, 17:52:43
Hi,
ich hab ne Rückmeldung (bzw. eine Frage).

Ich habe:

FHEM komplett neu aufgesetzt (aus dem SVN). Läuft auf einem Raspberry PI 3.
Per USB ist ein Arduino Nano angeschlossen, mit ConfigurableFirmata 2.10 (um die gehts doch, oder?? )
An Pin 9 eben dieses Arduinos ist ein OWCOUNTER angeschlossen (DS2423)

Ich habe nun folgende Dinge in folgender Reihenfolge getan:

/etc/init.d/fhem start
define Arduino FRM /dev/ttyUSB0@57600
define OWio3 OWX Arduino:10
define OWC OWCOUNT 1D.CE780F000000 60


ein
get Arduino Firmware  liefert mir ein ConfigurableFirmata_210.ino
ein get Arduino version liefert mir ein V_2_10

soweit, so gut.

ein get OWio3 devices liefert mir keine Antwort. Der Fehler war aber schnell gefunden, OW hängt am Pin 9, und nicht wie konfiguriert an PIN 10.
Also Pin ändern auf 9. Dabei ist mir mehrfach FHEM abgestürzt. Warum es natürlich jetzt, wenn ichs dokumentieren will, geht ... keine Ahnung. Also, ich reichs nach, sobald ich was hab.

Das Discover meldet jetzt
OWX_Discover: 1-Wire devices found on bus OWio3
A3.AA55AA55AA55      unknown        OWX_A3_AA55AA55AA55

im Log steht:
2018.01.04 16:45:44 5: Arduino FRM:>f0734009f7
2018.01.04 16:45:44 5: SW: f0734009f7
2018.01.04 16:45:44 5: Arduino FRM:<f0734209
2018.01.04 16:45:44 5: Arduino FRM:<235556525a4a6a2a7a01f7
2018.01.04 16:45:44 2: OWX_Discover: Device with unknown family code 'A3' found on bus OWio3
2018.01.04 16:45:44 1: OWX_Discover: 1-Wire devices found on bus OWio3 (OWX_A3_AA55AA55AA55)
2018.01.04 16:45:57 5: Arduino FRM:>f0730109f7
2018.01.04 16:45:57 5: SW: f0730109f7
2018.01.04 16:45:57 5: Arduino FRM:>f0732c091d1c637b0000000006550030002029600100f7
2018.01.04 16:45:57 5: SW: f0732c091d1c637b0000000006550030002029600100f7
2018.01.04 16:45:57 5: Arduino FRM:<f073430906007c7f7f7f7f7f7f7f7f7f7f7f7f7f7f7f7f7f7f7f7f7f7f7f7f7f
2018.01.04 16:45:57 5: Arduino FRM:<7f7f7f7f7f7f7f7f7f7f7f7f7f7f7f7f7f7f7f7f7f7f03f7
2018.01.04 16:45:57 1: OWX_FRM::Complex receiving inside loop no. 1 0x30 0x30 0x30 0x30 0x30 0x30 0x30 0x30 0x30 0xa5 0xc0 0x01 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff
2018.01.04 16:45:57 5: Arduino FRM:>f0730109f7
2018.01.04 16:45:57 5: SW: f0730109f7
2018.01.04 16:45:57 1: OWXCOUNT_BinValues called for device OWC in context getpage.14 with data 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff
2018.01.04 16:45:57 1: OWXCOUNT_BinValues getpage: OWC: invalid CRC, 255 255 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff
2018.01.04 16:45:57 5: Arduino FRM:>f0730109f7
2018.01.04 16:45:57 5: SW: f0730109f7
2018.01.04 16:45:57 5: Arduino FRM:>f0732c091d1c637b0000000006550038002029700100f7
2018.01.04 16:45:57 5: SW: f0732c091d1c637b0000000006550038002029700100f7
2018.01.04 16:45:57 5: Arduino FRM:<f073430907007c7f7f7f7f7f7f7f7f7f7f7f7f7f7f7f7f7f7f7f7f7f7f7f7f7f
2018.01.04 16:45:57 5: Arduino FRM:<7f7f7f7f7f7f7f7f7f7f7f7f7f7f7f7f7f7f7f7f7f7f03f7
2018.01.04 16:45:57 1: OWX_FRM::Complex receiving inside loop no. 1 0x30 0x30 0x30 0x30 0x30 0x30 0x30 0x30 0x30 0xa5 0xe0 0x01 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff
2018.01.04 16:45:57 5: Arduino FRM:>f0730109f7
2018.01.04 16:45:57 5: SW: f0730109f7
2018.01.04 16:45:57 1: OWXCOUNT_BinValues called for device OWC in context getpage.15.final with data 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff
2018.01.04 16:45:57 1: OWXCOUNT_BinValues getpage: OWC: invalid CRC, 255 255 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff


Wenn ich den Arduino trenne (USB rausziehen) und wieder verbinde, erscheinen folgende Meldungen im LOG:


2018.01.04 16:47:21 1: /dev/ttyUSB0 disconnected, waiting to reappear (Arduino)
2018.01.04 16:47:21 5: Starting notify loop for Arduino, 1 event(s), first is DISCONNECTED
2018.01.04 16:47:21 5: createNotifyHash
2018.01.04 16:47:21 5: End notify loop for Arduino
2018.01.04 16:47:26 3: Setting Arduino serial parameters to 57600,8,N,1
2018.01.04 16:47:26 5: Arduino FRM_DoInit
2018.01.04 16:47:26 5: Arduino FRM:>ff
2018.01.04 16:47:26 5: SW: ff
2018.01.04 16:47:26 5: Arduino setup stage 1
2018.01.04 16:47:26 1: /dev/ttyUSB0 reappeared (Arduino)
2018.01.04 16:47:26 5: Starting notify loop for Arduino, 1 event(s), first is CONNECTED
2018.01.04 16:47:27 5: End notify loop for Arduino
2018.01.04 16:47:27 5: Arduino setup stage 1
2018.01.04 16:47:27 5: Arduino setup stage 1
2018.01.04 16:47:27 5: Arduino setup stage 1
2018.01.04 16:47:27 5: Arduino setup stage 1
2018.01.04 16:47:27 5: Arduino setup stage 1
2018.01.04 16:47:27 5: Arduino setup stage 1
2018.01.04 16:47:27 5: Arduino setup stage 1
2018.01.04 16:47:27 5: Arduino setup stage 1
2018.01.04 16:47:27 5: Arduino setup stage 1
2018.01.04 16:47:28 5: Arduino setup stage 1
2018.01.04 16:47:29 5: Arduino setup stage 1
2018.01.04 16:47:30 5: Arduino setup stage 1
2018.01.04 16:47:30 3: Arduino querying Firmata versions
2018.01.04 16:47:30 5: Arduino FRM:>f90000
2018.01.04 16:47:30 5: SW: f90000
2018.01.04 16:47:30 5: Arduino FRM:>f079f7
2018.01.04 16:47:30 5: SW: f079f7
2018.01.04 16:47:31 5: Arduino setup stage 1
2018.01.04 16:47:31 5: Arduino setup stage 1
2018.01.04 16:47:31 5: Arduino FRM:<f90206f079020a43006f006e0066006900670075007200610062006c00650046
2018.01.04 16:47:31 5: Arduino setup stage 1
2018.01.04 16:47:31 5: Arduino FRM:<00690072006d006100740061005f003200310030002e0069006e006f00f7e010
2018.01.04 16:47:31 5: Arduino setup stage 1
2018.01.04 16:47:31 3: Arduino Firmata Firmware Version: ConfigurableFirmata_210.ino V_2_10 (using Protocol Version: V_2_06)
2018.01.04 16:47:31 5: Arduino FRM:>f069f7
2018.01.04 16:47:31 5: SW: f069f7
2018.01.04 16:47:31 5: Arduino FRM:>f06bf7
2018.01.04 16:47:31 5: SW: f06bf7
2018.01.04 16:47:31 5: Arduino FRM:<04e15a03e22703e31c03e45f02e53f02e63002e72c02f90206f079020a43006f
2018.01.04 16:47:31 5: Arduino setup stage 2
2018.01.04 16:47:31 5: Arduino FRM:<006e0066006900670075007200610062006c0065004600690072006d00610074
2018.01.04 16:47:31 5: Arduino setup stage 2
2018.01.04 16:47:31 5: Arduino FRM:<0061005f003200310030002e0069006e006f00f7f06a7f7f7f7f7f7f7f7f7f7f
2018.01.04 16:47:31 5: Arduino setup stage 2
2018.01.04 16:47:31 5: Arduino FRM:<7f7f7f7f0001020304050607f7f06c7f7f00010b01010107017f00010b010101
2018.01.04 16:47:31 5: Arduino setup stage 2
2018.01.04 16:47:31 5: Arduino FRM:<030807017f00010b01010107017f00010b010101030807017f00010b01010103
2018.01.04 16:47:31 5: Arduino setup stage 2
2018.01.04 16:47:31 5: Arduino FRM:<0807017f00010b01010107017f00010b01010107017f00010b01010103080701
2018.01.04 16:47:31 5: Arduino setup stage 2
2018.01.04 16:47:31 5: Arduino FRM:<7f00010b010101030807017f00010b010101030807017f00010b01010107017f
2018.01.04 16:47:31 5: Arduino setup stage 2
2018.01.04 16:47:31 5: Arduino FRM:<00010b01010107017f00010b010101020a07017f00010b010101020a07017f00
2018.01.04 16:47:31 5: Arduino setup stage 2
2018.01.04 16:47:31 5: Arduino FRM:<010b010101020a07017f00010b010101020a07017f00010b010101020a07017f
2018.01.04 16:47:31 5: Arduino setup stage 2
2018.01.04 16:47:31 5: Arduino FRM:<00010b010101020a07017f020a7f020a7ff7
2018.01.04 16:47:31 5: Arduino setup stage 2
2018.01.04 16:47:31 5: Arduino FRM:>f07a6807f7
2018.01.04 16:47:31 5: SW: f07a6807f7
2018.01.04 16:47:31 5: Arduino setup stage 3
2018.01.04 16:47:31 5: Starting notify loop for Arduino, 1 event(s), first is Initialized
2018.01.04 16:47:31 5: End notify loop for Arduino
2018.01.04 16:47:31 5: Arduino setup stage 4
2018.01.04 16:47:44 5: Cmd: >get OWio3 devices<
pin '9' is not configured for mode 'ONEWIRE' at FHEM/lib/Device/Firmata/Platform.pm line 770.


Danach stürzt FHEM ab.

ein list vom FRM-Device zeigt, dass Pin 9 aber als OW-Pin zur Verfügung steht:

Internals:
   DEF        /dev/ttyUSB0@57600
   DeviceName /dev/ttyUSB0@57600
   FD         5
   NAME       Arduino
   NOTIFYDEV  global
   NR         21
   NTFY_ORDER 50-Arduino
   PARTIAL   
   STATE      Initialized
   TYPE       FRM
   analog_pins 14,15,16,17,18,19,20,21
   analog_resolutions 14:10,15:10,16:10,17:10,18:10,19:10,20:10,21:10
   firmware   ConfigurableFirmata_210.ino
   firmware_version V_2_10
   input_pins 2,3,4,5,6,7,8,9,10,11,12,13,14,15,16,17,18,19
   onewire_pins 2,3,4,5,6,7,8,9,10,11,12,13,14,15,16,17,18,19
   output_pins 2,3,4,5,6,7,8,9,10,11,12,13,14,15,16,17,18,19
   protocol_version V_2_06
   pwm_pins   3,5,6,9,10,11
   pwm_resolutions 3:8,5:8,6:8,9:8,10:8,11:8
   READINGS:
     2018-01-04 16:49:58   state           Initialized
   SERIAL:
Attributes:
   verbose    5


der Vollständigkeit halber hier auch noch das owio3:

Internals:
   ALARMED    0
   ASYNCHRONOUS 0
   DEF        Arduino:9
   DeviceName Arduino:9
   FRM_OWX_CORRELATIONID 6
   FRM_OWX_CURRDEV 1D.CE780F000000.86
   HWDEVICE   Arduino
   INITDONE   1
   INTERFACE  firmata
   IODev      Arduino
   NAME       OWio3
   NR         22
   PARTIAL   
   PIN        9
   PRESENT    1
   ROM_ID     FF
   STATE      Initialized
   TYPE       OWX
   interval   300
   timeout    2
   version    7.05
   DEVHASH:
     OWX_1D_22DC84000003 1D.22DC84000003.51
     OWX_1D_23DC84000003 1D.23DC84000003.66
     OWio3      Busmaster
   DEVS:
     1D.22DC84000003.51
     1D.23DC84000003.66
   FRM_OWX_REPLIES:
     1D.22DC84000003.51 s�
     1D.23DC84000003.66 s�
     1D.CE780F000000.86 ������������������������������������������
   FRM_OWX_REQUESTS:
Attributes:


Seit heute hab ich auch wieder CRC-Fehler, obwohl ich an dem Schaltungsaufbau nix geändert hab. Ich werd das aber nochmal nachprüfen, obs mit der 206 wieder einwandfrei rennt...

Grüße,
Stephan
Titel: Antw:Firmata Update für Firmware-Versionen ab 2.7
Beitrag von: Achim am 04 Januar 2018, 19:10:28
Hallo,

ich habe heute die Updates eingespielt. Leider funktionierte danach der Firmata-Teil meiner Installation nicht mehr. Im Logfile habe ich folgende Meldungen stehen (wiederkehrend bis ich ein Restore auf die alten Dateien gemacht habe).
Zitat2018.01.04 18:45:55 4: Connection accepted from Ardu_Nano1_192.xx.xx.xx_1031
2018.01.04 18:45:55 3: Ardu_Nano1 Firmata device has reconnected
2018.01.04 18:45:55 3: Ardu_Nano1 querying Firmata versions
2018.01.04 18:45:55 3: Ardu_Nano1 Firmata Firmware Version: Eth6.ino V_2_06 (using Protocol Version: V_2_06)
2018.01.04 18:45:55 3: received String_data: Unhandled sysex command
2018.01.04 18:46:01 3: Ardu_Nano1 no response from Firmata, closing connection
2018.01.04 18:46:07 4: Connection accepted from Ardu_Nano1_192.xx.xx.xx_1032
2018.01.04 18:46:07 3: Ardu_Nano1 Firmata device has reconnected
2018.01.04 18:46:07 3: Ardu_Nano1 querying Firmata versions
2018.01.04 18:46:07 3: Ardu_Nano1 Firmata Firmware Version: Eth6.ino V_2_06 (using Protocol Version: V_2_06)
2018.01.04 18:46:07 3: received String_data: Unhandled sysex command
2018.01.04 18:46:12 3: Ardu_Nano1 no response from Firmata, closing connection
2018.01.04 18:46:17 4: Connection accepted from Ardu_Nano1_192.xx.xx.xx_1033
2018.01.04 18:46:18 3: Ardu_Nano1 Firmata device has reconnected
2018.01.04 18:46:18 3: Ardu_Nano1 querying Firmata versions
2018.01.04 18:46:18 3: Ardu_Nano1 Firmata Firmware Version: Eth6.ino V_2_06 (using Protocol Version: V_2_06)
2018.01.04 18:46:18 3: received String_data: Unhandled sysex command
2018.01.04 18:46:23 3: Ardu_Nano1 no response from Firmata, closing connection

Nach dem Restore der Dateien:
Zitat10_FRM.pm
20_FRM_AD.pm
20_FRM_OUT.pm
20_FRM_PWM.pm

ging es wieder. Wobei das Problem sicher in der 10_FRM.pm Datei liegt, da ich die anderen Module nicht verwende. Die Änderungen im LIB-Teil von Firmata sind noch die neuen. Damit gibt es keine Problem. Ich weiß die Infos sind nicht besonders viel, aber vielleicht reicht es ja zum Fehler finden. Sonst werde ich am Wochenende mal den Loglevel etwas höher setzen.

Viele Grüße
Achim
Titel: Antw:Firmata Update für Firmware-Versionen ab 2.7
Beitrag von: jensb am 04 Januar 2018, 19:48:26
@abc2006
Ich habe keine eigenen Erfahrungen mit OneWire an Firmata. Das Logging "OWX_Discover: Device with unknown family code 'A3' found on bus OWio3" sollte sich mal jemand ansehen, der mehr davon versteht. Abstürze im Zusammenhang mit OneWire hat z.B. auch @ThoTo gehabt (siehe weiter unten). Versuche es mit dem gepatchten 11_OWX_FRM (https://forum.fhem.de/index.php/topic,81104.msg740584.html#msg740584) noch einmal, dann könntest du zumindest den Absturz los sein.

Grüße,
Jens
Titel: Antw:Firmata Update für Firmware-Versionen ab 2.7
Beitrag von: jensb am 04 Januar 2018, 19:56:35
@Achim
Tut mir leid, das die neue Version bei dir rumzickt. Zu einer deiner Fehlermeldung steht in der FRM-Hilfe:
ZitatAnalogInputFirmata must always be enabled, even if not used. Otherwise the device setup will fail with the error <i>Unhandled sysex command</i> when connecting because the pin capability query cannot be completed.
Trifft das bei dir zu, d.h. ist bei dir AnalogFirmata deaktiviert? Wenn ja, könntest du es aktivieren und prüfen, ob es einen Unterschied macht?

Grüße,
Jens
Titel: Antw:Firmata Update für Firmware-Versionen ab 2.7
Beitrag von: JensS am 04 Januar 2018, 20:31:51
Meine Systeme laufen jetzt alle mit der neuen Version stabil. Allerdings hat das Update nicht richtig gegriffen, so dass ich manche Dateien nochmals manuell installierte. Vielleicht ist es hilfreich, den Dateien Firmata.pm, Constants.pm, etc. die Version mitzugeben:# $Id: Constants.pm 1 2018-01-03 18:59:05Z jensb $

Gruß Jens
Titel: Antw:Firmata Update für Firmware-Versionen ab 2.7
Beitrag von: Achim am 04 Januar 2018, 20:45:15
Hallo Jens,

AnalogInputFirmata habe ich nicht aktiviert. Die Fehlermeldung "received String_data: Unhandled sysex command" kommt bisher immer nur beim Neustart von FHEM. Habe ich auch in älteren Logs nachgesehen. Das stört bisher auch nicht. Ich sehe das Problem in der Meldung:

ZitatArdu_Nano1 no response from Firmata, closing connection

Danach kommt gleich ein Reconnect und das wiederholt sich im 10sek Takt. An dem Arduino konfiguriere ich jetzt nichts herum. Das läuft bisher nach vielen Versuchen mit einer älteren ConfigurableFirmata Version und "feinem" austesten bis genügend freier Speicher vorhanden war und der Arduino nicht laufend abstürzt. Ich habe ein ENC28J60 Ethernet Modul und da ist der Speicher ziemlich knapp. Und an dem System hängen bei mir einige Temperatursensoren für die Heizungssteuerung/Optimierung dran. Wenn ich bei den Außentemperaturen rangehe geht der WAF Faktor aber so was von in den Keller.....

Viele Grüße
Achim
Titel: Antw:Firmata Update für Firmware-Versionen ab 2.7
Beitrag von: jensb am 04 Januar 2018, 20:46:18
@dirigent
ZitatVielleicht ist es hilfreich, den Dateien Firmata.pm, Constants.pm, etc. die Version mitzugeben
Darüber habe ich auch schon nachgedacht, aber das möchte ich gern vermeiden. Der Firmata-Treiber "perl-firmata" ist ein von FHEM unabhängiges Perl-Projekt mit eigener Lizenz, das zur Vereinfachung direkt mit FHEM verteilt wird. Der Code sollte unabhängig vom Verteilungsweg immer der Gleiche bleiben. Ich habe z.B. den Lizenztext und die Änderungen mit eingecheckt, aber diese Dateien werden über das FHEM Update gar nicht verteilt. Vielleicht kann irgendjemand den Update-Prozess dafür besser einstellen.

Grüße,
Jens
Titel: Antw:Firmata Update für Firmware-Versionen ab 2.7
Beitrag von: jensb am 04 Januar 2018, 20:52:45
@Achim
Das du unter diesen Umständen nichts ändern willst, kann ich gut verstehen. Ich bin aus diesem Grund zum WIZ5100 gewechselt, da hat man etwas mehr Spielraum. Habe mir den ursprünglichen Ablauf im FRM-Modul noch einmal angesehen. Da wird ein Timeout verwendet, wenn der Arduino nicht auf die "analog capabilities" antwortet. Werde das nachbauen und mich melden.

Grüße,
Jens
Titel: Antw:Firmata Update für Firmware-Versionen ab 2.7
Beitrag von: Achim am 04 Januar 2018, 20:53:27
Hallo,

bei mir sind die "perl-firmata" Treiber in dem LIB Verzeichnis durch das FHEM Update mit aktualisiert worden.

Viele Grüße
Achim
Titel: Antw:Firmata Update für Firmware-Versionen ab 2.7
Beitrag von: jensb am 04 Januar 2018, 21:11:33
@Achim
Hier ein gepatchtes FRM-Modul für den Verbindungsaufbau ohne AnalogInputFirmata. Wäre super, wenn du es heute noch testen könntest.

Grüße,
Jens
Titel: Antw:Firmata Update für Firmware-Versionen ab 2.7
Beitrag von: JensS am 04 Januar 2018, 21:40:03
@Achim,

ich weiß nicht, ob es noch relevant ist aber ntruchsess hat mir mal einen Tipp gegeben, wie man beim ENC28J60 etwas Speicher reduzieren kann.
https://forum.fhem.de/index.php/topic,31715.msg247573.html#msg247573 (https://forum.fhem.de/index.php/topic,31715.msg247573.html#msg247573)

Gruß Jens
Titel: Antw:Firmata Update für Firmware-Versionen ab 2.7
Beitrag von: Achim am 05 Januar 2018, 18:40:43
Hallo Jens,

deine Testversion ohne AnalogInput funktioniert bei mir. Hier der Logfile Auszug beim Neustart von FHEM:
Zitat2018.01.05 18:29:19 3: Ardu_Nano1 querying Firmata versions
2018.01.05 18:29:21 3: Ardu_Nano1 Firmata Firmware Version: Eth6.ino V_2_06 (using Protocol Version: V_2_06)
2018.01.05 18:29:28 3: received String_data: Unhandled sysex command
Die Meldung "unhandled sysex" ist trotz abgeschaltetem Analoginput noch vorhanden.

Die "Internals" vom FRM Modul haben sich etwas geändert:
Zitatfirmware_version   V_2_06
input_pins   2,3,4,5,6,7,8,9,14,15,16,17,18,19
onewire_pins   2,3,4,5,6,7,8,9,14,15,16,17,18,19
output_pins   2,3,4,5,6,7,8,9,14,15,16,17,18,19
protocol_version   V_2_06

Was ist der Unterschied zwischen der Firmware_version und der protocol_version? Und was kann man mit den Pin-Angabe anfangen? Woher kommen diese Infos?

Viele Grüße
Achim
Titel: Antw:Firmata Update für Firmware-Versionen ab 2.7
Beitrag von: Achim am 05 Januar 2018, 18:43:19
Hallo Jens,

vielen Dank für den Hinweis für die Firmata Konfiguration. Aber ich kenne sie bereits. Ich habe mich damals sehr intensiv mit dem Firmata Sketch beschäftigt. Hat eine Zeit gedauert bis der Arduino ohne Abstürze "dauerlauffähig" war. Je mehr freier Speicher, je stabiler das Teil.

Viele Grüße
Achim
Titel: Antw:Firmata Update für Firmware-Versionen ab 2.7
Beitrag von: jensb am 05 Januar 2018, 20:07:43
@Achim
Danke für die Rückmeldung. Werde nachher die überarbeitete FRM-Version einchecken, damit sie ab morgen per FHEM-Update zur Verfügung steht.

Die von dir erwähnten Internals hast du vorher nicht gesehen, da ja auch in der "alten" Version des FRM-Moduls ein Fehler aufgetreten ist, der die Verarbeitung der Capability-Abfragen des Firmata-Devices verhindert hat. Die neue Version verarbeitet die Antworten der Capability-Abfragen nun trotz des Fehlers. Die Fehlermeldung an sich ist nicht vermeidbar, da das FRM-Modul die Abfragen durchführen muss, um zu erfahren, was das Firmata-Device kann. Dein Firmata-Device antwortet auf eine der Capability-Abfragen mit "Unhandled sysex command" und will damit sagen, dass es diese eine Anfrage nicht unterstützt, weil du die Verarbeitung deaktiviert hast (AnalogInputFirmata). Die Pin-Infos sagen dir, welche Pins wie genutzt werden dürfen (also z.B. als digitalen Eingang, Ausgang, etc.). Das ist in deinem Fall nicht besonders spannend, aber je nach Firmata-Hardware und -Konfiguration können zwischen den Listen schon Unterschiede bestehen. In deinem Fall siehst du z.B. dass Pin 1 nicht verwendet werden darf. Außerdem werden bei dir natürlich keine analog_pins aufgeführt. Andere Firmata-Anwender, die mit AnalogInputFirmata arbeiten, haben die Pin-Beschreibungen auch mit der "alten" Version des FRM-Moduls schon gehabt.

Der Unterschied zwischen Firmware-Version und Protokoll-Version ist der eigentliche Grund für dieses Update. Firmata ist zunächst einmal eine Kommunikationsprotokolldefinition. Auch die aktuelle Version von ConfigurableFirmata 2.10 verwendet die Firmata Protokoll-Version 2.6. Die Versionsnummer von ConfigurableFirmata ist die Firmware-Version, also ein Indikator für die Features, die in den ConfigurableFirmata-Sketchen enthalten sind. In der "alten" Version der Firmata-Treiber und des FRM-Moduls wurde zwischen den beiden Versionen nicht unterschieden und nur auf die Firmware-Version geachtet. Deshalb hat ConfigurableFirmata ab Version 2.7 nicht ohne Anpassungen mit FHEM funktioniert (siehe 1. Post dieses Threads).

Grüße,
Jens
Titel: Antw:Firmata Update für Firmware-Versionen ab 2.7
Beitrag von: JensS am 05 Januar 2018, 21:40:57
Hallo Jens,

gute Arbeit! Habe soeben die aktuelle Version installiert und FRM läuft weiterhin einwandfrei.
Vielen Dank nochmals, dass du dich der Module angenommen hast.

Gruß Jens
Titel: Antw:Firmata Update für Firmware-Versionen ab 2.7
Beitrag von: jensb am 05 Januar 2018, 22:10:05
@dirigent
Freut mich sehr, dass es bei dir klappt :)

Ganz fertig bin ich aber noch nicht. Es wird eine weitere Runde geben, bestehend aus Firmata-Treiber, FRM und FRM_IN. Wie ich vor ein paar Tagen bemerkt habe, verwenden die aktuellen Versionen in FHEM eine seit Protokoll-Version 2.5 angekündigte Methode, um die Pullups bei digitalen Eingängen ein- und auszuschalten. Damit das nicht demnächst Ärger macht, bereite ich ein weiteres Update vor. Das Update ist abwärtskompatibel, d.h. wenn ein Firmata-Device die neuen Methoden nicht beherrscht, werden weiter die alten Methoden verwendet.

Grüße,
Jens
Titel: Antw:Firmata Update für Firmware-Versionen ab 2.7
Beitrag von: Maista am 05 Januar 2018, 23:57:00
Hallo Jens

Habe heute morgen blind ein update gemacht. FHEM bootet nicht mehr.
Weiß nicht wann ich Zeit finde zum nachschauen.

Müssen Änderungen an den Einstellungen gemacht werden das es funktioniert
oder hätte FHEM ohne Probleme starten müssen?

Hab ein Arduino Mega via USB am RPI angeschlossen.
Benutzt werden 7 One-Wire Ports.

Wenn ich dazu komme schau ich mir die Logs an .

Gruß Gerd
Titel: Antw:Firmata Update für Firmware-Versionen ab 2.7
Beitrag von: jensb am 06 Januar 2018, 00:21:00
Hallo Gerd,

Änderungen an der Konfiguration sind für das Update nicht erforderlich. Wenn du OneWire verwendest, solltest du auf jeden Fall zusätzlich den schon erwähnten Patch für 11_OWX_FRM.pm (https://forum.fhem.de/index.php/topic,81104.msg740584.html#msg740584) herunterladen und zusätzlich einspielen. OneWire verursacht in der aktuellen Version einen Absturz, wenn Firmata Plausibilitätsfehler meldet, da es die Fehlermeldung ignoriert.

Bitte poste deine Logs und nimm bis auf weiteres die vorherige 10_FRM.pm aus dem Backup-Verzeichnis.

Grüße,
Jens

Titel: Antw:Firmata Update für Firmware-Versionen ab 2.7
Beitrag von: JensS am 06 Januar 2018, 08:48:08
Guten Morgen Jens,

mit der neuen 10_FRM.pm funktioniert die asyncrone Abfrage meines 18b20 nicht. Syncron funktioniert es. Hier die verbose5-Ausgabe:2018.01.06 08:37:44 3: FRMa querying Firmata versions
2018.01.06 08:37:46 3: FRMa Firmata Firmware Version: Mega206.ino V_2_10 (using Protocol Version: V_2_06)
2018.01.06 08:38:41 1: OWX_Init called for bus OWXa with interface state Initialized, now going for detect
2018.01.06 08:38:41 1: OWX: 1-Wire bus OWXa: interface Firmata detected in FRMa
2018.01.06 08:38:46 3: OWTHERM:  Device OWX_28_3EC1DA050000 defined.
2018.01.06 08:38:46 1: OWX_Discover: 1-Wire devices found on bus OWXa (OWX_28_3EC1DA050000)
2018.01.06 08:38:46 1: OWX_Discover: 1-Wire devices found on bus OWXa (OWX_28_3EC1DA050000)
2018.01.06 08:38:46 1: OWX_Discover: 1-Wire devices found on bus OWXa (OWX_28_3EC1DA050000)
2018.01.06 08:42:28 4: OWX_Qomplex: Added dev 283EC1DA05000020 to queue OWXa context=convert
2018.01.06 08:42:28 1:    queue OWXa contains 1 entries after insertion
2018.01.06 08:42:28 1:     => 283EC1DA05000020 context convert expecting 1 bytes, waiting
2018.01.06 08:42:28 1: ----------------------------------------------
2018.01.06 08:42:28 1: OWX_Qomplex: Added dev 283EC1DA05000020 to queue OWXa numread=19
2018.01.06 08:42:28 1:    queue OWXa contains 2 entries after insertion
2018.01.06 08:42:28 1:     => 283EC1DA05000020 context convert expecting 1 bytes, waiting
2018.01.06 08:42:28 1:     => 283EC1DA05000020 context readsp expecting 19 bytes, waiting
2018.01.06 08:42:28 1: ----------------------------------------------


Gruß Jens
Titel: Antw:Firmata Update für Firmware-Versionen ab 2.7
Beitrag von: jensb am 06 Januar 2018, 10:55:27
Hallo Jens,

hier scheint das Firmata-Device nicht zu antworten. Bitte mache den Test noch einmal mit verbose=5 für OWX+FRM, damit man die Firmata-Telegramme sieht.

Grüße,
Jens
Titel: Antw:Firmata Update für Firmware-Versionen ab 2.7
Beitrag von: jensb am 06 Januar 2018, 11:12:01
@Achim
Hast du auf deinem Firmata-Device AnalogInputFirmate deaktiviert?

@dirigent
Hat die asynchrone Abfrage mit dem "alten" FRM-Modul funktioniert?

Grüße,
Jens
Titel: Antw:Firmata Update für Firmware-Versionen ab 2.7
Beitrag von: Maista am 06 Januar 2018, 19:40:56
@Jensb
Hallo Jens. Gerade ein paar Minuten Zeit gefunden.
Nach dem ich das so umkopiert habe wie du das beschrieben hast, bootet FHEM wieder.
Danke.

Als Meldung stand im Log:
ZitatUndefined subroutine &main::ReadingsSingleUpdate called at ./FHEM/10_FRM.pm line 1055

Eventl. habe ich morgen mehr Musse das genauer zu untersuchen. Falls es noch nötig ist.

Soweit scheint es erst mal zu gehen.

Gruss Gerd
Titel: Antw:Firmata Update für Firmware-Versionen ab 2.7
Beitrag von: JensS am 06 Januar 2018, 19:59:55
Hallo Jens, hier die Logdaten des aktuellen Moduls inkl. ansync. OWX. Der DS18b20 wird gefunden und angelegt, jedoch bleibt die Temperaturabfrage ergebnislos.2018.01.06 19:54:28 1: Including fhem.cfg
2018.01.06 19:54:29 3: telnetPort: port 7072 opened
2018.01.06 19:54:29 3: WEB: port 8083 opened
2018.01.06 19:54:29 3: WEBphone: port 8084 opened
2018.01.06 19:54:29 3: WEBtablet: port 8085 opened
2018.01.06 19:54:29 2: eventTypes: loaded 38 events from ./log/eventTypes.txt
2018.01.06 19:54:29 1: Including ./log/fhem.save
2018.01.06 19:54:29 1: Error: >FRMa:7< has no TYPE, but following keys: ><
2018.01.06 19:54:29 3: Opening FRMa device /dev/ttyUSB0
2018.01.06 19:54:29 3: Setting FRMa serial parameters to 57600,8,N,1
2018.01.06 19:54:29 5: FRMa FRM_DoInit
2018.01.06 19:54:29 5: FRMa FRM:>ff
2018.01.06 19:54:29 5: SW: ff
2018.01.06 19:54:29 5: FRMa setup stage 1
2018.01.06 19:54:29 3: FRMa device opened
2018.01.06 19:54:29 0: Featurelevel: 5.8
2018.01.06 19:54:29 0: Server started with 16 defined entities (fhem.pl:15766/2018-01-03 perl:5.024001 os:linux user:fhem pid:2077)
2018.01.06 19:54:30 5: FRMa setup stage 1
2018.01.06 19:54:30 5: FRMa setup stage 1
2018.01.06 19:54:30 5: FRMa setup stage 1
2018.01.06 19:54:30 5: FRMa setup stage 1
2018.01.06 19:54:30 5: FRMa setup stage 1
2018.01.06 19:54:30 5: FRMa setup stage 1
2018.01.06 19:54:30 5: FRMa setup stage 1
2018.01.06 19:54:30 5: FRMa setup stage 1
2018.01.06 19:54:30 5: FRMa setup stage 1
2018.01.06 19:54:30 5: FRMa setup stage 1
2018.01.06 19:54:31 5: FRMa setup stage 1
2018.01.06 19:54:32 5: FRMa setup stage 1
2018.01.06 19:54:32 3: FRMa querying Firmata versions
2018.01.06 19:54:32 5: FRMa FRM:>f90000
2018.01.06 19:54:32 5: SW: f90000
2018.01.06 19:54:32 5: FRMa FRM:>f079f7
2018.01.06 19:54:32 5: SW: f079f7
2018.01.06 19:54:33 5: FRMa setup stage 1
2018.01.06 19:54:34 5: FRMa setup stage 1
2018.01.06 19:54:34 5: FRMa FRM:<f90206f079020a4d0065
2018.01.06 19:54:34 5: FRMa setup stage 1
2018.01.06 19:54:34 5: FRMa FRM:<00670061003200300036002e0069006e006f00f7e04d02e12402e27301e35b01e43101e50f01e61001e71c01f90206f079020a4d006500670061003200300036002e0069006e006f00f7
2018.01.06 19:54:34 5: FRMa setup stage 1
2018.01.06 19:54:34 3: FRMa Firmata Firmware Version: Mega206.ino V_2_10 (using Protocol Version: V_2_06)
2018.01.06 19:54:34 5: FRMa FRM:>f069f7
2018.01.06 19:54:34 5: SW: f069f7
2018.01.06 19:54:34 5: FRMa FRM:>f06bf7
2018.01.06 19:54:34 5: SW: f06bf7
2018.01.06 19:54:34 5: FRMa FRM:<f06a7f7f7f7f7f7f7f7f7f7f7f7f7f7f0001020304050607f7f06c7f7f00010b01010107017f00010b010101030807017f00010b01010107
2018.01.06 19:54:34 5: FRMa setup stage 2
2018.01.06 19:54:34 5: FRMa FRM:<017f00010b010101030807017f00010b010101030807017f00010b01010107017f00010b01010107017f00010b010101030807017f00010b010101030807017f00010b010101030807017f00010b01010107017f00010b01010107017f00010b010101020a07017f00010b010101020a07017f00010b010101020a07017f00010b010101020a07017f00010b010101020a07017f00010b010101020a07017f020a7f020a7ff7
2018.01.06 19:54:34 5: FRMa setup stage 2
2018.01.06 19:54:34 5: FRMa FRM:>f07a6807f7
2018.01.06 19:54:34 5: SW: f07a6807f7
2018.01.06 19:54:34 5: FRMa setup stage 3
2018.01.06 19:54:34 5: FRMa FRM:>f40300
2018.01.06 19:54:34 5: SW: f40300
2018.01.06 19:54:34 5: FRMa FRM:>d001
2018.01.06 19:54:34 5: SW: d001
2018.01.06 19:54:34 5: FRMa FRM:>d001
2018.01.06 19:54:34 5: SW: d001
2018.01.06 19:54:34 5: FRMa FRM:>f40601
2018.01.06 19:54:34 5: SW: f40601
2018.01.06 19:54:34 5: FRMa FRM:>d001
2018.01.06 19:54:34 5: SW: d001
2018.01.06 19:54:34 5: FRMa FRM:>900000
2018.01.06 19:54:34 5: SW: 900000
2018.01.06 19:54:34 5: FRMa setup stage 4
2018.01.06 19:54:34 5: FRMa FRM:<900000900000
2018.01.06 19:54:34 5: FRMa FRM:<900000
2018.01.06 19:55:24 5: OWXa FRM_Client_AssignIOPort before IODev FRMa -> FRMa
2018.01.06 19:55:24 5: OWXa FRM_Client_AssignIOPort after IODev FRMa
2018.01.06 19:55:24 5: FRMa FRM:>f40707
2018.01.06 19:55:24 5: SW: f40707
2018.01.06 19:55:29 1: OWX_Init called for bus OWXa with interface state Initialized, now going for detect
2018.01.06 19:55:29 1: OWX: 1-Wire bus OWXa: interface Firmata detected in FRMa
2018.01.06 19:55:29 5: FRMa FRM:>f0734007f7
2018.01.06 19:55:29 5: SW: f0734007f7
2018.01.06 19:55:29 5: FRMa FRM:<f0734207
2018.01.06 19:55:29 5: FRMa FRM:<287c04565d0000002000f7
2018.01.06 19:55:34 3: OWTHERM:  Device OWX_28_3EC1DA050000 defined.
2018.01.06 19:55:34 1: OWX_Discover: 1-Wire devices found on bus OWXa (OWX_28_3EC1DA050000)
2018.01.06 19:55:34 5: FRMa FRM:>f0734007f7
2018.01.06 19:55:34 5: SW: f0734007f7
2018.01.06 19:55:34 5: FRMa FRM:<f0734207
2018.01.06 19:55:34 5: FRMa FRM:<287c04565d0000002000f7
2018.01.06 19:55:34 1: OWX_Discover: 1-Wire devices found on bus OWXa (OWX_28_3EC1DA050000)
2018.01.06 19:55:44 4: OWX_Qomplex: Added dev 283EC1DA05000020 to queue OWXa context=convert
2018.01.06 19:55:44 1:    queue OWXa contains 1 entries after insertion
2018.01.06 19:55:44 1:     => 283EC1DA05000020 context convert expecting 1 bytes, waiting
2018.01.06 19:55:44 1: ----------------------------------------------
2018.01.06 19:55:44 1: OWX_Qomplex: Added dev 283EC1DA05000020 to queue OWXa numread=19
2018.01.06 19:55:44 1:    queue OWXa contains 2 entries after insertion
2018.01.06 19:55:44 1:     => 283EC1DA05000020 context convert expecting 1 bytes, waiting
2018.01.06 19:55:44 1:     => 283EC1DA05000020 context readsp expecting 19 bytes, waiting
2018.01.06 19:55:44 1: ----------------------------------------------
2018.01.06 19:55:50 4: OWX_Qomplex: Added dev 283EC1DA05000020 to queue OWXa context=convert
2018.01.06 19:55:50 1:    queue OWXa contains 1 entries after insertion
2018.01.06 19:55:50 1:     => 283EC1DA05000020 context convert expecting 1 bytes, waiting
2018.01.06 19:55:50 1: ----------------------------------------------
2018.01.06 19:55:50 1: OWX_Qomplex: Added dev 283EC1DA05000020 to queue OWXa numread=19
2018.01.06 19:55:50 1:    queue OWXa contains 2 entries after insertion
2018.01.06 19:55:50 1:     => 283EC1DA05000020 context convert expecting 1 bytes, waiting
2018.01.06 19:55:50 1:     => 283EC1DA05000020 context readsp expecting 19 bytes, waiting
2018.01.06 19:55:50 1: ----------------------------------------------


Gruß Jens

p.s. Die syncrone Variante funktioniert.
Titel: Antw:Firmata Update für Firmware-Versionen ab 2.7
Beitrag von: ThoTo am 06 Januar 2018, 20:39:55
Hallo Jens,

leider war es heute wieder soweit, mein FHEM ist stehen geblieben und vom Watchdog neu gestartet worden.
Letzte Meldung im Log wie gehabt:
pin '19' is not configured for mode 'ONEWIRE' at FHEM/lib/Device/Firmata/Platform.pm line 813.

Beim FHEM-Start erhalte ich btw. noch folgende Meldung, die war aber auch schon vor deinen Updates:
2018.01.06 18:37:06 1: PERL WARNING: Constant subroutine main::SHIFT redefined at ./FHEM/10_FRM.pm line 51.
main::BEGIN() called at ./FHEM/10_FRM.pm line 51
eval {...} called at ./FHEM/10_FRM.pm line 51
require ./FHEM/10_FRM.pm called at fhem.pl line 2436
eval {...} called at fhem.pl line 2435
main::CommandReload(undef, "10_FRM", undef) called at fhem.pl line 1851
main::LoadModule("FRM", undef) called at fhem.pl line 1908
main::CommandDefine(undef, "OWArduino FRM fhem_hw:2004", "define") called at fhem.pl line 1168
main::AnalyzeCommand(undef, "define OWArduino FRM fhem_hw:2004", "ACC") called at fhem.pl line 1022
main::AnalyzeCommandChain(undef, "define OWArduino FRM fhem_hw:2004") called at configDB.pm line 782
main::_cfgDB_Execute(undef, "attr global userattr alexaName alexaRoom cmdIcon devStateIcon"..., "attr global autoload_undefined_devices 1", "attr global autosave 0", "attr global dnsHostsFile /etc/hosts", "attr global dnsServer 192.168.x.x", "attr global exclude_from_update 19_Revolt.pm 11_OWX_FRM.pm 10"..., "attr global group FHEM", "attr global holiday2we AT_Feiertage", ...) called at configDB.pm line 475
main::cfgDB_ReadAll(undef) called at fhem.pl line 543


Hast du noch eine Idee oder was mache ich falsch??

LG Thomas
Titel: Antw:Firmata Update für Firmware-Versionen ab 2.7
Beitrag von: Achim am 06 Januar 2018, 21:03:02
Hallo Jens,

mit deiner Testversion funktioniert beim mir ein Input, Pin 15, nicht mehr. Ein anderer Input funktionierte noch, Pin 8. Fehlermeldungen sind keine im Log. Ich bin jetzt wieder auf die alte Version zurück. Damit funktioniert der Input Pin wieder. Wenn ich dazukomme, nehme ich morgen mal die neuen Module und setzte den Loglevel hoch.
AnalogInput ist bei der Firmata auf dem Arduino nach wie vor deaktiviert.

Viele Grüße
Achim
Titel: Antw:Firmata Update für Firmware-Versionen ab 2.7
Beitrag von: jensb am 06 Januar 2018, 21:12:43
Hallo Gerd,

die Meldung
ZitatUndefined subroutine &main::ReadingsSingleUpdate called at ./FHEM/10_FRM.pm line 1055
stammt aus der Sub FRM_OWX_Init des FRM-Moduls. Diese Sub wird von einer alten Version des Moduls 00_OWX.pm aufgerufen, die aktuelle 00_OWX.pm macht das anders. In deiner Version von 00_OWX.pm wird scheinbar ein Zugriff auf den FHEM-Kern gemacht, bevor dieser richtig initialisiert ist. Oder verwendest du eigenen Code, der die  Sub FRM_OWX_Init explizit aufruft?

Es ist wahrscheinlich sinnvoll, dass du zunächst ein konsistentes Update durchführst inkl. dem Patch für 11_OWX_FRM.pm.

Grüße,
Jens
Titel: Antw:Firmata Update für Firmware-Versionen ab 2.7
Beitrag von: jensb am 06 Januar 2018, 21:26:03
Hallo Jens,

nach
Zitat2018.01.06 19:55:34 5: FRMa FRM:<f0734207
2018.01.06 19:55:34 5: FRMa FRM:<287c04565d0000002000f7
hat das Firmata-Device auf die OneWire-Anfrage geantwortet. OWX scheint damit zunächst zufrieden zu sein, beschwert sich aber kurz darauf über fehlende Daten. Allerdings liefert Firmata keine Daten unaufgefordert. Was fehlt ist die nächste Anfrage von OWX. Woran das liegt kann ich nicht sagen, da OWX nicht meine Spielwiese ist.

Hier noch einmal meine Frage von heute Mittag: Hat die asynchrone Abfrage mit dem "alten" FRM-Modul funktioniert?

Grüße,
Jens
Titel: Antw:Firmata Update für Firmware-Versionen ab 2.7
Beitrag von: JensS am 06 Januar 2018, 21:28:56
Ja, mit deinen vorigen Versionen klappte es.
Titel: Antw:Firmata Update für Firmware-Versionen ab 2.7
Beitrag von: jensb am 06 Januar 2018, 21:35:12
Hallo Jens,

das Problem sieht für mich nicht so aus, als ob man das ohne vergleichbaren Hardwareaufbau nachstellen kann und die habe ich leider nicht. Eine Änderungen in den Firmata-Treibern und dem FRM-Modul in Bezug auf OneWire hat es nicht gegeben. Daher habe ich noch keine Idee, wo das Problem herkommt. Werde mir die OneWire-Abläufe mal ansehen. Wenn du eine Idee hast, lass es mich wissen.

Grüße,
Jens
Titel: Antw:Firmata Update für Firmware-Versionen ab 2.7
Beitrag von: JensS am 06 Januar 2018, 21:48:59
Hallo Jens,

Entwarnung - nach Einspielung der vorigen Version kam auch kein Wert. Hatte da eine Idee und habe die fhem.save gelöscht. Nun klappt es auch mit der neuen Version. Keine Ahnung, woran sich FHEM verschluckt hat.2018.01.06 21:44:33 1: Including fhem.cfg
2018.01.06 21:44:33 3: telnetPort: port 7072 opened
2018.01.06 21:44:33 3: WEB: port 8083 opened
2018.01.06 21:44:33 3: WEBphone: port 8084 opened
2018.01.06 21:44:33 3: WEBtablet: port 8085 opened
2018.01.06 21:44:34 2: eventTypes: loaded 42 events from ./log/eventTypes.txt
2018.01.06 21:44:40 1: PERL WARNING: Use of uninitialized value in numeric comparison (<=>) at fhem.pl line 2028, <$fh> line 64.
2018.01.06 21:44:40 3: OWTHERM:  Device OWX_28_3EC1DA050000 defined.
2018.01.06 21:44:40 1: Including ./log/fhem.save
2018.01.06 21:44:40 1: Error: >FRMa:7< has no TYPE, but following keys: ><
2018.01.06 21:44:40 3: Opening FRMa device /dev/ttyUSB0
2018.01.06 21:44:40 3: Setting FRMa serial parameters to 57600,8,N,1
2018.01.06 21:44:40 5: FRMa FRM_DoInit
2018.01.06 21:44:40 5: FRMa FRM:>ff
2018.01.06 21:44:40 5: SW: ff
2018.01.06 21:44:40 5: FRMa setup stage 1
2018.01.06 21:44:40 3: FRMa device opened
2018.01.06 21:44:40 0: Featurelevel: 5.8
2018.01.06 21:44:40 0: Server started with 17 defined entities (fhem.pl:15766/2018-01-03 perl:5.024001 os:linux user:root pid:4427)
2018.01.06 21:44:40 5: FRMa setup stage 1
2018.01.06 21:44:40 5: FRMa setup stage 1
2018.01.06 21:44:40 5: FRMa setup stage 1
2018.01.06 21:44:41 5: FRMa setup stage 1
2018.01.06 21:44:41 5: FRMa setup stage 1
2018.01.06 21:44:41 5: FRMa setup stage 1
2018.01.06 21:44:41 5: FRMa setup stage 1
2018.01.06 21:44:41 5: FRMa setup stage 1
2018.01.06 21:44:41 5: FRMa setup stage 1
2018.01.06 21:44:42 5: FRMa setup stage 1
2018.01.06 21:44:43 5: FRMa setup stage 1
2018.01.06 21:44:43 3: FRMa querying Firmata versions
2018.01.06 21:44:43 5: FRMa FRM:>f90000
2018.01.06 21:44:43 5: SW: f90000
2018.01.06 21:44:43 5: FRMa FRM:>f079f7
2018.01.06 21:44:43 5: SW: f079f7
2018.01.06 21:44:44 5: FRMa setup stage 1
2018.01.06 21:44:44 5: FRMa setup stage 1
2018.01.06 21:44:45 5: FRMa FRM:<f90206f079020a4d00650067006100
2018.01.06 21:44:45 5: FRMa setup stage 1
2018.01.06 21:44:45 5: FRMa FRM:<3200300036002e0069006e006f00f7e02502e15d01e21e01e37900e46d00e56200e65c00e75700f90206f079020a4d006500670061003200300036002e0069006e006f00f7
2018.01.06 21:44:45 5: FRMa setup stage 1
2018.01.06 21:44:45 3: FRMa Firmata Firmware Version: Mega206.ino V_2_10 (using Protocol Version: V_2_06)
2018.01.06 21:44:45 5: FRMa FRM:>f069f7
2018.01.06 21:44:45 5: SW: f069f7
2018.01.06 21:44:45 5: FRMa FRM:>f06bf7
2018.01.06 21:44:45 5: SW: f06bf7
2018.01.06 21:44:45 5: FRMa FRM:<f06a7f7f7f7f7f7f7f7f7f7f7f7f7f7f0001020304050607f7f06c7f7f00010b01010107017f00010b010101030807017f00010b010101
2018.01.06 21:44:45 5: FRMa setup stage 2
2018.01.06 21:44:45 5: FRMa FRM:<07017f00010b010101030807017f00010b010101030807017f00010b01010107017f00010b01010107017f00010b010101030807017f00010b010101030807017f00010b010101030807017f00010b01010107017f00010b01010107017f00010b010101020a07017f00010b010101020a07017f00010b010101020a07017f00010b010101020a07017f00010b010101020a07017f00010b010101020a07017f020a7f020a7ff7
2018.01.06 21:44:45 5: FRMa setup stage 2
2018.01.06 21:44:45 5: FRMa FRM:>f07a6807f7
2018.01.06 21:44:45 5: SW: f07a6807f7
2018.01.06 21:44:45 5: FRMa setup stage 3
2018.01.06 21:44:45 5: FRMa FRM:>f40300
2018.01.06 21:44:45 5: SW: f40300
2018.01.06 21:44:45 5: FRMa FRM:>d001
2018.01.06 21:44:45 5: SW: d001
2018.01.06 21:44:45 5: FRMa FRM:>d001
2018.01.06 21:44:45 5: SW: d001
2018.01.06 21:44:45 5: FRMa FRM:>f40601
2018.01.06 21:44:45 5: SW: f40601
2018.01.06 21:44:45 5: FRMa FRM:>d001
2018.01.06 21:44:45 5: SW: d001
2018.01.06 21:44:45 5: FRMa FRM:>900000
2018.01.06 21:44:45 5: SW: 900000
2018.01.06 21:44:45 5: FRMa setup stage 4
2018.01.06 21:44:45 5: FRMa FRM:<900000900000
2018.01.06 21:44:45 5: FRMa FRM:<900000
2018.01.06 21:44:50 4: OWX_Qomplex: Added dev 283EC1DA05000020 to queue OWXa context=convert
2018.01.06 21:44:50 1: OWX_FRM::Write attempted to undefined device OWXa
2018.01.06 21:44:50 1:    queue OWXa contains 1 entries after insertion
2018.01.06 21:44:50 1:     => 283EC1DA05000020 context convert expecting 1 bytes, active
2018.01.06 21:44:50 1: ----------------------------------------------
2018.01.06 21:44:50 1: OWX_Qomplex: Added dev 283EC1DA05000020 to queue OWXa numread=19
2018.01.06 21:44:50 1:    queue OWXa contains 2 entries after insertion
2018.01.06 21:44:50 1:     => 283EC1DA05000020 context convert expecting 1 bytes, active
2018.01.06 21:44:50 1:     => 283EC1DA05000020 context readsp expecting 19 bytes, waiting
2018.01.06 21:44:50 1: ----------------------------------------------
2018.01.06 21:44:51 1: OWX_FRM::Write attempted to undefined device OWXa
2018.01.06 21:45:29 5: OWXa FRM_Client_AssignIOPort before IODev FRMa -> FRMa
2018.01.06 21:45:29 5: OWXa FRM_Client_AssignIOPort after IODev FRMa
2018.01.06 21:45:29 5: FRMa FRM:>f40707
2018.01.06 21:45:29 5: SW: f40707
2018.01.06 21:45:34 1: OWX_Init called for bus OWXa with interface state Initialized, now going for detect
2018.01.06 21:45:34 1: OWX: 1-Wire bus OWXa: interface Firmata detected in FRMa
2018.01.06 21:45:34 5: FRMa FRM:>f0734007f7
2018.01.06 21:45:34 5: SW: f0734007f7
2018.01.06 21:45:34 5: FRMa FRM:<f0734207
2018.01.06 21:45:34 5: FRMa FRM:<287c04565d0000002000f7
2018.01.06 21:45:34 1: OWX_Discover: 1-Wire devices found on bus OWXa (OWX_28_3EC1DA050000)
2018.01.06 21:45:38 4: OWX_Qomplex: Added dev 283EC1DA05000020 to queue OWXa context=convert
2018.01.06 21:45:38 5: FRMa FRM:>f0730107f7
2018.01.06 21:45:38 5: SW: f0730107f7
2018.01.06 21:45:38 1: OWX_FRM::Write Sending out 0x55 0x28 0x3e 0xc1 0xda 0x05 0x00 0x00 0x20 0x44 0xff
2018.01.06 21:45:38 5: FRMa FRM:>f0732c07287c04565d00000020160000000011f7
2018.01.06 21:45:38 5: SW: f0732c07287c04565d00000020160000000011f7
2018.01.06 21:45:38 1:    queue OWXa contains 1 entries after insertion
2018.01.06 21:45:38 1:     => 283EC1DA05000020 context convert expecting 1 bytes, active
2018.01.06 21:45:38 1: ----------------------------------------------
2018.01.06 21:45:38 1: OWX_Qomplex: Added dev 283EC1DA05000020 to queue OWXa numread=19
2018.01.06 21:45:38 1:    queue OWXa contains 2 entries after insertion
2018.01.06 21:45:38 1:     => 283EC1DA05000020 context convert expecting 1 bytes, active
2018.01.06 21:45:38 1:     => 283EC1DA05000020 context readsp expecting 19 bytes, waiting
2018.01.06 21:45:38 1: ----------------------------------------------
2018.01.06 21:45:38 5: FRMa FRM:<f0734307000000000000000000000000000000f7
2018.01.06 21:45:38 1: OWX_FRM::Read receiving in first read 0x30 0x30 0x30 0x30 0x30 0x30 0x30 0x30 0x30 0x44 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00
2018.01.06 21:45:38 5: FRMa FRM:>f0730107f7
2018.01.06 21:45:38 5: SW: f0730107f7
2018.01.06 21:45:39 5: FRMa FRM:>f0734007f7
2018.01.06 21:45:39 5: SW: f0734007f7
2018.01.06 21:45:39 5: FRMa FRM:<f0734207
2018.01.06 21:45:39 5: FRMa FRM:<287c04565d0000002000f7
2018.01.06 21:45:39 1: OWX_Discover: 1-Wire devices found on bus OWXa (OWX_28_3EC1DA050000)
2018.01.06 21:45:39 5: FRMa FRM:>f0730107f7
2018.01.06 21:45:39 5: SW: f0730107f7
2018.01.06 21:45:39 1: OWX_FRM::Write Sending out 0x55 0x28 0x3e 0xc1 0xda 0x05 0x00 0x00 0x20 0xbe 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff
2018.01.06 21:45:39 5: FRMa FRM:>f0732c07287c04565d000000203a000800402ff7
2018.01.06 21:45:39 5: SW: f0732c07287c04565d000000203a000800402ff7
2018.01.06 21:45:39 5: FRMa FRM:<f07343070100340c3049513f7f074018707f7f7f7f7f7f7f7f7f7f7f7f7f7f7f
2018.01.06 21:45:39 5: FRMa FRM:<7f7f7f7f7f7f7f07f7
2018.01.06 21:45:39 1: OWX_FRM::Read receiving in first read 0x30 0x30 0x30 0x30 0x30 0x30 0x30 0x30 0x30 0xbe 0x8d 0x01 0x4b 0x46 0x7f 0xff 0x03 0x10 0x03 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff
2018.01.06 21:45:39 5: FRMa FRM:>f0730107f7
2018.01.06 21:45:39 5: SW: f0730107f7


Gruß Jens
Titel: Antw:Firmata Update für Firmware-Versionen ab 2.7
Beitrag von: jensb am 06 Januar 2018, 22:03:12
Hallo Thomas,

das Logging
Zitatpin '19' is not configured for mode 'ONEWIRE' at FHEM/lib/Device/Firmata/Platform.pm line 813.
deutet darauf hin, dass hier ein Ablauf nicht stimmt. 11_OWX_FRM muss zuerst den Pin in Firmata konfigurieren, bevor es darauf zugreifen darf. Außerdem sollte beim Zugriff eine Fehlerbehandlung erfolgen, damit FHEM nicht abstürzt.

Ich habe die 11_OWX_FRM.pm (https://forum.fhem.de/index.php/topic,81104.msg740584.html#msg740584) um weitere Fehlerbehandlungen erweitert, damit zunächst einmal die Abstürze aufhören. Bitte ausprobieren.

Zitat2018.01.06 18:37:06 1: PERL WARNING: Constant subroutine main::SHIFT redefined at ./FHEM/10_FRM.pm line 51.
Das sieht sehr ungewöhnlich aus, aber eine Erklärung habe ich spontan nicht.

Grüße,
Jens

UPDATE 07.01.2018: gepatchte 11_OWX_FRM.pm hierhin (https://forum.fhem.de/index.php/topic,81104.msg740584.html#msg740584) verschoben

UPDATE 07.01.2018: verwendest du auch 37_harmony.pm?
Titel: Antw:Firmata Update für Firmware-Versionen ab 2.7
Beitrag von: jensb am 06 Januar 2018, 22:09:35
Hallo Jens,

danke für die Entwarnung. Das sieht so viel besser aus. Wenn das Löschen von fhem.save hilft, muss es wohl ein Reading sein, das den Kommunikationsablauf beeinflusst und das wohl beim Neustart nicht zurück gesetzt wird (ich tippe auf 11_OWX_FRM.pm). Vielleicht kannst du durch Wiederholung des Tests und Vergleich herausfinden, welches Reading es ist.

Grüße,
Jens
Titel: Antw:Firmata Update für Firmware-Versionen ab 2.7
Beitrag von: JensS am 06 Januar 2018, 22:13:59
Ok, wenn es wieder auftritt, mach ich eine Sicherung der Sicherung.  :)
Titel: Antw:Firmata Update für Firmware-Versionen ab 2.7
Beitrag von: jensb am 06 Januar 2018, 22:14:29
Hallo Achim,

mit
Zitatmit deiner Testversion funktioniert beim mir ein Input, Pin 15, nicht mehr
meinst du vermutlich, dass Änderungen am Pin nicht mehr im FRM_IN-Device ankommen. Bitte mach ein Log mit verbose=5 für FRM und FRM_IN mit Neustart und mindestens einer Signaländerung.

Grüße,
Jens
Titel: Antw:Firmata Update für Firmware-Versionen ab 2.7
Beitrag von: Maista am 07 Januar 2018, 00:49:42
@jensb

Moin Jens

ZitatOder verwendest du eigenen Code, der die  Sub FRM_OWX_Init explizit aufruft?

Nein, so wie es ist :)
Ich habe allerdings die Aktuellen OWX-Module nicht installiert da bei mir dann mangels den IODEVs
nichts mehr funktionierte und ich danach keine Lust mehr hatte zu schauen wie man es hinbekommt.

Gruss
Gerd
Titel: Antw:Firmata Update für Firmware-Versionen ab 2.7
Beitrag von: jensb am 07 Januar 2018, 11:53:48
Hallo Gerd,

ich vermute, das du momentan eine inkompatible Mischung von OWX- und FRM-Modulen hast. Wenn du bei den alten OWX-Modulen bleiben willst/musst, dann nimm bitte auch die alten FRM-Module. Achte darauf, dass es neben dem 00_OWX.pm und dem 10_FRM.pm auch noch andere Module mit OWX und FRM im Namen gibt, die dann auch genauso "alt" seinen müssen. Du kannst eine zueinander passende Kombination z.B. auch aus dem FHEM SVN-Repository herunterladen.

Das Problem mit den IODevs von OWX ist aber mit der neuen Version von FRM gelöst (siehe diesen Post (https://forum.fhem.de/index.php/topic,81815.msg740576.html#msg740576)). Ein Update von OWX und FRM auf den aktuellen Stand, kombiniert mit dieser gepatchten 11_OWX_FRM.pm (https://forum.fhem.de/index.php/topic,81815.msg743801.html#msg743801) müsste die bessere Wahl sein.

Grüße,
Jens
Titel: Antw:Firmata Update für Firmware-Versionen ab 2.7
Beitrag von: abc2006 am 07 Januar 2018, 12:46:22
Hi,
ich habe bei dem FRM-Modul festgestellt, dass z.B nach einem restart von FHEM erstmal kurz "opened" im Status steht, danach "initialized". Sieht für mich nicht nach "connected" aus..

Soll es das bedeuten, oder habe ich einen Fehler?
Vielleicht wäre es sinnvoll, diesen Wert auf einen "sprechenden" Wert zu ändern... Wenn z.B. bei DOIF initialized steht, weiss ich, dass es bisher *nicht* reagiert hat ..

Grüße,
Stephan
Titel: Antw:Firmata Update für Firmware-Versionen ab 2.7
Beitrag von: jensb am 07 Januar 2018, 13:14:44
Hallo Stephan,

da ich nicht weiß, welche Anwender bereits mit welchen States arbeiten, möchte ich die bisherigen States möglichst nicht ändern. Das geht sowieso nicht ohne weiteres. Ein Teil der States kommt vom FRM-Modul, z.B. "Initialized", aber aus 2 völlig verschiedenen Abläufen heraus, nämlich einmal nach dem logischen Verbindungsaufbau zum Firmata-Device und jedes mal, wenn ein OneWire Device initialisiert wird (für mich unlogisch). Der State "opened" wiederum kommt aus dem DevIO-Modul, z.B. nach dem erfolgreichen Öffnen der seriellen Schnittstelle. Der Ablauf "opened" -> "Initialized" ist bei USB-Verbindungen also "normal" und bedeutet "verbunden + initialisiert".

Grüße,
Jens
Titel: Antw:Firmata Update für Firmware-Versionen ab 2.7
Beitrag von: abc2006 am 07 Januar 2018, 14:00:18
Alles klar, nehm ich zur Kenntnis, find ich aber trotzdem noch verwirrend:)

Danke,
Stephan
Titel: Antw:Firmata Update für Firmware-Versionen ab 2.7
Beitrag von: Maista am 07 Januar 2018, 14:30:52
@jensb
Hallo Jens,

danke für die Info. Ich habe nun doch noch weiter probiert. Und nach dem ich meine Defines den aktuellen Vorgaben angepasst habe, findet er nun alle OW-Device wieder!

Für alle die vor dem gleichen Problem stehen hier meine alten Defines:

#### definiere FRM als IO-Device
define FIRMATA FRM /dev/ttyACM0@57600
attr FIRMATA icon DIN_rail_firmata
attr FIRMATA room OWX,System

#### OW-Ports laden
#Port 2 fuer interne messungen
define OWio2 OWX 2
attr OWio2 IODev FIRMATA
attr OWio2 comment Sensor am Arduino-Mega
attr OWio2 room OWX,System

#Port 3 (ACHTUNG!! PORT4 geht nicht wenn LAN/SD-Card benutzt wird!)
define OWio3 OWX 3
attr OWio3 IODev FIRMATA
attr OWio3 comment Aussen Norden-Temperatur, Feuchte
attr OWio3 room OWX,System


Neu sieht das nun so aus:

#### definiere FRM als IO-Device
define FIRMATA FRM /dev/ttyACM0@57600
attr FIRMATA icon DIN_rail_firmata
attr FIRMATA room OWX,System

#### OW-Ports laden
#Port 2 fuer interne messungen
define OWio2 OWX FIRMATA:2
attr OWio2 comment Sensor am Arduino-Mega
attr OWio2 room OWX,System

#Port 3 (ACHTUNG!! PORT4 geht nicht wenn LAN/SD-Card benutzt wird!)
define OWio3 OWX FIRMATA:3
attr OWio3 comment Aussen Norden-Temperatur, Feuchte
attr OWio3 room OWX,System


Jens, zwei fragen habe ich noch

Wenn ich "set OWio2 reopen" setze bleibt der Kanal "disconnected". Er zeigt mir den DS18B20 noch als Device an. Ansprechen klappt aber nicht mehr. Erst nach einem Shutdown ist das OWio2 wieder im Internals "STATE" als "Initialized" markiert.

Das Readings "state" bleibt aber weiter auf "disconnected"

OWTHERM: Could not get values from device TA_28_736020050000, return was OWTHERM: TA_28_736020050000 not accessible
2018.01.07 14:15:14 1 : OWX_FRM::Ready function called for bus OWio2. STATE=disconnected
2018.01.07 14:16:14 1 : OWX_FRM::Ready function called for bus OWio2. STATE=disconnected
2018.01.07 14:17:00 1 : ====> REOPENING DEVICE
2018.01.07 14:17:00 3 : OWX_Set OWio2 reopen => 0
2018-01-07 14:17:00 OWX OWio2 reopen
2018.01.07 14:17:11 5 : FIRMATA FRM:>f0734002f7
2018.01.07 14:17:11 5 : SW: f0734002f7
2018.01.07 14:17:11 5 : FIRMATA FRM:<f0734202
2018.01.07 14:17:11 5 : FIRMATA FRM:<2866010352
2018.01.07 14:17:11 5 : FIRMATA FRM:<0000000b01f7
2018.01.07 14:17:11 1 : OWX_Discover: 1-Wire devices found on bus OWio2 (TA_28_736020050000)
2018.01.07 14:17:16 1 : OWX_FRM::Ready function called for bus OWio2. STATE=disconnected
2018.01.07 14:17:20 5 : FIRMATA FRM:>f0730102f7
2018.01.07 14:17:20 5 : SW: f0730102f7
2018.01.07 14:17:20 1 : OWX_Complex called while interface OWio2 disconnected


Zweite frage, in wie weit ist die Version der Firmata im Arduino von belang?
Kann ich meine alte 2.06 vorerst laufen lassen?

Danke für deine Arbeit. Somit hat Firmata wieder eine Zukunft  ;D

Schönen Sonntag.

Gruss,
Gerd

Titel: Antw:Firmata Update für Firmware-Versionen ab 2.7
Beitrag von: jensb am 07 Januar 2018, 14:46:00
Hallo Gerd,

danke für die Rückmeldung.

Zitat
Wenn ich "set OWio2 reopen" setze bleibt der Kanal "disconnected". Er zeigt mir den DS18B20 noch als Device an. Ansprechen klappt aber nicht mehr. Erst nach einem Shutdown ist das OWio2 wieder im Internals "STATE" als "Initialized" markiert.
Das Readings "state" bleibt aber weiter auf "disconnected"
Ich würde gerne helfen, aber ich habe bei mir kein OneWire an Firmata und der OneWire-Code wird von @pahenning betreut. Das gepatchte Modul 11_OWX_FRM.pm ist ein Hotifx um FHEM-Abstürze zu vermeiden. Du kannst es auch noch mal mit der unveränderten 11_OWX_FRM.pm versuchen und prüfen, ob es einen Unterschied macht. Bitte ansonsten im 1-Wire-Bereich nachsehen und ggf. da einen eigenen Thread aufmachen.

Zitat... in wie weit ist die Version der Firmata im Arduino von belang?
Kann ich meine alte 2.06 vorerst laufen lassen?
Die aktuellen FHEM-Updates für Firmata sind bzgl. der Firmata-Devices abwärtskompatibel - an den Arduinos muss nichts geändert werden.

Grüße,
Jens
Titel: Antw:Firmata Update für Firmware-Versionen ab 2.7
Beitrag von: jensb am 07 Januar 2018, 15:05:14
Hallo Stephan,

hier noch etwas mehr im Sinne von "verwirrend", nämlich die Liste aller möglichen States des FRM-Moduls:




SubAufruferState

DevIo_Expect
FRM (USB)failed

DevIo_Expect
FRM (USB)opened

DevIo_OpenDev
FRM (USB)opened

DevIo_OpenDev
FRM (USB)disconnected

DevIo_Disconnected
FRM (USB)disconnected

FRM_Start
FRM (TCP)listening

FRM_Tcp_Connection_Close
FRM (TCP)listening

FRM_SetupDevice
FRM-ClientInitialized

FRM_Init_Pin_Client
FRM-Clienterror initializing: pin X

FRM_Client_Define
FRM-Clientdefined

FRM_Client_Unassign
FRM-Clientdefined

FRM_OWX_Init
FRM-Client OWXInitialized
FRM_i2c_update_deviceI2C-Receiveactive

Die DevIo-Einflüsse können als FRM-intern betrachtet werden. Ansonsten ist der State des FRM-Moduls stark fremdbestimmt. "FRM-Client" sind alle FHEM-Module, die sich beim FRM-Modul anmelden (also z.B. 11_OWX_FRM, FRM_IN, ...).  Meiner Meinung nach sollten Aktivitäten anderer Module nicht in dieser Weise den State eines Moduls beeinflussen - aber wie gesagt - Abwärtskompatibilität hat Vorrang.

Grüße,
Jens
Titel: Antw:Firmata Update für Firmware-Versionen ab 2.7
Beitrag von: abc2006 am 08 Januar 2018, 13:05:57
Hi,
kannst du einen *richtigen* Status in einem Reading bereitstellen? dann kann ich mir das mit StateFormat ändern ...
Wenns liefe, wahrscheinlich nicht mehr so wichtig:

Allerdings hab ich grade den Arduino abgezogen, und FRM liefert mir "opened"... sicher??

Habe dann festgestellt, dass die beide auf das gleiche Device (dev/ttyUSB0) zugreifen wollen.. aber bevor ich was tun konnte, war FHEM weg (abgestürzt):

Zitat2018.01.08 13:03:35 5: Arduino setup stage 1
2018.01.08 13:03:35 5: Arduino setup stage 1
2018.01.08 13:03:36 5: Arduino setup stage 1
2018.01.08 13:03:37 5: Arduino setup stage 1
2018.01.08 13:03:37 5: Arduino setup stage 5
2018.01.08 13:03:37 3: Arduino no response from Firmata, closing DevIo
2018.01.08 13:03:37 5: Arduino setup stage 4
2018.01.08 13:03:38 5: Cmd: >save<
2018.01.08 13:03:38 5: Starting notify loop for global, 1 event(s), first is SAVE
2018.01.08 13:03:38 5: End notify loop for global
2018.01.08 13:03:39 1: OWX_Init called for bus OWio3 with interface state opened, now going for detect
2018.01.08 13:03:39 1: OWX_SER::Query OWio3: Sending out0xc1
2018.01.08 13:03:39 5: SW: c1
2018.01.08 13:03:39 4: OWX_SER::Query OWio3: 1 of 1 bytes in first attempt and state opened
2018.01.08 13:03:39 1: OWX_SER::Query OWio3: Sending out0x17 0x45 0x5b 0x0f 0x91
2018.01.08 13:03:39 5: SW: 17455b0f91
2018.01.08 13:03:39 4: OWX_SER::Query OWio3: 5 of 5 bytes in first attempt and state opened
2018.01.08 13:03:39 1: OWX_SER::Detect 1-Wire bus OWio3: interface not found, answer was 0x17 0x41 0xab 0x20 0xfc
2018.01.08 13:03:39 1: OWX_SER::Query OWio3: Sending out0x17 0x45 0x5b 0x0f 0x91
2018.01.08 13:03:39 5: SW: 17455b0f91
2018.01.08 13:03:39 4: OWX_SER::Query OWio3: 5 of 5 bytes in first attempt and state opened
2018.01.08 13:03:39 1: OWX_SER::Detect 1-Wire bus OWio3: interface not found, answer was 0x17 0x41 0xab 0x20 0xfc
2018.01.08 13:03:39 1: OWX_SER::Query OWio3: Sending out0x17 0x45 0x5b 0x0f 0x91
2018.01.08 13:03:39 5: SW: 17455b0f91
2018.01.08 13:03:39 4: OWX_SER::Query OWio3: 5 of 5 bytes in first attempt and state opened
2018.01.08 13:03:39 1: OWX_SER::Detect 1-Wire bus OWio3: interface not found, answer was 0x17 0x41 0xab 0x20 0xfc
2018.01.08 13:03:39 1: OWX_SER::Query OWio3: Sending out0x17 0x45 0x5b 0x0f 0x91
2018.01.08 13:03:39 5: SW: 17455b0f91
2018.01.08 13:03:39 4: OWX_SER::Query OWio3: 5 of 5 bytes in first attempt and state opened
2018.01.08 13:03:39 1: OWX_SER::Detect 1-Wire bus OWio3: interface not found, answer was 0x17 0x41 0xab 0x20 0xfc
2018.01.08 13:03:39 1: OWX_SER::Detect 1-Wire bus OWio3: interface not detected, answer was 0x17 0x41 0xab 0x20 0xfc
2018.01.08 13:03:39 4: OWX_Init: Detection failed
2018.01.08 13:03:39 1: Cannot init /dev/ttyUSB0, ignoring it (OWio3)
2018.01.08 13:03:42 5: Cmd: >{ReadingsVal("OWio3","reopen","")}<
2018.01.08 13:03:42 5: Cmd: >{AttrVal("OWio3","room","")}<
2018.01.08 13:03:46 5: Cmd: >get OWio3 devices<
2018.01.08 13:03:46 1: OWX_SER::Query OWio3: Sending out0xe3 0xc5
2018.01.08 13:03:46 5: SW: e3c5
OWio3, Arduino is not connected at ./FHEM/10_FRM.pm line 822.


Titel: Antw:Firmata Update für Firmware-Versionen ab 2.7
Beitrag von: jensb am 08 Januar 2018, 21:38:48
@abc2006

Zitat... kannst du einen *richtigen* Status in einem Reading bereitstellen?
Meinst du damit einen "reinen" Status der Verbindung zum Firmata-Device? Wäre wünschenswert, aber das ist nicht mal eben und es geht wahrscheinlich auch ohne Änderung:

ZitatAllerdings hab ich grade den Arduino abgezogen, und FRM liefert mir "opened"... sicher??
Auf den ersten Blick nicht, aber wenn ich mir den Logauszug ansehe, müsste folgendes mit deinem State passiert sein: 1. opened (USB-connect), 2. disconnected (Arduino no response from Firmata, closing DevIo). Macht der Arduino einen Reset, dann kommt als nächstes wieder "opened". "opened" bedeutet nur, dass eine Verbindung zwischen FHEM und dem USB-Device exisitert und hat nichts mit der Verbindung zum Firmata-Device zu tun. Was fehlt ist State "Initialized" bzw. Setup Stage 3. Dein Arduino scheint sich gar nicht zu melden (keine Version empfangen, es fehlt Setup Stage 2) und Setup Stage 1 wird mehrere Sekunden lang wiederholt, bis zum Timeout. Wenn du ein Log für das State-Reading des FRM-Device anlegst, kannst du das wahrscheinlich besser nachvollziehen. Warum sich dein Firmata-Device nicht meldet, kann man so nicht feststellen. Häng es mit USB an die Arduino IDE und schau dir nach dem Reset an, was der Serielle Monitor ausgibt. Normal wäre 1. Protokoll-Version 2. Firmware-Version, beides wird vom Firmata-Device nach dem Reset unaufgefordert gesendet.

ZitatOWio3, Arduino is not connected at ./FHEM/10_FRM.pm line 822
Ein Absturz an dieser Stelle ist für mich nicht nachvollziehbar. OWX ruft FRM nicht mehr direkt auf und die von mir gepatchte 11_OWX_FRM.pm sichert den Aufruf von FRM_Client_FirmataDevice ab, der in Zeile 822 steht und den Absturz verursacht hat. Verwendest du vielleicht das alte OWX? Wenn ja, dann sieh dir bitte diesen (https://forum.fhem.de/index.php/topic,81815.msg744073.html#msg744073) und diesen (https://forum.fhem.de/index.php/topic,81815.msg744192.html#msg744192) Post an.

Grüße,
Jens
Titel: Antw:Firmata Update für Firmware-Versionen ab 2.7
Beitrag von: abc2006 am 08 Januar 2018, 22:15:17
Zitat@abc2006
Meinst du damit einen "reinen" Status der Verbindung zum Firmata-Device? Wäre wünschenswert, aber das ist nicht mal eben und es geht wahrscheinlich auch ohne Änderung:

Okay, ich hatte eine grobe Tabelle, wollte aber keinen so engen Rahmen vorgeben/fordern. Hier dann nochmal:
Reading FRM_USB Inhalt: failed|opened|disconnected
Reading FRM_TCP inhalt: failed|connected|disconnected|timeout
Reading FRM-Client: initialized|error|defined|failed
Reading Connected OWX OWio1|OWio2,OWio3
Reading Connected FRM_AD Analogpin1|Analogpin2 usw
oder so ähnlich.

ZitatNormal wäre 1. Protokoll-Version 2. Firmware-Version, beides wird vom Firmata-Device nach dem Reset unaufgefordert gesendet.

Serieller Monitor:
siehe Bild. Kann ich daraus schon schließen, dass da was nicht stimmt?

ZitatVerwendest du vielleicht das alte OWX? Wenn ja, dann sieh dir bitte
Meinst du das 11_OWX_FRM?

Nein, habe die 11_OWX_FRM.pm heruntergeladen. Allerdings muss ich zugeben, dass da evtl ein Fehler passiert sein könnte. Ich muss zugeben, dass ich in diesem ganzen Versions_wirrwar mehr als einmal den überblick verloren habe (falls ich ihn jemals hatte). Wäre es möglich, dem FRM.pm eine Versionsnummer zu geben (so wie z.B. OWX)?

define OWio2 OWX FIRMATA:2

So sieht meine Definition aus, seit ich angefangen habe, mit Firmata herumzuprobieren.

Titel: Antw:Firmata Update für Firmware-Versionen ab 2.7
Beitrag von: jensb am 08 Januar 2018, 23:16:05
@abc2006

Dein Vorschlag für die States ist plausibel, aber im Detail leider so nicht umsetzbar. Werde es trotzdem auf die langfristige ToDo-Liste setzten.

Der Output auf dem Seriellen Monitor sieht gut aus. Mit ein bisschen Fantasie kannst du deinen Firmata-Projektnamen lesen. Da kommen also Daten. Vermutlich hat dein Konfigurationsproblem mit der doppelten Schnittstellenzuweisung dafür gesorgt, dass die Daten nicht beim FRM-Device ankommen. Also Konfiguration anpassen und nochmal versuchen. Solange das Grundlegende nicht funktioniert, solltest du deine Konfiguration nach Möglichkeit erst einmal abspecken. Legt doch einfach noch ein FRM-Device an und setzt solange beim vorhandenen die Schnittstelle auf "none". Geht alles gut, zeigt dein neues FRM-Device anschließend STATE=Initialized.

Bzgl. OWX ist wichtig, dass alles aus einem Guss ist. Es reicht nicht, nur die 11_OWX_FRM.pm herunterzuladen. Fast jedes FHEM Modul hat bereits eine Versionsnummer. Tippe mal "version" in dein FHEM ein und sieh dir die Spalte "Rev" an. Da müsste u.a. stehen:
Wenn die Revs bei dir kleiner sind, dann mache zuerst ein FHEM-Update und nimm anschließend die gepatchte 11_OWX_FRM.pm.

Grüße,
Jens
Titel: Antw:Firmata Update für Firmware-Versionen ab 2.7
Beitrag von: Maista am 08 Januar 2018, 23:37:02
@abc2006
Auf der offiziellen Firmata Homepage gibt's Testsoftware für Firmata.
Die war glaub Ich in Java geschrieben und ist mit einer GUI. Via USB am PC
Kann man damit unabhängig von FHEM testen.
Damit können die IO-PORTS gesetzt oder eingelesen werden.
In den Anfängen habe ich damit getestet ob das überhaupt funktioniert.

@jensb
Funktioniert immer noch alles!
13 OWX Devices an 5 Pins. Zum Teil Original DS oder Nachbauten von TM3D.

Gruss
Gerd
Titel: Antw:Firmata Update für Firmware-Versionen ab 2.7
Beitrag von: abc2006 am 09 Januar 2018, 01:50:03
Hi,


00_OWX.pm         15392 2017-11-05 06:46:46Z phenning
11_OWX_FRM.pm     15392 2017-11-05 06:46:46Z phenning
10_FRM.pm         15794 2018-01-05 19:14:58Z jensb




-rw-r--r-- 1 root root 17721 Jan  9 00:29 /root/11_OWX_FRM.pm
-rw-r--r-- 1 fhem dialout 17721 Jan  7 12:36 /opt/fhem/FHEM/11_OWX_FRM.pm
root@hzfhem:~# diff /root/11_OWX_FRM.pm /opt/fhem/FHEM/11_OWX_FRM.pm
root@hzfhem:~#

scheinen gleich zu sein, also alles so wie es sein soll. oder?

Dann kommts jetzt auf die Firmata-Versionen an.
Ich habe keine Ahnung, wie ich die auseinanderhalte. Also probier ich es anhand der Datei
arduino-1.8.5/libraries/ConfigurableFirmataXXX/src/ConfigurableFirmata.h

Dort steht drin:

Bei der Version, die ich nach https://forum.fhem.de/index.php/topic,44525.msg380238.html#msg380238 (https://forum.fhem.de/index.php/topic,44525.msg380238.html#msg380238) aus dem Github geholt hab, vor .. November '15? als 2.06:

FIRMATA_MAJOR_VERSION 2
FIRMATA_MINOR_VERSION 7
FIRMATA_BUGFIX_VERSION 0

in der aktuellen (2.10) steht drin :
FIRMATA_PROTOCOL_MAJOR_VERSION  2
FIRMATA_PROTOCOL_MINOR_VERSION  6
FIRMATA_PROTOCOL_BUGFIX_VERSION  0

FIRMATA_FIRMWARE_MAJOR_VERSION  2
FIRMATA_FIRMWARE_MINOR_VERSION  10
FIRMATA_FIRMWARE_BUGFIX_VERSION  0
Bin ich da richtig mit der Übereinstimmung, dass die 2.06 die alt-kompatible ist?

Dann kommt da jetzt der WIKI-Artikel ins Spiel.
der sagt:
ZitatDie aktuelle Arduino-IDE bringt zwar schon eine Version der StandardFirmata mit, diese enthält aber noch keine Unterstützung für OneWire. Diese findet man im eigenen Fork. Den kompletten Branch kann man sich auch bequem als zip-Archiv herunterladen

so. Der "eigene Fork" ist der link auf Version 2.10. also falsch. in der Zip-Datei ist auch die 2.10 drin.
Dann kommt der nächste Abschnitt:
Zitatie in dem Verzeichnis befindlichen Dateien 'Firmata.h', 'Firmata.cpp' und 'Boards.h' müssen durch die im arduino-configurable.zip-file enthaltenen Versionen ersetzt werden. Am besten kopiert man einfach den gesamten Inhalt des Ordners 'arduino-configurable' in das 'libraries/Firmata'-Verzeichnis (mitsamt des Unterordners 'examples').

So. Woher bekomm ich jetzt die arduino-configurable.zip? Ich hab im Download-Verzeichnis eine heruntergeladen, und zwar von
https://codeload.github.com/firmata/arduino/zip/configurable

Weiss aber nicht mehr, woher ich diesen Link hatte.
Und die soll ich jetzt über die Dateien des Firmata 2.06 drüberkopieren. Aber ist das bei 2.10 auch notwendig?
An der Stelle bin ich ein bisschen am Ende meines Lateins.
Aber halt, da sind ja dann auch noch die Dateien, die bei FHEM mit ausgeliefert werden:
/opt/fhem/FHEM/lib/Device/Firmata/Base.pm
/opt/fhem/FHEM/lib/Device/Firmata/Changes
/opt/fhem/FHEM/lib/Device/Firmata/Constants.pm
/opt/fhem/FHEM/lib/Device/Firmata/Error.pm
/opt/fhem/FHEM/lib/Device/Firmata/Language.pm
/opt/fhem/FHEM/lib/Device/Firmata/license.txt
/opt/fhem/FHEM/lib/Device/Firmata/Platform.pm
/opt/fhem/FHEM/lib/Device/Firmata/Protocol.pm
/opt/fhem/FHEM/lib/Device/Firmata/README


Sind die zu *allen* Firmata-Versionen kompatibel?
Das sind doch die Dateien, an denen du nichts ändern wolltest, weil die von Firmata mit entwickelt werden, oder?



So, BTT: ich hab jetzt laufen: FHEM wie oben beschrieben, plus einen Arduino mit Firmata 2.06, ausgecheckt wie oben im Post beschrieben. Puh, ob ich da jetzt was drüberkopiert hab ... gute Frage..
diff sagt: ich habs *nicht* drüberkopiert.

FHEM sagt dann folgendes:

list OWio3:

Internals:
   ALARMED    0
   ASYNCHRONOUS 0
   DEF        Arduino:9
   DeviceName Arduino:9
   FRM_OWX_CORRELATIONID 0
   HWDEVICE   Arduino
   INITDONE   0
   INTERFACE  firmata
   IODev      Arduino
   NAME       OWio3
   NEXT_OPEN  1515454515
   NR         22
   PARTIAL   
   PIN        9
   PRESENT    1
   ROM_ID     FF
   STATE      disconnected
   TYPE       OWX
   interval   300
   timeout    2
   version    7.05
   DEVHASH:
     OWX_1D_22DC84000003 1D.22DC84000003.51
     OWX_1D_23DC84000003 1D.23DC84000003.66
     OWio3      Busmaster
   DEVS:
     1D.22DC84000003.51
     1D.23DC84000003.66
   FRM_OWX_REPLIES:
   READINGS:
     2018-01-09 00:34:15   state           disconnected
Attributes:
   verbose    5


get OWio3 devices
OWX_Discover: 1-Wire devices found on bus OWio3
1D.22DC84000003      DS2423         OWX_1D_22DC84000003
1D.23DC84000003      DS2423         OWX_1D_23DC84000003


Internals:
   ASYNC      0
   DEF        DS2423 22DC84000003
   ERRCOUNT   0
   INTERVAL   15
   IODev      OWio3
   NAME       OWX_1D_22DC84000003
   NOTIFYDEV  global
   NR         23
   NTFY_ORDER 50-OWX_1D_22DC84000003
   OW_FAMILY  1D
   OW_ID      22DC84000003
   PRESENT    0
   ROM_ID     1D.22DC84000003.51
   STATE      initialized 2018-01-09 00:33:48
   TYPE       OWCOUNT
   DATA:
     memory     
   READINGS:
     2018-01-09 00:33:02   A               978501
     2018-01-09 00:33:02   A_rate          0
     2018-01-09 00:33:02   B               0
     2018-01-09 00:33:02   B_rate          0
     2018-01-09 00:33:02   memory         
     2018-01-09 00:33:48   state           initialized
   owg_midnight:
     
     
   owg_str:
     
     
   owg_val:
     
     
Attributes:
   IODev      OWio3
   interval   15
   model      DS2423
   room       OWX
   stateFormat {sprintf("%s %s",ReadingsVal($name,"state",0),ReadingsTimestamp($name,"state",0))}

Allerdings sagt ein
get  OWX_1D_22DC84000003  counters
immer noch
OWCOUNT: get OWX_1D_22DC84000003 counters failed, reason: OWCOUNT: Could not get values from device OWX_1D_22DC84000003, reason: 1D.22DC84000003.51 not accessible in reading page 14OWCOUNT: Could not get values from device OWX_1D_22DC84000003, reason: 1D.22DC84000003.51 not accessible in reading page 15


Wenn du mir bestätigst, dass (die aktuelle oder irgend eine andere Konfiguration die *empfohlene* ist, dann setze ich das gerne so um, dokumentiere das im Wiki und wenn der Fehler dann noch besteht, ist es ein OWX/OneWire-Problem?

Ich löte morgen mal den zweiten Counter, nur um sicherzugehen, dass ich den nicht aus versehen irgendwie zerschossen hab. Wenn das was ändern sollte, meld ich mich asap. (ist übrigens auch ein Nachbau vom Tobias)

Danke erstmal,
Grüße,
Stephan
Titel: Antw:Firmata Update für Firmware-Versionen ab 2.7
Beitrag von: abc2006 am 09 Januar 2018, 10:43:36
Also der DS18B20 liefert (bei bisher gleichem Setup) ebenfalls einen Fehler:

OWTHERM: Could not get values from device OWX_28_16C19F050000, return was OWTHERM: OWX_28_16C19F050000 not accessible
Firmata 2.06


Grüße,
Stephan
Titel: Antw:Firmata Update für Firmware-Versionen ab 2.7
Beitrag von: abc2006 am 09 Januar 2018, 10:48:33
Kannst du mir mal Hilfe zur Selbsthilfe geben?


2018.01.09 10:45:44 5: Arduino FRM:<e01902
2018.01.09 10:45:45 5: Arduino FRM:<e01902
2018.01.09 10:45:46 5: Arduino FRM:<e01902
2018.01.09 10:45:47 5: Arduino FRM:<e01a02
2018.01.09 10:45:48 1: OWX_Complex called while interface OWio3 disconnected
2018.01.09 10:45:48 1: OWX_Complex called while interface OWio3 disconnected
2018.01.09 10:45:48 1: OWX_Complex called while interface OWio3 disconnected
2018.01.09 10:45:48 1: OWX_Complex called while interface OWio3 disconnected
2018.01.09 10:45:48 5: Arduino FRM:<e01a02
2018.01.09 10:45:49 5: Arduino FRM:<e01a02
2018.01.09 10:45:50 5: Arduino FRM:<e01a02
2018.01.09 10:45:51 5: Arduino FRM:<e01a02
2018.01.09 10:45:52 5: Arduino FRM:<e01b02
2018.01.09 10:45:53 5: Arduino FRM:<e01b02
2018.01.09 10:45:54 5: Arduino FRM:<e01a02
2018.01.09 10:45:55 5: Arduino FRM:<e01a02
2018.01.09 10:45:56 5: Arduino FRM:<e01b02
2018.01.09 10:45:57 5: Arduino FRM:<e01b02
2018.01.09 10:45:58 5: Arduino FRM:<e01b02
2018.01.09 10:45:59 5: Arduino FRM:<e01b02
2018.01.09 10:46:00 5: Arduino FRM:<e01b02
2018.01.09 10:46:01 5: Arduino FRM:<e01b02
2018.01.09 10:46:02 5: Arduino FRM:<e01b02
2018.01.09 10:46:03 1: OWX_Complex called while interface OWio3 disconnected
2018.01.09 10:46:03 1: OWX_Complex called while interface OWio3 disconnected
2018.01.09 10:46:03 5: Arduino FRM:<e01a02
2018.01.09 10:46:04 5: Arduino FRM:<e01a02
2018.01.09 10:46:05 5: Arduino FRM:<e01a02
2018.01.09 10:46:06 5: Arduino FRM:<e01a02
2018.01.09 10:46:07 5: Arduino FRM:<e01902
2018.01.09 10:46:08 5: Arduino FRM:<e01902
2018.01.09 10:46:09 5: Arduino FRM:<e01a02
2018.01.09 10:46:10 5: Arduino FRM:<e01a02
2018.01.09 10:46:11 5: Arduino FRM:<e01902
2018.01.09 10:46:12 5: Arduino FRM:<e01a02
2018.01.09 10:46:13 5: Arduino FRM:<e01a02
2018.01.09 10:46:14 5: Arduino FRM:<e01a02
2018.01.09 10:46:15 1: OWX_FRM::Ready function called for bus OWio3. STATE=disconnected
2018.01.09 10:46:15 5: Arduino FRM:<e01a02
2018.01.09 10:46:16 5: Arduino FRM:<e01a02
2018.01.09 10:46:17 5: Arduino FRM:<e01a02
2018.01.09 10:46:18 1: OWX_Complex called while interface OWio3 disconnected
2018.01.09 10:46:18 1: OWX_Complex called while interface OWio3 disconnected


Wie kann ich herausfinden, was das "e01a02" bedeutet?
Ich vermute, das sind die NAchrichten, die FRM an den Arduino sendet, aber keine Antwort (Prefixed mit SW>) erhält. Stimmt das?
Titel: Antw:Firmata Update für Firmware-Versionen ab 2.7
Beitrag von: Maista am 09 Januar 2018, 22:58:57
Moin.
Funktioniert immer noch.
Bei Gelegenheit versuche ich Async.

Gruß
Gerd
Titel: Antw:Firmata Update für Firmware-Versionen ab 2.7
Beitrag von: jensb am 09 Januar 2018, 23:00:52
@abc2006

ZitatKannst du mir mal Hilfe zur Selbsthilfe geben?
Würde ich gerne, aber das kann ich nicht in dem Umfang den du brauchst - ich kenne mich mit OneWire aktuell nicht gut genug aus, um Ratschläge geben zu können. Ein Teil deiner Fragen gehört klar in den OneWire-Bereich. Bezüglich Firmata (ohne OneWire) ist folgendes relevant: Mit der aktuellen Firmata-Version kannst du (fast) beliebige Firmata und ConfigurableFirmata Versionen verwenden, also auch solche mit Versionsnummern, die größer sind als 2.6 (das war bisher die Obergrenze, wenn man keine Anpassungen an FHEM oder Firmata machen wollte). Daher empfiehlt es sich nun, die aktuellste verfügbare Firmata-Version zu verwenden. Ein Teil der Wiki-Hinweise sind deshalb seit Jahrewechsel überarbeitungsbedürftig . Wenn du also OneWire einsetzten willst, dann greife momentan zu ConfigurableFirmata 2.10. Für einen schnellen Verbindungstest empfehle ich trotzdem zuerst den Sketch StandardFirmataEthernet. Die Netzwerkparameter einstellen und nach ein paar Minuten solltest du zumindest eine Verbindung mit FHEM haben (State=Initialized).

ZitatWie kann ich herausfinden, was das "e01a02" bedeutet?
Siehe hier (https://github.com/firmata/protocol/blob/master/protocol.md) und hier (https://github.com/firmata/protocol/blob/master/onewire.md). Du empfängst (FRM:<) jede Sekunde einen analogen Messwert von Pin 0 (E0). Dein Firmata-Device reagiert also und scheinbar ist ein FRM_AD-Device für Pin 0 konfiguriert, was merkwürdig ist, da du ja OneWire machen willst. Ohne das Logging vor dem 1. "e01a02" kann man aber nicht herausfinden, woran das liegen könnte.

Grüße,
Jens
Titel: Antw:Firmata Update für Firmware-Versionen ab 2.7
Beitrag von: jensb am 09 Januar 2018, 23:03:57
@Maista

ZitatBei Gelegenheit versuche ich Async.
Das soll auch gehen, aber klemmt scheinbar auf dem OWX-Seite manchmal. Weiter vorn im Thread war eine Info dazu von @dirigent.

Grüße,
Jens
Titel: Antw:Firmata Update für Firmware-Versionen ab 2.7
Beitrag von: abc2006 am 10 Januar 2018, 11:37:48
ZitatDu empfängst (FRM:<) jede Sekunde einen analogen Messwert von Pin 0 (E0). Dein Firmata-Device reagiert also und scheinbar ist ein FRM_AD-Device für Pin 0 konfiguriert, was merkwürdig ist, da du ja OneWire machen willst. Ohne das Logging vor dem 1. "e01a02" kann man aber nicht herausfinden, woran das liegen könnte.
Ja. Ich hoffe, ich hatte oben schon erwähnt, dass ich (zusätzlich) einen AnalogIn definiert hatte, um feststellen zu können, ob ich Firmata-Verbindung habe.

ZitatSiehe hier und hier
Klasse,
danke, das hab ich schon ein paar mal gesucht. Dann beschäftige ich mich mal weiter damit und linke meine Frage mal zum one-Wire-Forum...

Danke erstmal für die Hilfe. Wenn ich noch was testen soll (grad hab ich den Aufbau noch da) sag Bescheid.
Grüße,
stephan
Titel: Antw:Firmata Update für Firmware-Versionen ab 2.7
Beitrag von: Achim am 10 Januar 2018, 15:21:18
Hallo Jens,

ich bin gestern dazugekommen, mir nochmals deine neuen Versionen anzusehen/einzuspielen. Ich habe auch deine geänderte OWX_FRM installiert. Nach Löschen der Firmata Parameter im fhem.save und Neustart funktioniert es jetzt bei mir. Auch die Inputs gehen.
In meiner Signatur steht was alles an dem Firmata Arduino hängt.

Viele Grüße
Achim
Titel: Antw:Firmata Update für Firmware-Versionen ab 2.7
Beitrag von: jensb am 10 Januar 2018, 21:21:44
@Achim
Danke für die Rückmeldung. Wenn du Teile der fhem.save löschen musstest, damit es funktioniert, hast du das gleiche Problem mit OWX_FRM wie einige andere. Das wird sich vermutlich hin- und wieder melden, bis die Ursache gefunden ist. In diesem  (https://forum.fhem.de/index.php/topic,81104.msg745736.html#msg745736)Thread wird momentan danach gesucht.

Grüße,
Jens
Titel: Antw:Firmata Update für Firmware-Versionen ab 2.7
Beitrag von: abc2006 am 11 Januar 2018, 15:24:52
Hi,
hab jetzt mal die aktuellste Firmware (firmatabuilder.com) drauf.
Danke für die beiden Links, jetzt kann ich endlich mal verstehen, was da passiert.


#########################################################################################
##### EDIT: alle Fragen hinfällig ####################
###########################################################################
Dadurch ergibt sich auch die erste Frage:
Zitat2018.01.11 15:12:34 5: Arduino FRM:>f90000
2018.01.11 15:12:34 5: SW: f90000
2018.01.11 15:12:34 5: Arduino FRM:>f079f7
2018.01.11 15:12:34 5: SW: f079f7
2018.01.11 15:12:35 5: Arduino setup stage 1
2018.01.11 15:12:35 5: Arduino setup stage 1
2018.01.11 15:12:36 5: Arduino FRM:<f90206f079020a4f0057004600690072006d006100740061006200750069006c
2018.01.11 15:12:36 5: Arduino setup stage 1
2018.01.11 15:12:36 5: Arduino FRM:<00640065007200320030003100380030003100310031002e0069006e006f00f7
2018.01.11 15:12:36 5: Arduino setup stage 1
2018.01.11 15:12:36 3: Arduino Firmata Firmware Version: OWFirmatabuilder20180111.ino V_2_10 (using Protocol Version: V_2_06)
2018.01.11 15:12:36 5: Arduino FRM:>f069f7
2018.01.11 15:12:36 5: SW: f069f7
2018.01.11 15:12:36 5: Arduino FRM:>f06bf7
2018.01.11 15:12:36 5: SW: f06bf7
2018.01.11 15:12:36 5: Arduino FRM:<f90206f079020a4f0057004600690072006d006100740061006200750069006c
2018.01.11 15:12:36 5: Arduino setup stage 2
2018.01.11 15:12:36 5: Arduino FRM:<00640065007200320030003100380030003100310031002e0069006e006f00f7
2018.01.11 15:12:36 5: Arduino setup stage 2
2018.01.11 15:12:36 5: Arduino FRM:<f07155006e00680061006e0064006c0065006400200073007900730065007800
2018.01.11 15:12:36 5: Arduino setup stage 2
2018.01.11 15:12:36 5: Arduino FRM:<200063006f006d006d0061006e006400f7f06c7f7f07017f07017f07017f0701
2018.01.11 15:12:36 3: received String_data: Unhandled sysex command


Wenn ich das richtig dekodiert habe, fragt FHEM den Arduino nach einem analogen mapping

2018.01.11 15:12:36 5: Arduino FRM:>f069f7
f0 - Start SYSEX
69 - ANALOG_MAPPING_QUERY # warum fragt der hier nach analogen..
f7 - End SYSEX

Welches vom Arduino (verständlicherweise) mit HÄ? beantwortet wird:
2018.01.11 15:12:36 5: Arduino FRM:<f07155006e00680061006e0064006c0065006400200073007900730065007800


Hab zwar noch ca. tausend weitere Fragen, aber vielleicht beantworten sich durch diese Info einige davon;)
Grüße,
stephan

edit: Tippfehler

edit: ich verlänger das gleich mal ein bisschen:
auf die 6b(CAPABILITY_QUERY) antwortet der Arduino:

f06c7f7f07017f07017f07017f07017f07017f07017f07017f07017f07017f07017f07017f07017f07017f07017f07017f07017f07017f07017f7f7ff7


Was übersetzt heisst:
Alle meine Pins (ausser 1,2,20,21 und 22) können OneWire (07) und DigitalOut(01)

So, hab jetzt grade mal ne halbe stunde gesucht, wie die Pins zugeordnet sind. Dachte, ich hätte das mal irgendwo gesehen.
Ich gehe mal davon aus, Pin 1 = TX, Pin 2= RX, Pin  3 = D2 [...] Pin 14 = D13 ( also eigentlich der letzte OW-Pin), Pin 15= A0, Pin 16 = A1 [...] Pin 22 = A7; anders macht es nicht viel Sinn.


Arduino FRM:>f07a6807f7
f0
7a setze analoge polling zeit
68 auf .. 1896 ms
07
f7



Meine Haupt-Frage: Warum fragt FRM nach Analog-Werten, wenns doch anscheinend erkannt hat, dass der Arduino gar kein Analog unterstützt ( kein Internal "analog-pins" und warum zeigt Firmata keine Digital-Pins an, wenn doch der Arduino (fälschlicherweise?!?) behauptet, er könne es?

Hab ich was übersehen? [/s]

#########################################################################################
##### /EDIT: alle Fragen hinfällig ####################
###########################################################################

Nach einem reboot des Raspberry läufts. ab-, und anstecken des Arduino, als auch ein "shutdown restart" sind NICHT ausreichend!


Grüße,
Stephan

Titel: Antw:Firmata Update für Firmware-Versionen ab 2.7
Beitrag von: jensb am 11 Januar 2018, 23:02:50
Hallo Stephan,

ZitatMeine Haupt-Frage: Warum fragt FRM nach Analog-Werten, wenns doch anscheinend erkannt hat, dass der Arduino gar kein Analog unterstützt ( kein Internal "analog-pins"
Die bisherigen FRM-Versionen wollten auch dann die Verbindung zum Firmata-Device herstellen, wenn irgendetwas bei den Capability-Abfragen schief geht und haben es der Anwender-Konfiguration überlassen, ob es plausibel war oder nicht. Es gab bis zum Update Anwender von FRM, die keine "xxx_pins/resolution" Internals angezeigt bekommen haben (siehe z.B. hier (https://forum.fhem.de/index.php/topic,81815.msg743075.html#msg743075)). Natürlich könnte man das bei der neuen Version verriegeln. Auch beim Setzen des Sampling-Intervals könnte automatisch eine 0 senden, wenn weder analoge Eingangspins bzw. I2C-Pins gemeldet werden. Das ist aber alles Kategorie "nice to have" und könnte einige experimentierfreudige Anwender stören. Das nächste geplante Update von FRM_IN wird übrigens tatsächlich von den Capabilities Gebrauch machen, um den Pin-Mode PULLUP abwärtskompatibel unterstützen zu können.

Zitat... und warum zeigt Firmata keine Digital-Pins an, wenn doch der Arduino (fälschlicherweise?!?) behauptet, er könne es?
Woraus schließt du "behauptet"? Aus "f06c7f7f07017f07017f07017f0701..."? Ja, diese Antwort ist auf den 1. Blick merkwürdig, bedeutet aber Pin 0: -, Pin 1: -, Pin 2: OneWire, Pin 3: OneWire, ... - da ist nichts mit INPUT oder OUTPUT dabei. "0701" bedeutet nicht OneWire + INPUT sondern OneWire mit resolution=1.

ZitatNach einem reboot des Raspberry läufts. ab-, und anstecken des Arduino, als auch ein "shutdown restart" sind NICHT ausreichend!
Schön dass es läuft, aber trotzdem ein bisschen merkwürdig. FHEM selbst kennt keinen Unterschied zwischem Neustart (/etc/init.d/fhem stop/start bzw. "shutdown restart") und Booten. Wenn man wirklich booten muss, um ein Problem zu lösen, dann liegt die Ursache im Bereich Betriebssystem (z.B. I/O-Recourcen) oder Hardware (z.B. Netzteil Spannungsstabilität).

Grüße,
Jens
Titel: Antw:Firmata Update für Firmware-Versionen ab 2.7
Beitrag von: abc2006 am 11 Januar 2018, 23:16:26
Zitat"0701" bedeutet nicht OneWire + INPUT sondern OneWire mit resolution=1.
Zitat

Ahhh... das war mein Fehler. Dann hat der Arduino ja alles richtig gemacht.
Hab ich im Protokoll tatsächlich übersehen.
Zitatdie Verbindung zum Firmata-Device herstellen[...]Anwender-Konfiguration
Wenn ich das richtig verstehe, glaubte Firmata, dass ich noch einen Analogen PIN abfragen wollte?
Meine Anwender-Konfiguration sagt aber nichts (mehr) von analog. Spätestens nachdem ich FHEM neu gestartet habe, müssten alle Überreste des Analogen Inputs weg sein (dachte ich zumindest).
Gut, legen wir das solange zu den Akten, bis mir einfällt, wie ich das reproduzieren könnte.


ZitatWenn man wirklich booten muss, um ein Problem zu lösen, dann liegt die Ursache im Bereich Betriebssystem (z.B. I/O-Recourcen) oder Hardware (z.B. Netzteil Spannungsstabilität).
Stimme ich dir zu, und ich vermute auch eher das Betriebssystem (/dev/ttyUSBx) als Ursache.
Allerdings weiss das Betriebssystem nix von FRM und AnalogPins...
Und ich erwarte von meinem Raspian, dass beim entfernen des USB-Steckers von einem Gerät sämtliche Kernelmodule entladen werden, bis es das nächste mal verbunden wird...

Grüße,
Stephan






Titel: Antw:Firmata Update für Firmware-Versionen ab 2.7
Beitrag von: JensS am 15 Januar 2018, 16:41:27
Hallo Jens,

heute konnte ich das Reading ausmachen, welches die OWX-Abfrage blockt.
Wenn man set OWX reopen ausführt, wird das OWX-Device in den STATE disconnected versetzt und ändert dies nicht mehr.
Sobald setreading OWX state Initialized ausgeführt wird, klappt es wieder mit der Abfrage.

Gruß Jens
Titel: Antw:Firmata Update für Firmware-Versionen ab 2.7
Beitrag von: jensb am 15 Januar 2018, 20:45:10
Hallo Jens,

hattest du "reopen" manuell ausgelöst?

Habe mir das in 00_OWX.pm angesehen: bei "reopen" wird DevIo_OpenDev aufgerufen. Aber diese Funktion ist nur für "echte" Betriebssystem-Devices wie serielle Schnittstellen gedacht und funktioniert nicht mit FHEM-internen IODev-Schnittstellen wie FRM. DevIo_OpenDev verändert die Verknüpfung zwischen dem FHEM-Kern und dem OWX-Device und setzt den State von OWX auf "disconnected", da DevIo_OpenDev kein OS-Device öffnen kann. OWX prüft periodisch mit OWX_Init auf neue Devices, aber wenn der State auf "disconnected" steht natürlich nicht mehr.

Um das zu verhindern müsste pah Anpassungen an OWX und den anderen OWX-Modulen machen, indem der "reopen"-Ablauf schnittstellenspezifisch umgesetzt wird. Bei FRM sollte ein "reinit" reichen.

Aktuell ist es das Beste, die Finger von "reopen" zu lassen, wenn man OWX mit FRM verwendet.

Grüße,
Jens
Titel: Antw:Firmata Update für Firmware-Versionen ab 2.7
Beitrag von: JensS am 15 Januar 2018, 22:01:43
Ja, das hatte ich manuell ausgelöst, in der Annahme, dass passiert, was da steht.   ???
Wenn man dann get OWX devices aufruft, werden diese angezeigt - seltsam...

Gruß Jens
Titel: Antw:Firmata Update für Firmware-Versionen ab 2.7
Beitrag von: jensb am 15 Januar 2018, 22:34:04
ZitatWenn man dann get OWX devices aufruft, werden diese angezeigt - seltsam...
Zum Glück nachvollziehbar, denn diese Funktion ist in OWX einerseits schnittstellenspezifisch umgesetzt und prüft andererseits nicht den State.

Grüße,
Jens
Titel: Antw:Firmata Update für Firmware-Versionen ab 2.7
Beitrag von: JensS am 18 Januar 2018, 19:55:16
Hallo Jens,

wollte nur mal den aktuellen Stand mitteilen:
FRM und 11_OWX_FRM.pm laufen in allen Installationen tadellos.

Gruß Jens
Titel: Antw:Firmata Update für Firmware-Versionen ab 2.7
Beitrag von: JensS am 21 Januar 2018, 10:35:04
Hallo Jens,

das Update vom 17.01. habe ich verpasst. Mein voriger Beitrag bezieht sich also auf die Vorversion. Nun habe ich die neue Version eingespielt und bekomme folgenden Fehler:2018.01.21 10:28:12 5: Cmd: >define in1 FRM_IN 3<
2018.01.21 10:28:12 5: Loading ./FHEM/20_FRM_IN.pm
2018.01.21 10:28:12 1: reload: Error:Modul 20_FRM_IN deactivated:
Bareword "PIN_PULLUP" not allowed while "strict subs" in use at ./FHEM/20_FRM_IN.pm line 97, <$fh> line 39.
2018.01.21 10:28:12 0: Bareword "PIN_PULLUP" not allowed while "strict subs" in use at ./FHEM/20_FRM_IN.pm line 97, <$fh> line 39.

Gruß Jens
Titel: Antw:Firmata Update für Firmware-Versionen ab 2.7
Beitrag von: jensb am 21 Januar 2018, 10:56:08
Hallo Jens,

vermute, dass du perl-firmata noch nicht aktualisiert hast (z.B. mit FHEM Update). Die neue Version des Moduls FRM_IN braucht auch die neue Version 0.64 von perl-firmata, da es die Konstante "PIN_PULLUP" bis 0.63 nicht gegeben hat. Habe gerade die Abhängigkeitshinweise im 1. Post korrigiert.

Grüße,
Jens
Titel: Antw:Firmata Update für Firmware-Versionen ab 2.7
Beitrag von: JensS am 21 Januar 2018, 11:09:44
Danke und sorry, ich hatte perl-firmata noch in exlude_from-update drin.
Peinlich :-[

Jetzt läuft FRM_IN.

Gruß Jens
Titel: Antw:Firmata Update für Firmware-Versionen ab 2.7
Beitrag von: JensS am 24 Januar 2018, 21:58:56
Hallo Jens,

ich nutze lediglich FRM-IN, -OUT, -LCD, -i2c und OWX. Habe heute pah's 11_OWX_FRM.pm{qx(wget -O /opt/fhem/FHEM/11_OWX_FRM.pm https://svn.fhem.de/trac/export/HEAD/trunk/fhem/FHEM/11_OWX_FRM.pm)}
shutdown restart
installiert. Alle Module laufen gut. Bisher keine Fehler.

Gruß Jens
Titel: Antw:Firmata Update für Firmware-Versionen ab 2.7
Beitrag von: jensb am 26 Januar 2018, 18:39:19
Hallo Jens,

das ist doch schon ein ganze Menge "lediglich" und noch besser, dass es alles zusammen funktioniert. Dann werde ich das neue FRM_IN am Wochenende einchecken.

Danke für die Rückmeldung und Grüße,
Jens
Titel: Antw:Firmata Update für Firmware-Versionen ab 2.7
Beitrag von: JensS am 02 Februar 2018, 23:13:16
Hallo Jens,

wieder eine Woche rum - und immer noch keine Fehler.  ;D Hin und wieder gab's ja wohl noch offizielle Updates.
Die Umsetzung der Anzeige der Treiberversion per Internal ist eine gute Idee. :)

Gruß Jens
Titel: Antw:Firmata Update für Firmware-Versionen ab 2.7
Beitrag von: jensb am 03 Februar 2018, 19:28:11
Hallo Jens,

danke für die Rückmeldung und die Beteiligung an den Tests. Aktuell sind keine weiteren Updates geplant.

Die Anzeige der Treiberversion als Internal war für mich der beste Kompromiss. Es gab den Wunsch, den Dateien von perl-firmata auch FHEM-Versionsnummern zu geben. Das passt aber nicht, da der Treiber zwar mit FHEM ausgeliefert wird, aber selbst ein Perl-Modul unter eigener Lizenz ist (siehe Device::Firmata (https://metacpan.org/search?q=Device%3A%3AFirmata) im CPAN) und schon eine Versionsnummer hat - nur halt nach Perl-Modul-Regeln und nicht nach FHEM-Modul-Regeln. Ein kleines Problem bleibt: ich habe noch keine Möglichkeit gefunden, die neue Treiberversion im CPAN zu aktualisieren. Die meisten wird das aber nicht stören, denn die FHEM-Version ist ja auf dem neusten Stand.

Grüße,
Jens
Titel: Antw:Firmata Update für Firmware-Versionen ab 2.7
Beitrag von: JensS am 03 Februar 2018, 21:15:08
Ist ntruchsess gar nicht mehr erreichbar bzw. aktiv? Du könntest einen PAUSE-Admin bitten, dir die notwendigen Rechte zu geben.
https://www.cpan.org/misc/cpan-faq.html#How_adopt_module (https://www.cpan.org/misc/cpan-faq.html#How_adopt_module)

Gruß Jens
Titel: Antw:Firmata Update für Firmware-Versionen ab 2.7
Beitrag von: jensb am 03 Februar 2018, 21:43:56
Ich habe mehr als 1 Jahr lang versucht, über PM, GitHub und über Rudi Kontakt mit Norbert aufzunehmen, aber leider ohne Erfolg. Es ist wirklich nicht mein Ding, die Projekte anderer Entwickler ohne explizites Einverständnis auch nur vorübergehend zu übernehmen. Das im Rahmen von FHEM nach Rücksprache und nach langer Wartezeit zu machen, ist die eine Sache. Auf GitHub war es nicht das Problem, da ich da ohnehin seit 2016 Co-Author bin. CPAN ist da noch mal was anderes. Das mit den PAUSE-Regeln hatte ich mir auch schon angesehen - werde es mir noch mal durch den Kopf gehen lassen.

Als nächstes kommen erst mal die Firmata-Artikel in der FHEM-Wiki dran. Hilfe ist willkommen.

Grüße,
Jens
Titel: Antw:Firmata Update für Firmware-Versionen ab 2.7
Beitrag von: JensS am 03 Februar 2018, 23:02:09
Ich könnte versuchen bei Arduino mit OneWireFirmata behilflich zu sein. Oder ist das pah's Gebiet?

Gruß Jens
Titel: Antw:Firmata Update für Firmware-Versionen ab 2.7
Beitrag von: jensb am 03 Februar 2018, 23:12:17
ZitatOder ist das pah's Gebiet?
Gute Frage. Habe mich bisher noch nicht mit den Regeln für die Wiki auseinander gesetzt, das steht noch auf der ToDo-Liste.

Grüße,
Jens
Titel: Antw:Firmata Update für Firmware-Versionen ab 2.7
Beitrag von: JensS am 15 Februar 2018, 11:39:59
Hallo Jens,
mir ist ein seltsamer Fehler aufgefallen, welcher eventuell durch die 10_FRM.pm verursacht wird.
https://forum.fhem.de/index.php/topic,82020.msg767035.html#msg767035 (https://forum.fhem.de/index.php/topic,82020.msg767035.html#msg767035)

Gruß Jens
Titel: Antw:Firmata Update für Firmware-Versionen ab 2.7
Beitrag von: jensb am 15 Februar 2018, 20:19:56
Hallo Jens,

siehe dazu meine Bewertung (https://forum.fhem.de/index.php/topic,82020.msg767273.html#msg767273) im gleichen Thread.

Grüße,
Jens
Titel: Antw:Firmata Update für Firmware-Versionen ab 2.7
Beitrag von: JensS am 15 Februar 2018, 20:58:54
Danke, sowas dachte ich mir schon.
Gruß Jens
Titel: Antw:Firmata Update für Firmware-Versionen ab 2.7
Beitrag von: JensS am 16 Februar 2018, 09:38:57
Hallo Jens,

heute früh um 4:13 Uhr hat ein Arduino Nano mit W5100 seinen Dienst eingestellt.
Als letztes sendete er die Temperatur eines i2c Typ SHT21.
error
I2C: Too few bytes received
2018-02-16 04:13:42

Internals:
   I2C_Address 64
   IODev      Saeule
   NAME       Saeule_SHT21
   NR         117
   STATE      1.6*C - 119.0 %
   Saeule_SENDSTAT Too few bytes received
   TYPE       I2C_SHT21
   READINGS:
     2018-02-16 04:08:40   humidity        119.0
     2018-02-16 04:08:40   state           T: 1.6 H: 119.0
     2018-02-16 04:13:41   temperature     1.6
Attributes:
   IODev      Saeule
   event-on-change-reading temperature:0.3,humidity:0.7
   poll_interval 5
   room       FIRMATA,Garten,Sensoren
   stateFormat temperature*C - humidity %
   verbose    0

Internals:
   CONNECTS   1
   DEF        3030 global
   DRIVER_VERSION 0.63
   DeviceName 3030
   FD         39
   NAME       Saeule
   NOTIFYDEV  global
   NR         26
   NTFY_ORDER 50-Saeule
   PORT       3030
   STATE      Initialized
   TYPE       FRM
   firmware   ConfigurableFirmata-nano.ino.ino
   firmware_version V_2_06
   i2c_pins   18,19
   input_pins 2,3,4,5,6,7,8,9,14,15,16,17,18,19
   onewire_pins 2,3,4,5,6,7,8,9,14,15,16,17,18,19
   output_pins 2,3,4,5,6,7,8,9,14,15,16,17,18,19
   protocol_version V_2_06
   pwm_pins   3,5,6,9
   pwm_resolutions 3:8,5:8,6:8,9:8
   READINGS:
     2018-02-16 04:13:42   error           I2C: Too few bytes received
     2018-02-15 12:17:10   state           Initialized
   SERIAL:
   SocketDevice:
     BUF       
     DeviceName 3030
     FD         38
     NAME       Saeule_192.168.xxx.xxx_49153
     NR         368
     PEER       192.168.xxx.xxx
     PORT       49153
     SNAME      Saeule
     SSL       
     STATE      Connected
     TEMPORARY  1
     TYPE       FRM
Attributes:
   i2c-config 30000
   room       FIRMATA
   verbose    0


Eine Skizze der Schaltung. Da der DS2482 unter OWX nicht mehr unterstützt wurde, habe 1-wire direkt am Arduino verdrahtet. Als Ethernetshield nutze ich einen W5100.
https://forum.fhem.de/index.php/topic,31715.msg242704.html#msg242704 (https://forum.fhem.de/index.php/topic,31715.msg242704.html#msg242704)

Gruß Jens
Titel: Antw:Firmata Update für Firmware-Versionen ab 2.7
Beitrag von: jensb am 16 Februar 2018, 22:00:43
Hallo Jens,

aus deinen Infos einen Zusammenhang abzuleiten fällt mir schwer. Habe den Eindruck, dass die Ursache nichts mit FHEM oder Firmata zu tun hat. Vor allem wenn der Hänger nur selten auftritt, ist es nicht leicht, das weiter einzugrenzen. Du hast relativ viele Funktionen auf einen Nano konzentriert. Das läuft nicht immer dauerstabil, u.a. weil der dynamische Speicher knapp ist.

Meine Lösung dafür: (A) Kühlkörper auf den W5100 - vor allem wenn er so warm wird, dass man ihn nicht mehr anfassen möchte - und (B) Optiboot Bootloader installieren und den Watchdog aktivieren, in dem du folgendes in den Firmata-Sketch einbaust:

#if defined(ARDUINO_ARCH_AVR)
// Watchdog, only for AVR-based boards
// Note: Some board (e.g. Pro Mini ATmega328 5V 16MHz) do not have a bootlader with WDT support
// causing the board to get stuck until power cycled after the WDT has been triggered. You
// can update the default bootloader, e.g. using optiboot.
#include <avr/wdt.h>
#endif
...
void setup()
{
...
#ifdef _AVR_WDT_H_
  // enable watchdog
  // Note: Some board do not support a WDT timeout of 8 seconds. You should choose
  // the maximum supported timeout of your board from the header file avr/wdt.h.
  wdt_enable(WDTO_8S);
#endif
}
...
void loop()
{
#ifdef _AVR_WDT_H_
  /* reset watchdog */
  wdt_reset();
#endif
...


Bleibt der Adruino dann mal hängen, merkt man es meist gar nicht mehr. Diese Lösung ist aber nur für sehr sporadische Ausfälle sinnvoll.

Mit ein paar weiteren Zeilen Code kann man auch den Soft-Reset von Firmata in einen Hard-Reset für den Arduino und einen Soft-Reset für den W5100 umwandeln:

void systemResetCallback()
{
  isResetting = true;
 
#ifdef _AVR_WDT_H_
  // shorten watchdog timeout
  wdt_enable(WDTO_500MS);
#ifdef  W5100_H_INCLUDED 
  // try to reset Ethernet chip (takes about 350 ms)
  W5100.init();
#endif 
  // perform hardware reset by triggering watchdog
  delay(1000);
#else
  // software reset
  initDefaultState();
#endif 

  isResetting = false;
}


Grüße,
Jens
Titel: Antw:Firmata Update für Firmware-Versionen ab 2.7
Beitrag von: JensS am 16 Februar 2018, 22:14:49
Danke für die umfangreiche Unterstützung. :)
Es tritt alle paar Monate auf.
Bisher hatte ich der Stromkreis per Relais unterbrochen aber das ist ja um Längen besser.

Gruß Jens
Titel: Antw:Firmata Update für Firmware-Versionen ab 2.7
Beitrag von: jensb am 16 Februar 2018, 22:32:01
Hallo Jens,

probier erst mal aus, ob es in deinem Fall auch hilft. Wenn du den Sketch erweitert hast, kannst du testen, ob du den Bootloader überhaupt aktualisieren musst. Dazu ein Sleep von mindestens 10 Sekunden in die Hauptschleife einbauen. Wenn der Arduino sich dann resettet und hängen bleibt, bleibt dir nichts anderes übrig. Bist du einmal in diesem Zustand, kommst du aber auch nicht mehr so leicht heraus, da die Firmware ja immer wieder resettet und wieder hängen bleibt. Die kurze Zwischenzeit musst du nutzten, um in den Upload-Modus zu kommen - dann kannst du wieder einen Sketch einspielen, der die Finger vom Watchdog lässt.

Um den Optiboot-Bootloader (https://github.com/Optiboot/optiboot) zu programmieren, brauchst du einen 2. Arduino (oder einen ISP). Es gibt diverse Tutorials zu diesem Thema.

Grüße,
Jens
Titel: Antw:Firmata Update für Firmware-Versionen ab 2.7
Beitrag von: ntruchsess am 26 Februar 2018, 10:26:02
Zitat von: jensb am 03 Februar 2018, 21:43:56Ich habe mehr als 1 Jahr lang versucht, über PM, GitHub und über Rudi Kontakt mit Norbert aufzunehmen, aber leider ohne Erfolg. Es ist wirklich nicht mein Ding, die Projekte anderer Entwickler ohne explizites Einverständnis auch nur vorübergehend zu übernehmen.

Hallo Jens,

ich hab tatsächlich schon gefühlt ewig nicht mehr hier reingeschaut, mein FHEM läuft seit Jahren unverändert und stabil und ich arbeite mittlerweile an ganz anderen Baustellen. Meine FHEM-module (und auch aller andere Code den ich im vergangenen Jahrzehnt open source veröffendlich habe) darf gerne jeder, der sich berufen fühlt weiterentwickeln, dafür brauchts meine explizite Erlaubnis nicht, dafür sind die jeweiligen Lizenzen ja offen genug.

Das perl-firmate-repository auf github kann ich Dir gerne ganz übertragen, wenn Du magst. Wie man auf CPAN die modul-ownship überträgt weiß ich leider nicht, würde mich aber auch freuen, wenn das jemand wie z.B. Du aktiv weiterführt.

Gruß,

Norbert
Titel: Antw:Firmata Update für Firmware-Versionen ab 2.7
Beitrag von: jensb am 27 Februar 2018, 19:50:23
Hallo Nobert,

freut mich wirklich sehr, dass du dich meldest. Hatte lange gehofft, dass das doch passiert.

Hatte mich zunächst nur mit Hinweisen in den Foren beteiligt, da die Probleme mit den aktuellen Firmata-Versionen zugenommen hatten. Als dann Hinweise zum Selbstpatchen der Firmata-Module in der FHEM-Wiki auftauchten, habe ich das nicht mehr mit ansehen können und meine eigenen Patches als Updates zur Verfügung gestellt. Danke, dass du damit kein Problem hast.

Eine Übertragung der Repositories ist mir nicht wichtig. Auf GitHub hattest du mich ja schon zum Mitentwickler gemacht, so dass ich Updates einchecken kann, wenn das erforderlich ist. Wie das mit CPAN funktioniert steht hier (https://www.cpan.org/modules/04pause.html#add-comaintainer). Ich werde mich als Perl-Entwickler registrieren und dann könntest du mich als Co-Maintainer eintragen. Die Details können wir per PM klären.

Viel Erfolg bei deinen "anderen Baustellen",
Jens
Titel: Antw:Firmata Update für Firmware-Versionen ab 2.7
Beitrag von: ntruchsess am 01 März 2018, 17:04:47
prima. Freut mich wirklich, dass Du das weiterführst! Gib Bescheid, wenn Du auf CPAN registriert bist, dann trage ich Dich da als Co-maintainer ein.

Gruß,

Norbert
Titel: Antw:Firmata Update für Firmware-Versionen ab 2.7
Beitrag von: ffdec am 14 März 2018, 21:00:03
Grad noch mal die Firmata FW auf 2.10 aktualisiert. Dennoch bleiben die Fehler, die schon sehr lange immer wieder beim Start kommen:
Wäre cool wenn wir das lösen können.

2018.03.14 20:51:31.786 1: OWX_FRM::Define warning: version 7.10 not identical to OWX version 7.08
2018.03.14 20:51:36.254 1: PERL WARNING: Use of uninitialized value in numeric comparison (<=>) at fhem.pl line 2055, <$fh> line 674.
2018.03.14 20:51:36.258 1: PERL WARNING: Use of uninitialized value in numeric comparison (<=>) at fhem.pl line 2055, <$fh> line 681.
2018.03.14 20:51:36.262 1: PERL WARNING: Use of uninitialized value in numeric comparison (<=>) at fhem.pl line 2055, <$fh> line 688.
2018.03.14 20:51:36.266 1: PERL WARNING: Use of uninitialized value in numeric comparison (<=>) at fhem.pl line 2055, <$fh> line 695.
2018.03.14 20:51:36.270 1: PERL WARNING: Use of uninitialized value in numeric comparison (<=>) at fhem.pl line 2055, <$fh> line 702.
2018.03.14 20:51:36.278 1: PERL WARNING: Use of uninitialized value in numeric comparison (<=>) at fhem.pl line 2055, <$fh> line 710.
2018.03.14 20:51:36.656 1: PERL WARNING: Use of uninitialized value in numeric comparison (<=>) at fhem.pl line 2055, <$fh> line 875.
2018.03.14 20:51:36.805 1: PERL WARNING: Use of uninitialized value in numeric comparison (<=>) at fhem.pl line 2055, <$fh> line 971.
2018.03.14 20:51:36.829 1: Including ./log/fhem.save
2018.03.14 20:51:37.054 1: Error: >OWX:6< has no TYPE, but following keys: ><
2018.03.14 20:51:37.619 1: usb create starting
2018.03.14 20:51:38.152 1: usb create end
2018.03.14 20:51:38.153 0: Featurelevel: 5.8
2018.03.14 20:51:38.154 0: Server started with 133 defined entities (fhem.pl:16403/2018-03-13 perl:5.024001 os:linux user:fhem pid:13275)
2018.03.14 20:51:39.275 1: HMLAN_Parse: LAN new condition ok
2018.03.14 20:51:42.484 1: PERL WARNING: Use of uninitialized value in concatenation (.) or string at ./FHEM/10_FRM.pm line 1051.
2018.03.14 20:51:52.991 1: OWX_Discover: 1-Wire devices found on bus DS18B20 (WWAuslauf,Ruecklauf,WWVorl,WWZP,Vorlauf)
2018.03.14 20:52:31.788 1: OWX_Init called for bus DS18B20 with interface state Initialized, now going for detect
2018.03.14 20:52:31.788 1: OWX: 1-Wire bus DS18B20: interface Firmata detected in Firm
2018.03.14 20:52:31.871 1: OWX_Discover: 1-Wire devices found on bus DS18B20 (WWAuslauf,Ruecklauf,WWVorl,WWZP,Vorlauf)


2018.03.14 20:51:37.054 1: Error: >OWX:6< has no TYPE, but following keys: >< Da kann man anstatt der Firmata irgend etwas reinschreiben. Also nicht wundern, wenn da OWX steht.
Titel: Antw:Firmata Update für Firmware-Versionen ab 2.7
Beitrag von: jensb am 14 März 2018, 22:13:56
@ffdec
Die Fehlermeldung kommt aus dem FHEM-Kern und zwar aus der Unterfunktion devspec2array. Die wird allerdings aus sehr vielen verschiedenen Abläufen heraus aufgerufen. Aufgrund des Loggings tippe ich auf das Wiederherstellen der gespeicherten Readings.

Ich kenne diese Fehlermeldung auch, hatte aber bisher nicht das Bedürfnis, der Sache nachzugehen. Werde mir das ansehen, das kann aber etwas dauern.

Grüße,
Jens
Titel: Antw:Firmata Update für Firmware-Versionen ab 2.7
Beitrag von: ffdec am 14 März 2018, 23:16:18
@jensb: Ah super, vielen Dank. Das reicht mir.
Titel: Antw:Firmata Update für Firmware-Versionen ab 2.7
Beitrag von: jensb am 17 März 2018, 13:07:09
Zwischenstand: Die von @ffdec gemeldete Warning
PERL WARNING: Use of uninitialized value in numeric comparison (<=>) at fhem.pl line 2055
hat nichts mit Firmata zu tun, siehe hier (https://forum.fhem.de/index.php/topic,85596.msg782492.html#msg782492).

Grüße,
Jens
Titel: Antw:Firmata Update für Firmware-Versionen ab 2.7
Beitrag von: jensb am 17 März 2018, 13:20:28
Das gleicht gilt für
Error: >OWX:6< has no TYPE, but following keys: ><
siehe hier (https://forum.fhem.de/index.php/topic,85596.msg782501.html#msg782501).

Grüße,
Jens
Titel: Antw:Firmata Update für Firmware-Versionen ab 2.7
Beitrag von: FhemPiUser am 25 März 2018, 17:52:25
Hallo Jens,

erstmal vielen Dank, dass Du die Wartung der Module übernommen hast und auch offen für Feature-Wünsche bist!

Ich hätte da nämlich einen Feature-Wunsch: eine Keep-Alive-Option mit Callback-Funktion.

Hintergrund:

Ich steuere meine Heizung über einen Arduino, der über Firmata über Ethernet (FRM device) an FHEM angebunden ist. Läuft an sich sehr stabil, aber ich hatte es in den letzten 3 Jahren glaube ich 2 Mal, dass FHEM bzw. der Raspberry aus irgendeinem Grund in der Nacht stehen blieb und daher morgens die Heizung nicht angeschaltet wurde. War nicht gut...

Daher wäre mein Wunsch, dass es eine Option gibt, dass FHEM bzw. das FRM device periodisch Keep-Alive-Nachrichten über Firmata Ethernet an den Arduino sendet. Wenn diese z.B. 2-3 Mal nicht mehr ankommen (z.B. weil FHEM bzw. der Raspberry ausgefallen ist), dann soll auf dem Arduino eine "Keep-Alive-Missing"-Callback-Funktion aufgerufen werden können. Diese würde in meinem Fall dann in den "Heizungs-Notfall-Modus" schalten und die Heizung anschalten. Wenn die Keep-Alive-Nachrichten wieder ankommen, würde eine "Keep-Alive-back"-Callback-Funktion aufgerufen werden, die die Heizung wieder in den Regelmodus von FHEM schaltet.

Was hälst Du davon? Wäre das möglich?

Vielen Dank
Titel: Antw:Firmata Update für Firmware-Versionen ab 2.7
Beitrag von: jensb am 25 März 2018, 18:44:18
Hallo FhemPiUser,

wenn ich dich richtig versehe, meinst du mit Keep-Alive nicht die TCP Socket Option sondern eine Art Watchdog-Telegramm. Nun, Firmata ist keine FHEM-Anwendung sondern ein standardisiertes Protokoll und eine Protokollerweiterung müsste man hier (https://github.com/firmata/protocol) beantragen und abwarten, was entschieden wird. Das wird in diesem Fall nicht nötig sein, hier reichen Arduino Bordmittel.

Mein Vorschlag: Verwende einen realen Digitalausgang ohne externe Beschaltung am Arduino und toggle ihn von FHEM aus periodisch mit "at" z.B. alle 10 Sekunden. Überwache das Toggeln in der Firmata loop, indem du den letzten Zustand und den Zeitpunkt der letzten Zustandsänderung in 2 Variablen zwischenspeicherst. Daraus kannst du deinen Notfall-Modus nach einem frei wählbaren Timeout auslösen.

In Gegenrichtung ist es fast genauso einfach. Füge in die Firmata loop folgendes ein:

  if (client.connected() && (currentMillis - pingSent) >= PING_PERIOD)
  {
    // send some data to detect loss of connection indirectly
    Firmata.sendString("ping");
    pingSent = currentMillis;
  }


definiere noch irgendwo weiter oben im Code "#define PING_PERIOD 60000 // [ms]" sowie "unsigned long pingSent = 0;" und setzte in deinem FRM-Device das Attribut "errorExclude" auf "ping". Anschließend kannst du das Reading "stringMessage" des FRM-Device überwachen. Im Gutfall sollte regelmäßig den Wert "ping" aktualisiert werden.

Für deinen Notfall-Modus könntest du "!client.connected()" zusätzlich mit auswerten.

Diese Funktionen in FHEM zu integrieren geht also nicht. Die wesentlichen Änderungen müssen in der Firmata-Firmware durchgeführt werden und das ist durchaus im Sinne des Erfinders.

Grüße,
Jens

Titel: Antw:Firmata Update für Firmware-Versionen ab 2.7
Beitrag von: FhemPiUser am 25 März 2018, 18:56:46
Hi Jens,

ok, stimmt, gute Idee mit dem toogle. Darauf bin ich nicht gekommen...

Vielen Dank!
Titel: Antw:Firmata Update für Firmware-Versionen ab 2.7
Beitrag von: FhemPiUser am 25 März 2018, 19:39:56
...falls es jemand anders benötigt anbei der Code für die keep alive Erweiterung der Arduino StandardFirmataEthernet inkl. Notfallmodus und -recovery:

Definitionen:
// KEEPALIVE START
#define KEEPALIVE_PERIOD 300000 // [ms] =5min
#define PIN_KEEPALIVE_LISTEN 6
#define PIN_SET_IN_EMERGENCY_1 7
#define PIN_SET_IN_EMERGENCY_2 8
// KEEPALIVE END


Globale Variablen:
// KEEPALIVE START
unsigned long previousKeepaliveMillis = 0;        // store the current value from millis()
int missingKeepaliveMsgs = 0;
int lastKeepalivePinState = 0;
byte keepaliveEmergencyMode = 0;
int pinState1;
int pinState2;
// KEEPALIVE END


Code hinzugefügt am Ende von loop():
 
// KEEPALIVE START
  if (lastKeepalivePinState != digitalRead(PIN_KEEPALIVE_LISTEN)) {
    previousKeepaliveMillis = currentMillis;
  lastKeepalivePinState = digitalRead(PIN_KEEPALIVE_LISTEN);
  if (keepaliveEmergencyMode > 0) {
    // leaving emergency mode
  // restore pin states
  //digitalWrite(PIN_SET_IN_EMERGENCY_1, pinState1); 
  //digitalWrite(PIN_SET_IN_EMERGENCY_2, pinState2); 
  // inform fhem about emergency mode
  keepaliveEmergencyMode = 0;
      Firmata.sendString("Keepalive: Leaving emegency mode!");
  }
  }
  if (((currentMillis - previousKeepaliveMillis) > (KEEPALIVE_PERIOD + 60000)) && (keepaliveEmergencyMode == 0)) {
  missingKeepaliveMsgs++;
    Firmata.sendString("Keepalive: Keepalive message missing.");
  }
  if (((currentMillis - previousKeepaliveMillis) > (3*KEEPALIVE_PERIOD + 60000)) && (keepaliveEmergencyMode == 0)) {
    // starting emergency mode
  // store pinstates
          pinState1 = digitalRead(PIN_SET_IN_EMERGENCY_1);
  pinState2 = digitalRead(PIN_SET_IN_EMERGENCY_2);
  keepaliveEmergencyMode = 1;
  digitalWrite(PIN_SET_IN_EMERGENCY_1, LOW);
  digitalWrite(PIN_SET_IN_EMERGENCY_2, LOW);
    Firmata.sendString("Keepalive: Starting emegency mode!");
  }
  // KEEPALIVE END


...und in fhem das periodische Setzen eines Keepalive FRM_OUT devices:

defmod Arduino_Heizung_Keepalive FRM_OUT 6
defmod at_Arduino_Heizung_Keepalive at +*00:05:00 set Arduino_Heizung_Keepalive toggle
Titel: Antw:Firmata Update für Firmware-Versionen ab 2.7
Beitrag von: jensb am 25 März 2018, 20:48:17
Wer Firmata verwendet und sich vor Fehlkonfgurationen durch den Host schützen möchte (z.B. fest verdrahteter Eingang wird unbeabsichtigt auf Ausgang gesetzt), kann noch einen Schritt weiter gehen:

void setPinModeCallback(byte pin, int mode)
{
  if (Firmata.getPinMode(pin) == PIN_MODE_IGNORE)
    return;

  // fixed digital inputs
  if (pin == MY_PULLUP_PIN && mode != PIN_MODE_PULLUP)
    return;

  // fixed digital outputs
  if (pin == MY_OUTPUT_PIN && mode != OUTPUT)
    return;

  ...
}


Will man die Hardwarekonfiguration auch nutzen, wenn nach dem Boot des Arduino noch kein Host-Connect zu Stande gekommen ist, dann hilft folgendes (immer mit obiger Fehlkonfigurationsblockade kombinieren):

void setup()
{
  ...

  initFirmata();

  // fixed digital inputs
  pinMode(PIN_TO_DIGITAL(MY_PULLUP_PIN), INPUT_PULLUP);
 
  // fixed digital outputs
  pinMode(PIN_TO_DIGITAL(MY_OUTPUT_PIN ), OUTPUT); 
  digitalWrite(PIN_TO_DIGITAL(MY_OUTPUT_PIN ), LOW); // initial state after boot/reset
}


Grüße,
Jens
Titel: Antw:Firmata Update für Firmware-Versionen ab 2.7
Beitrag von: hugo.crank am 06 August 2018, 08:37:17
Hallo,
da ich hin und wieder den leidigen Zustand habe das mir 2 Arduinos stecken bleiben hab ich bei meiner suche dieses Thema gefunden. Gehe ich richtig davon aus das ich mit der nachfolgenden Funktion "Emergencymode" den arduino dazu bewegen kann das er neustartet einen "Reset" durchführt wenn er keinee positive Rückmeldung von Fhem erhält?
Zustand ist im Moment der das der betreffende Arduino als "Online" gezeigt wird bei mir in der Fheminstanz pingbar sowie connected. aber nicht mehr ansprechbar ist da sich Fhem mit befehlen verrennt.




Zitat von: FhemPiUser am 25 März 2018, 19:39:56
...falls es jemand anders benötigt anbei der Code für die keep alive Erweiterung der Arduino StandardFirmataEthernet inkl. Notfallmodus und -recovery:

Definitionen:
// KEEPALIVE START
#define KEEPALIVE_PERIOD 300000 // [ms] =5min
#define PIN_KEEPALIVE_LISTEN 6
#define PIN_SET_IN_EMERGENCY_1 7
#define PIN_SET_IN_EMERGENCY_2 8
// KEEPALIVE END


Globale Variablen:
// KEEPALIVE START
unsigned long previousKeepaliveMillis = 0;        // store the current value from millis()
int missingKeepaliveMsgs = 0;
int lastKeepalivePinState = 0;
byte keepaliveEmergencyMode = 0;
int pinState1;
int pinState2;
// KEEPALIVE END


Code hinzugefügt am Ende von loop():
 
// KEEPALIVE START
  if (lastKeepalivePinState != digitalRead(PIN_KEEPALIVE_LISTEN)) {
    previousKeepaliveMillis = currentMillis;
  lastKeepalivePinState = digitalRead(PIN_KEEPALIVE_LISTEN);
  if (keepaliveEmergencyMode > 0) {
    // leaving emergency mode
  // restore pin states
  //digitalWrite(PIN_SET_IN_EMERGENCY_1, pinState1); 
  //digitalWrite(PIN_SET_IN_EMERGENCY_2, pinState2); 
  // inform fhem about emergency mode
  keepaliveEmergencyMode = 0;
      Firmata.sendString("Keepalive: Leaving emegency mode!");
  }
  }
  if (((currentMillis - previousKeepaliveMillis) > (KEEPALIVE_PERIOD + 60000)) && (keepaliveEmergencyMode == 0)) {
  missingKeepaliveMsgs++;
    Firmata.sendString("Keepalive: Keepalive message missing.");
  }
  if (((currentMillis - previousKeepaliveMillis) > (3*KEEPALIVE_PERIOD + 60000)) && (keepaliveEmergencyMode == 0)) {
    // starting emergency mode
  // store pinstates
          pinState1 = digitalRead(PIN_SET_IN_EMERGENCY_1);
  pinState2 = digitalRead(PIN_SET_IN_EMERGENCY_2);
  keepaliveEmergencyMode = 1;
  digitalWrite(PIN_SET_IN_EMERGENCY_1, LOW);
  digitalWrite(PIN_SET_IN_EMERGENCY_2, LOW);
    Firmata.sendString("Keepalive: Starting emegency mode!");
  }
  // KEEPALIVE END


...und in fhem das periodische Setzen eines Keepalive FRM_OUT devices:

defmod Arduino_Heizung_Keepalive FRM_OUT 6
defmod at_Arduino_Heizung_Keepalive at +*00:05:00 set Arduino_Heizung_Keepalive toggle

Titel: Antw:Firmata Update für Firmware-Versionen ab 2.7
Beitrag von: FhemPiUser am 06 August 2018, 20:56:52
hallo hugo.crank,

im code wird im emergency mode ein digitalwrite ausgeführt (Ausgang auf low, bedeutet bei mir heizung an). das könntest du aber durch deinen code ersetzen, z.b zum reset des arduino...

Titel: Antw:Firmata Update für Firmware-Versionen ab 2.7
Beitrag von: hugo.crank am 07 August 2018, 08:10:57
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.
Titel: Antw:Firmata Update für Firmware-Versionen ab 2.7
Beitrag von: slawekking am 11 September 2018, 21:17:17
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
                     
Titel: Antw:Firmata Update für Firmware-Versionen ab 2.7
Beitrag von: JensS am 16 September 2018, 10:44:53
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 (https://wiki.fhem.de/wiki/Trick_der_Woche#CUL_.26_CO_.C3.BCber_Serial_ID-einbinden)

Gruß Jens
Titel: Antw:Firmata Update für Firmware-Versionen ab 2.7
Beitrag von: slawekking am 16 September 2018, 14:26:23
Hallo Jens,

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

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

Gruss

Christoph
Titel: Antw:Firmata Update für Firmware-Versionen ab 2.7
Beitrag von: JensS am 16 September 2018, 22:29:39
Hängen beide Arduinos direkt am Pi oder per USB-Hub?https://www.raspberrypi.org/documentation/hardware/raspberrypi/usb/README.md (https://www.raspberrypi.org/documentation/hardware/raspberrypi/usb/README.md)
Titel: Antw:Firmata Update für Firmware-Versionen ab 2.7
Beitrag von: slawekking am 16 September 2018, 22:53:47
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.
Titel: FRM_IN mit korrekten Zeitstempeln pro PIN
Beitrag von: Joe9 am 04 Oktober 2018, 14:00:30
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.
Titel: Antw:Firmata Update für Firmware-Versionen ab 2.7
Beitrag von: jensb am 04 Oktober 2018, 20:01:32
@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
Titel: FRM_IN mit korrekten Zeitstempeln pro PIN
Beitrag von: Joe9 am 04 Oktober 2018, 21:19:44
Zitat
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
Titel: Antw:Firmata Update für Firmware-Versionen ab 2.7
Beitrag von: jensb am 04 Oktober 2018, 21:44:59
@Joe9
ZitatWenn 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.

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

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

ZitatEine 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
Titel: Antw:Firmata Update für Firmware-Versionen ab 2.7
Beitrag von: matthias soll am 31 Oktober 2018, 19:47:52
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?
Titel: Antw:Firmata Update für Firmware-Versionen ab 2.7
Beitrag von: jensb am 31 Oktober 2018, 20:45:36
@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 (https://forum.fhem.de/index.php/board,26.0.html) 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
Titel: Antw:Firmata Update für Firmware-Versionen ab 2.7
Beitrag von: matthias soll am 01 November 2018, 06:05:31
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
Titel: Antw:FRM_IN mit korrekten Zeitstempeln pro PIN
Beitrag von: jensb am 04 November 2018, 22:26:50
@Joe9 und alle, die sich für den Reading-Zeitstempel von FRM_IN interessieren

Joe9 hatte hier (https://forum.fhem.de/index.php/topic,81815.msg842557.html#msg842557) 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
Titel: Antw:Firmata Update für Firmware-Versionen ab 2.7
Beitrag von: jensb am 09 Dezember 2018, 12:19:47
Die neue Version von FRM_IN ist ab 10.12.2018 per FHEM Update verfügbar.

Grüße,
Jens
Titel: Antw:Firmata Update für Firmware-Versionen ab 2.7
Beitrag von: jensb am 27 Dezember 2018, 12:26:03
Ich hatte mich schon mehrmals gefragt, was das Modul FRM_I2C macht. Aus der Modulhilfe bin ich nicht so recht schlau geworden und habe es einfach mal ausprobiert.

Die Funktion ist ähnlich wie die des Linux-Kommandozeilentool i2cdump und kann daher z.B. zur Diagnose verwendet werden. Allerdings ist der Output der aktuellen Version mehr verwirrend als hilfreich, da er nicht initialisiert wird und sich beim Start erst mit zufälligen Werten füllt, bis die endgültige Byteanzahl erreicht ist.

Auf GitHub  (https://github.com/jnsbyr/fhem/tree/master/FHEM)gibt es nun eine neue Version von FRM und FRM_I2C, die den Output von FRM_I2C zunächst mit 256 Nullen initialisiert. Auch die Modulhilfe von FRM_I2C wurde aktualisiert.

Prinzipiell könnte man in das Modul auch eine I2C-Write-Funktion integrieren, wenn dafür Bedarf besteht.

Grüße,
Jens
Titel: Antw:Firmata Update für Firmware-Versionen ab 2.7
Beitrag von: JensS am 27 Dezember 2018, 15:36:19
Ist das dann so, dass man dann I2C-Geräte direkt (ohne spez. FRM-Modul) ansprechen kann (z.B. SSD1306)?
Das fände ich super und ich könnte endlich mein FRM_LCD in den verdienten Ruhestand schicken.

Gruß Jens
Titel: Antw:Firmata Update für Firmware-Versionen ab 2.7
Beitrag von: jensb am 27 Dezember 2018, 19:04:14
ZitatIst das dann so, dass man dann I2C-Geräte direkt (ohne spez. FRM-Modul) ansprechen kann (z.B. SSD1306)?
Ja, aber ob das praktikabel ist, hängt davon ab, wie komplex der erforderliche Ablauf ist.

Speziell das SSD1306 ist kein Text-Display. Du müsstest also zuerst den Text zu Pixeln rendern und die dann Byteweise übertragen. Das ist kein Job für DOIF & Co. Auf 'nem Arduino gibt es dafür spezielle Bibliotheken. Die in Perl nachzubauen dürfte nicht trivial sein, aber vielleicht hast du ja schon was passendes.

Werde das Write bei Gelegenheit einbauen, dann kannst du ja 'mal einen Test machen.

Grüße,
Jens
Titel: Antw:Firmata Update für Firmware-Versionen ab 2.7
Beitrag von: jensb am 29 Dezember 2018, 20:34:25
Habe FRM_I2C auf Anregung von @dirigent um eine Schreibfunktion erweitert. Man kann nun auch das periodische Lesen deaktivieren und mit get und set Register(-gruppen) einzeln lesen und schreiben. Bitte berücksichtigen, dass man über Firmata in FHEM nur nicht-blockierend lesen kann, d.h. man sendet eine Leseanforderung und die Daten kommen erst etwas später, sind also nicht schon da, wenn das get Kommando fertig ist - man kann den Datenempfang aber z.B. mit einem notify einsammeln. Außerdem kann man bei Firmata ein paar Lese- und Schreibanforderung gemischt hintereinander absetzten ohne auf eine Rückmeldung zu warten, da Firmata die I2C-Kommandos puffert.

Zur Installation bitte FRM und FRM_I2C gleichzeitig von GitHub (https://github.com/jnsbyr/fhem/tree/master/FHEM) aktualisieren.

Im dem Zusammenhang wurde auch die I2C Fehlerbehandlung von FRM überarbeitet. Wenn man mit Firmata auf den I2C-Bus zuzugreift und das Firmata-Device nicht mit FHEM verbunden ist, gibt es nun eine passende Fehlerrückmeldung über das Internal SENDSTAT. Das kann je nach I2C-Modul z.B. beim FHEM Neustart auftreten. Getestet habe ich es mit I2C_BMP180 und I2C_TSL2561, beide kommen ohne Moduländerung damit zurecht.

Bei der Anpassung der I2C Fehlerbehandlung ist mir ein Bug im Modul GPUtils.pm aufgefallen:
sub GP_Catch($) {
  my $exception = shift;
  if ($exception) {
    $exception =~ /^(.*)( at.*FHEM.*)$/;
    return $1;
  }
  return undef;
}

Ziel dieser sub ist es meiner Ansicht nach, den Text vor dem Perl-Stacktrack abzugreifen. Die 1. Matchgruppe $1 ist aber aktuell immer leer, da das Ende wohl nicht passt (nach mehreren Newlines steht am Ende des Stacktrace meist etwas wie "... called at fhem.pl line 728"). Entfernt man das "$" aus dem Match, klappt es wieder. GP_Catch wird von einer Reihe von Modulen verwendet (FRM, MYSENSORS_DEVICE, OWX_FRM, OWxxxxx), deshalb möchte ich das nicht einfach ändern.

Rückmeldungen sind erwünscht.

Grüße,
Jens
Titel: Antw:Firmata Update für Firmware-Versionen ab 2.7
Beitrag von: JensS am 29 Dezember 2018, 21:12:08
Danke dir Jens, ich probiere es nächste Woche mit einem DS2482-100 und einem SSD1306 aus.

Gruß Jens
Titel: Antw:Firmata Update für Firmware-Versionen ab 2.7
Beitrag von: jensb am 26 September 2020, 21:59:29
Hallo allerseits,

dieser Thread ist schon lange beendet.

Es ist aber nicht ganz einfach, möglichst viele "Betroffene" zu erreichen, deshalb hier der Hinweis, dass es Firmata-Neuigkeiten (https://forum.fhem.de/index.php/topic,114552.msg1087982.html#msg1087982) gibt, die alle Anwender betreffen.

Grüße,
Jens