[Firmata] - Update - Device::Firmata wird aus FHEM entfernt

Begonnen von jensb, 26 September 2020, 21:39:45

Vorheriges Thema - Nächstes Thema

jensb

Ein wichtiges Update der 10/20_FRM-Module steht zum Testen bereit mit folgenden Schwerpunkten:


  • Entfernen des Perl-Moduls Device::Firmata aus FHEM (Betrifft auch Nutzer von OWX_FRM und OWX_ASYNC)
  • Zuverlässigkeit von Firmata-Devices mit Netzwerkschnittstelle
  • Standardisierung der 10/20_FRM-Module

Es gibt noch weitere Detailverbesserungen, die u.a. auf den Rückmeldungen einiger Anwender basieren. Mehr Infos dazu finden sich am Ende des Beitrags.

Die Beta-Versionen der neuen FHEM-Modulversionen sind beigefügt und finden sich auch auf GitHub.

Mir fehlt z.T. die Hardware, um alle überarbeiteten Module auch funktionell zu testen (FRM_RGB, FRM_ROTENC, FRM_SERVO, FRM_STEPPER). Daher bitte ich um eure Rückmeldung, vor allem auch dann, wenn es bei euch funktioniert. Wer die Beta-Versionen ausprobiert, sollte vorher auf jeden Fall seine aktuellen Modulversionen sichern, um bei Bedarf schnell wieder zurückstellen zu können.


zu 1.) Entfernen des Perl-Moduls Device::Firmata aus FHEM

FHEM und die FHEM-Module stehen unter der Lizenz GPLv2. Die FHEM-Distribution enthält aber momentan noch Module mit anderen Lizenzen. Die sollen nun schrittweise aus der FHEM-Distribution entfernt werden und zu diesen Modulen zählt das Perl-Modul Device::Firmata. Das Entfernen bedeutet nicht, dass diese Module nicht mehr mit FHEM verwendet werden können, sondern nur, dass sie nicht mehr automatisch mit FHEM installiert und aktualisiert werden. Für Perl-Module gibt es für das Installieren und Aktualisieren CPAN, Details hierzu findet man in der FHEM-Wiki.

Da das Perl-Modul Device::Firmata bisher automatisch installiert wurde, sind die darauf aufbauenden FHEM-Module nicht darauf vorbereitet, dass es nicht installiert sein könnte. In Folge stürzt FHEM ab, wenn das Perl-Modul Device::Firmata aus dem FHEM-Unterverzeichnis gelöscht wird oder wenn man bei einer FHEM-Neuinstallation ein define für ein Firmata-Modul durchführt. Damit das nicht passiert, gibt es ein Update für das Modul 10_FRM.pm und alle 20_FRM_XXXXX.pm Module. Die neuen Modulversionen verhindern den Absturz von FHEM und zeigen eine Fehlermeldung, wenn Device::Firmata nicht installiert ist oder eine veraltete Version hat.

Für das Modul 11_OWX_FRM.pm ist eine ähnliche Änderung in Arbeit, aber aktuell noch nicht verfügbar.

Unklar ist, ob es auch entsprechnde Anpassungen bei 00_OWX_ASYNC.pm geben wird, da es schon länger nicht mehr aktualiert wurde, denn auch dieses FHEM-Modul kann mit Firmata genutzt werden. Sofern man aber Device::Firmata selbst installiert, kann es weiter verwendet werden.


Ich empfehle allen Firmata-Anwendern schon jetzt die FHEM-Version 0.64 von Device::Firmata zu entfernen und auf die Perl-Version 0.69 umzusteigen, denn die FHEM-Version ist bereits seit längerem veraltet und enthält bekannte und behobene Fehler.


Die Umstellung ist im Normalfall schnell erledigt. Auf einem Linux-Derivat verwendet man dazu die Kommandozeile:


sudo cpan install Device::Firmata
cd <FHEM-Installationsverzeichnis>/FHEM/lib/Device
optional: cp -a Firmata* <Sicherungsziel>
sudo rm -r Firmata*
sudo service fhem restart


Außerderm sollte man noch "FHEM/lib/Device/Firmata.*" zum FHEM-Attribut "exclude_from_update" von "global" hinzufügen, damit die veraltete Version von Device::Firmata nicht wieder installiert wird.


zu 2.) Zuverlässigkeit von Firmata-Devices mit Netzwerkschnittstelle

Wenn man mit einem Smarthome-System nicht nur experimentiert sondern damit Komfortfunktionen bereit stellt, dann möchte man sich auch darauf verlassen können. Trotzdem kann natürlich eine Störung in einem Sensor oder Aktor auftreten. Um so ärgerlicher ist es, wenn das länger unbemerkt bleibt. Die neue Version von FRM verbessert daher die Verbindungsüberwachung für Firmata-Devices, die per TCP/IP angebunden sind, also per LAN oder WLAN. Ein Verbindungsabbruch wird nun zuverlässiger erkannt und ändert den State des FRM-Devices. Je nach Implementierung in den jeweiligen FRM-Client-Modulen kann man so nicht akualisierte Messwerte und fehlgeschlagene Aktionen erkennen.

Außderdem gibt es ein neues Attribut "ping-interval". Wenn man es setzt sendet FRM periodisch den String "ping" an das Firmata-Device. Das sorgt für eine beschleunigte Verbindungsabbrucherkennung für den Anwendungsfall, wo FHEM dem Firmata-Device normalerweise nichts sendet.

Hat man den Anwendungsfall, dass das Firmata-Device im Normalfall nichts an FHEM sendet, sollte man in seinen Firmata-Sketch etwas entsprechendes einbauen und das Attribut "errorExclude" von "FRM" auf "ping" setzen, z.B.:


#define PING_PERIOD 20000 // [ms]

unsigned long pingSent = 0;
char message[8];

void loop()
{
  ...

  unsigned long currentMillis = millis(); 
  if (stream.status() == ESTABLISHED && (currentMillis - pingSent) >= PING_PERIOD)
  {
    // send some data to detect loss of connection indirectly
    sprintf(message, "ping");   
    Firmata.sendString(message);
    pingSent = currentMillis;
  }

  ...
}


Zusätzlich gibt es das neue Attribut "receiveTimeout". Wenn man es setzt trennt FRM die Verbindung, wenn innerhalb des konfigurierten Timeouts keine Daten vom Firmata-Device empfangen werden.

Kombiniert man das periodische Senden und Empfangen von Daten mit dem Empfangstimeout kann man Funktionsfehler und Netzwerkstörungen sicher erkennen.

Da man Firmata auch als I2C-Brücke verwenden kann, gibt es im gleichen Zusammenhang noch eine Erweiterung für I2C. Besteht beim Schreiben auf den I2C-Bus keine Netzwerkverbindung zum Firmata-Device wird nun ein Fehler zurückgemeldet, der vom jeweiligen I2C-Modul ausgewertet werden kann.



zu 3.) Standardisierung der 10/20_FRM-Module

Beim Testen der Änderungen von Punkt 1 sind viel kleine Unterschiede bei der Bedienung, des Fehlerverhaltens und des Loggings bei den 10/20_FRM_XXXXX-Modulen aufgefallen. Hier zumindest eine Teilstandardisierung umzusetzen, hat sich als relativ zeitaufwendig herausgestellt. Ziel war es u.a., dass die in FHEMWEB angezeigten Parameterfelder hinter get und set den tatsächlichen Anforderungen des jeweiligen Kommandos entsprechen, dass bei Ablauffehlern während get, set oder bei Attributänderung das STATE-Internal auf eine Fehlertext gesetzt wird, dass der Aufbau der Fehlertexte für den gleichen Ablauf gleich ist und dass bei get und set zumindest die Anzahl der Übergabeparameter überprüft werden.



Hier die Liste der wesentlichen Änderungen:

FRM

  • TCP/WiFi connected Firmata devices: TCP socket close detection improved, new attribute "receiveTimeout"
  • new attribute "ping-interval"
  • I2C: set inernal I2C SENDSTAT to error if sub I2CWrtFn is called while Firmata device is not connected and propagate error by synchronously calling sub I2CRecFn
  • added command "set sendString"
  • detect if Device::Firmata is installed and has required version, set FRM internal DRIVER_STATUS and FRM client internal IODev_ERROR on error
  • added support for client module I2C_INA219

alle 20_FRM_XXXXX.pm

  • check for IODev install error in Init, Get, Set, Attr and Undef
  • missing get/set argument metadata added
  • get/set argument verifier improved
  • moved define argument verification and decoding from Init to Define
  • error behaviour of Init, Get, Set and Attr standardized
  • annotaded module help of attributes for FHEMWEB

FRM_I2C

  • init register image before updating received bytes
  • moved receive processing from FRM module to FRM_I2C module
  • added I2C read function "get register"
  • added I2C write function "set register"
  • improve live modification of IODev
  • issue I2C stop reading command if device is initialized with zero byte count or is deleted

OWX_FRM

  • Update in Arbeit

OWX_ASYNC

  • Update unwahrscheinlich (kein aktiver Maintainer)

FRM_LCD

  • ist seit längerem abgekündigt und wird nun entfernt: bitte statt dessen das kompatible Modul I2C_LCD verwenden

Device::Firmata 0.69 (CPAN) im Vergleich zu 0.64 (FHEM)

  • fix push on reference in method "attach"
  • fix analog input pin operations in Device::Firmata::Platform
  • added method IO::SerialIO::close()

Grüße,
Jens



Edit 23.10.2020:

  • alle FRM-Module aktualisiert.
  • zu 1) 11_OWX_FRM.pm ist in Arbeit.
  • zu 2) Anders als zunächst angenommen wirken sich die beschriebenen Änderungen auch auf Firmata-1-Wire-Lösungen aus.
  • zu 2) weiteres neues Attribut "receiveTimeout".

Edit 25.11.2020:

  • 11_OWX_FRM.pm aktualisiert.

Edit 20.12.2020:

  • Perl-Modul Device::Firmata aus FHEM entfernt.
FHEM 6.1 - RPi 4 Raspbian 12 + PiTFT - OPi Zero Armbian 5.35
EnOcean - (W)LAN/Firmata: BMP180, TSL2561, SHT21, Heatronic 3, OBIS - WLAN/ESP8266: Gardena 1251, Zirkulationspumpe - RTL433: Oregon - Bluetooth - MQTT
Contributions: https://svn.fhem.de/trac/browser/trunk/fhem/contrib/jensb

rudolfkoenig

ZitatIn Folge stürzt FHEM ab, wenn das Perl-Modul Device::Firmata aus dem FHEM-Unterverzeichnis gelöscht wird oder wenn man bei einer FHEM-Neuinstallation ein define für ein Firmata-Modul durchführt.
Kleine Korrektur: FHEM stuerzt nicht ab.
Falls man das Geraet neu definiert, dann wird "nur" die Meldung "Cannot load module FRM" ausgegeben, mit Details in FHEM Log (Can't locate Device/Firmata/...).
Falls man FHEM mit existierenden Definitionen in fhem.cfg startet, dann steht diese Meldung in der motd, was nach dem Start auf der FHEMWEB "Homepage" angezeigt wird, weiterhin wird ein von Modulen automatisch ausgeloestes save verhindert, damit die nicht akzeptierte Definition nicht automatisch aus der fhem.cfg entfernt wird.


jensb

Es gibt bei den bisherigen FRM-Modulen auch noch den Fall, dass das Define selbst funktioniert und erst etwas zeitversetzt der FRM-interne Client Init eine Perl-Exception auslöst, so dass ich FHEM neu starten musste, allerdings nicht zwingend im Zusammenhang mit einem fehlenden Device::Firmata.
FHEM 6.1 - RPi 4 Raspbian 12 + PiTFT - OPi Zero Armbian 5.35
EnOcean - (W)LAN/Firmata: BMP180, TSL2561, SHT21, Heatronic 3, OBIS - WLAN/ESP8266: Gardena 1251, Zirkulationspumpe - RTL433: Oregon - Bluetooth - MQTT
Contributions: https://svn.fhem.de/trac/browser/trunk/fhem/contrib/jensb

Allgaeuer

Hallo Jens,

bei mir funktioniert alles. Ich verwende "AD", "PWM", "IN" und "OUT" . Auch das "Flackern" beim IPad ist weg, wenn ich das FRM-Device aufgerufen habe.

Ich habe die Module hier aus dem Post rüberkopiert. Wenn Du vielleicht noch die Kommandozeilen angibst, wie man die Module später direkt von Github installiert/updated, dann ist Deine Beschreibung perfekt.

Danke  :)

Gruß Allgäuer

jensb

Hallo Allgäuer,

danke für den Test und deine Rückmeldung.

Die Beta-Versionen der FRM-Module kann man prinzipiell auch von GitHub direkt installieren. Auf der Kommandozeile geht das ungefähr so (Beispiel für Rasbian):


mkdir beta
cd beta
git clone https://github.com/jnsbyr/fhem.git
cd fhem/FHEM
sudo cp -a 10_FRM.pm <FHEM Installationsverzeichnis>/FHEM
sudo cp -a 20_FRM*.pm <FHEM Installationsverzeichnis>/FHEM
sudo chmod fhem:dialout <FHEM Installationsverzeichnis>/FHEM/*FRM*
cd ../..
rm -r beta


Wie man Device::Firmata über die Kommandozeile installiert, steht ja bereits im 1. Post (sudo cpan install Device::Firmata ...).

Grüße,
Jens
FHEM 6.1 - RPi 4 Raspbian 12 + PiTFT - OPi Zero Armbian 5.35
EnOcean - (W)LAN/Firmata: BMP180, TSL2561, SHT21, Heatronic 3, OBIS - WLAN/ESP8266: Gardena 1251, Zirkulationspumpe - RTL433: Oregon - Bluetooth - MQTT
Contributions: https://svn.fhem.de/trac/browser/trunk/fhem/contrib/jensb

JensS

Hallo Jens,

danke, dass du die Module weiterentwickelst! Auch den Wechsel der Firmata-Ressorcen zu den offiziellen Quellen finde ich gut.
Sobald die OWX verfügbar ist, werde ich FRM umstellen. Bis dahin verzichte ich auf updates.

Gruß Jens
Debian auf APU2C4, HM-CFG-USB2, SIGNALduino, HM-ES-PMSw1-Pl, TFA 30.3121, TFA 30.3125, ITS-150, PIR-5000, configurable Firmata USB & LAN, 1-wire: DS-18B20, DS-18S20, DS-2408, DS-2413, diverse I2C-Komponenten, zigbee2mqtt, ESPEasy etc.

Prof. Dr. Peter Henning


jensb

#7
Die neuen Versionen der Module 10_FRM.pm und 20_FRM_*.pm sind eingecheckt und ab 31.10.2020 per FHEM Update verfügbar.

Außerdem wurde das Modul 20_FRM_LCD.pm nach contrib/deprecated verschoben - bitte statt dessen das Modul 52_I2C_LCD.pm verwenden.

Auch der Wiki-Artikel über Firmata ist nun aktualisiert.

Grüße,
Jens
FHEM 6.1 - RPi 4 Raspbian 12 + PiTFT - OPi Zero Armbian 5.35
EnOcean - (W)LAN/Firmata: BMP180, TSL2561, SHT21, Heatronic 3, OBIS - WLAN/ESP8266: Gardena 1251, Zirkulationspumpe - RTL433: Oregon - Bluetooth - MQTT
Contributions: https://svn.fhem.de/trac/browser/trunk/fhem/contrib/jensb

golem

Hallo,
Bie mir erscheint bei meinen Eingängen die Meldung
Perl module Device::Firmata not properly installed.
Die Fimata Module habe die ich wie in Wiki beschrieben mit
sudo cpan install Device::Firmata
Installiert und im Fhem Verzeichnisse gelöscht. Hat Jemand noch eine Idee?

Gruß Denis
Pi - Max-Lan - 8x max Ht -3x Max WT - Max Fk -modbus umg103- 2x Arduino mit Firmata Ethernet- ws300 - 433Mhz Sender Empfänger - 7x 1wire ds1820

jensb

Hallo Denis,

wechsle zum IODev, also zu deinem FRM-Modul und schau dir an, ob es das Internal DRIVER_STATUS gibt und wenn ja, was da für eine Meldung steht.

DRIVER_STATUS soll helfen, die eigentliche Ursache zu finden. Es könnte z.B. sein, dass du die "alte" FHEM-Variante aus dem Unterverzeichnis FHEM\lib\Device nicht gelöscht hast (siehe dazu auch die Deinstallationsanleitung aus dem 1. Post dieses Threads). Aktuell liefert das FHEM-Update leider noch die alte Version, da die Umstellung von OWX nicht abgeschlossen ist.

Grüße,
Jens
FHEM 6.1 - RPi 4 Raspbian 12 + PiTFT - OPi Zero Armbian 5.35
EnOcean - (W)LAN/Firmata: BMP180, TSL2561, SHT21, Heatronic 3, OBIS - WLAN/ESP8266: Gardena 1251, Zirkulationspumpe - RTL433: Oregon - Bluetooth - MQTT
Contributions: https://svn.fhem.de/trac/browser/trunk/fhem/contrib/jensb

golem

Hi Jens,

Das internal DRIVER_STATUS ist nicht vorhanden. Muß ich die das Modul wohl nochmal austauschen oder?
Pi - Max-Lan - 8x max Ht -3x Max WT - Max Fk -modbus umg103- 2x Arduino mit Firmata Ethernet- ws300 - 433Mhz Sender Empfänger - 7x 1wire ds1820

jensb

Hallo Denis,

das Internal DRIVER_STATUS gibt es nur, wenn das FRM-Modul ein Problem festgestellt hat. Daher vermute ich, dass sich die Devices den Zustand gemerkt haben, wo es noch nicht gepasst hat.

Bitte prüfe, ob die Devices, bei denen die Meldung "Perl module Device::Firmata not properly installed" erscheint, das Internal IODev_ERROR=1 haben. Sollte das der Fall sein, dann solltest du FHEM einmal neu starten. Dadurch werden alle Internals gelöscht. Wenn das Internal nach dem Neustart weg ist, dann müsste auch die Fehlermeldung weg sein und dann haben wir den Grund.

Ist der Fall aber bei dir anders, dann bitte einmal die Ausgabe des Kommandos list für das FRM-Device und eines der Client-Devices mit der Meldung posten, sowie die Rev der beiden Module aus der Ausgabe des Kommandos version.

Grüße,
Jens
FHEM 6.1 - RPi 4 Raspbian 12 + PiTFT - OPi Zero Armbian 5.35
EnOcean - (W)LAN/Firmata: BMP180, TSL2561, SHT21, Heatronic 3, OBIS - WLAN/ESP8266: Gardena 1251, Zirkulationspumpe - RTL433: Oregon - Bluetooth - MQTT
Contributions: https://svn.fhem.de/trac/browser/trunk/fhem/contrib/jensb

golem

Hallo Jens,

Internals:
   DEF        /dev/serial/by-id/usb-Arduino__www.arduino.cc__Arduino_Uno_6493534313335141C261-if00@57600
   DeviceName /dev/serial/by-id/usb-Arduino__www.arduino.cc__Arduino_Uno_6493534313335141C261-if00@57600
   FD         62
   FUUID      5c77ca64-f33f-dec7-5fed-b2c85630156b6931
   LAST_RECEIVED 2020-11-24 21:43:30
   NAME       firmata
   NOTIFYDEV  global
   NR         380
   NTFY_ORDER 50-firmata
   PARTIAL   
   STATE      Initialized
   TYPE       FRM
   analog_pins 14,15,16,17,18,19
   analog_resolutions 14:10,15:10,16:10,17:10,18:10,19:10
   encoder_pins 2,3
   encoder_resolutions 2:28,3:28
   firmware   ConfigurableFirmata.ino
   firmware_version V_2_06
   i2c_pins   18,19
   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
   servo_pins 2,3,4,5,6,7,8,9,10,11,12,13
   servo_resolutions 2:14,3:14,4:14,5:14,6:14,7:14,8:14,9:14,10:14,11:14,12:14,13:14
   stepper_pins 2,3,4,5,6,7,8,9,10,11,12,13,14,15,16,17,18,19
   stepper_resolutions 2:21,3:21,4:21,5:21,6:21,7:21,8:21,9:21,10:21,11:21,12:21,13:21,14:21,15:21,16:21,17:21,18:21,19:21
   READINGS:
     2020-11-24 21:42:04   state           Initialized
   SERIAL:
Attributes:
   i2c-config 1
   room       Geräte
   verbose    3

Internals:
   DEF        3
   FUUID      5c77c9fd-f33f-dec7-31b7-8ed9c67e00a09d54
   IODev      firmata
   IODev_ERROR 1
   NAME       in_gaszaehler
   NR         158
   STATE      on
   TYPE       FRM_IN
   READINGS:
     2020-11-06 11:41:45   reading         on
     2020-11-24 21:42:04   state           error: Perl module Device::Firmata not properly installed
Attributes:
   IODev      firmata
   activeLow  yes
   comment    Bei einer großen Leitungslänge eines Arduino eingangs ist der Interne Pullup zu hoch. ein Externe 1KOhm Wiederstand ist hier besser.
   group      Gas
   internal-pullup off
   room       Heizung,Keller
   stateFormat reading

10_FRM.pm              23052 2020-10-30 17:48:53Z jensb
20_FRM_IN.pm           23054 2020-10-30 18:16:24Z jensb

OneWire und I2C funktionieren mit dem Firmata Device
Pi - Max-Lan - 8x max Ht -3x Max WT - Max Fk -modbus umg103- 2x Arduino mit Firmata Ethernet- ws300 - 433Mhz Sender Empfänger - 7x 1wire ds1820

Prof. Dr. Peter Henning

OK, ich habe beim Test keine Fehler in den Änderungsvorschlägen von Jens gefunden und soeben 11_OWX_FRM eingecheckt.

LG

pah

jensb

Hallo Denis,

die Versionen passen.

ZitatOneWire und I2C funktionieren mit dem Firmata Device
Das ist prima und auch plausibel, denn die bisherigen OneWire-Modul-Versionen und alle I2C-Module überprüfen die Firmata-Version und deren Kompatibilität nicht, das machen nur die "neuen" FRM-Module.

Zitat... dann solltest du FHEM einmal neu starten.
Hast du das ausprobiert, bevor du die list-Kommandos ausgeführt hast?

Grüße,
Jens
FHEM 6.1 - RPi 4 Raspbian 12 + PiTFT - OPi Zero Armbian 5.35
EnOcean - (W)LAN/Firmata: BMP180, TSL2561, SHT21, Heatronic 3, OBIS - WLAN/ESP8266: Gardena 1251, Zirkulationspumpe - RTL433: Oregon - Bluetooth - MQTT
Contributions: https://svn.fhem.de/trac/browser/trunk/fhem/contrib/jensb

JensS

#15
läuft... :)
FRM_IN und OUT, AD
OWX_FRM und FRM_I2C


Gruß und Dank!
Von und an Jens sowie Herrn Prof.
Debian auf APU2C4, HM-CFG-USB2, SIGNALduino, HM-ES-PMSw1-Pl, TFA 30.3121, TFA 30.3125, ITS-150, PIR-5000, configurable Firmata USB & LAN, 1-wire: DS-18B20, DS-18S20, DS-2408, DS-2413, diverse I2C-Komponenten, zigbee2mqtt, ESPEasy etc.

wthiess

Hallo!
Leider habe ich mit Firmata ein Problem. Ich steuere mit einem Arduino mega und Ethernetshield eine 8Fach Relais Karte an. Leider immer wenn Fhem neu startet und/oder Firmata reinit macht, werden alle 8 Relais kurz gestartet. Das ist natürlich eine Katastrophe da ich mit einem Relais mein Eingangstor steuere. Vorher hatte ich das über einen Pi mit GPIO. Ohne Fhem gibt es kein Problem. Wie könnte man das lösen? Bitte um Hilfe.
lg
Wolfgang

Raspberry Pi 3; 8xRelais; Aptodec Nano V3.0 Pro; FS1000a; RF-5V; Hama TS33C; 3x Brennerstuhl FunkSteckdosen; 9x Dooya funk Rollo; KWL Systemair VR400; Thermokon Modbusthermostat; diverse China Modbus Thermostate; 1-wire Bus; Telegram; QuickFhem; FhemNative; Firmata; Alexa ......

golem

Hallo Jens,

Neugestartet habe ich schon mehrfach.

Denis
Pi - Max-Lan - 8x max Ht -3x Max WT - Max Fk -modbus umg103- 2x Arduino mit Firmata Ethernet- ws300 - 433Mhz Sender Empfänger - 7x 1wire ds1820

jensb

Hallo Denis,

ich werde bis Ende dieser Woche eine Testversion erstellen und sie hier posten.

Grüße,
Jens
FHEM 6.1 - RPi 4 Raspbian 12 + PiTFT - OPi Zero Armbian 5.35
EnOcean - (W)LAN/Firmata: BMP180, TSL2561, SHT21, Heatronic 3, OBIS - WLAN/ESP8266: Gardena 1251, Zirkulationspumpe - RTL433: Oregon - Bluetooth - MQTT
Contributions: https://svn.fhem.de/trac/browser/trunk/fhem/contrib/jensb

jensb

Hallo Wolfgang!

ZitatLeider immer wenn Fhem neu startet und/oder Firmata reinit macht, werden alle 8 Relais kurz gestartet.
Das hat (leider) nichts mit dem Thema dieses Threads zu tun. Hier eine Kurzantwort. Wenn das nicht reicht bitte einen eigenen Thread aufmachen und hier den Verweis posten.

Es liegt vermutlich an einer Besonderheit von Firmata für den Arduino. Die Standardsketche setzen bei der Initialisierung analoge GPIOs auf Eingang (hochohmig) und rein digitale GPIOs auf Ausgang (niederohmig). Die AVR Microcontroller setzen beim Reset aber alle GPIOs auf Eingang. Und FHEM setzt die Pins nach dem Verbindungsaufbau so, wie du das willst. Wenn ich ein Relais wäre, würde ich unter diesen Bedingungen beim Reset auch klappern. Schau dir im Firmata-Sketch die Prozedur systemResetCallback() an, da kann man das Init-Verhalten von Firmata beeinflussen. Zum Testen solltest du in FHEM keine Pins konfigurieren. Anschließend sollte beim Reset nichts mehr klappern.

Grüße,
Jens
FHEM 6.1 - RPi 4 Raspbian 12 + PiTFT - OPi Zero Armbian 5.35
EnOcean - (W)LAN/Firmata: BMP180, TSL2561, SHT21, Heatronic 3, OBIS - WLAN/ESP8266: Gardena 1251, Zirkulationspumpe - RTL433: Oregon - Bluetooth - MQTT
Contributions: https://svn.fhem.de/trac/browser/trunk/fhem/contrib/jensb

jensb

Hallo Denis,

anbei die angekündigte Testversion für 10_FRM.pm. Bitte zuerst die vorhandene Version sichern, dann die Testversion einspielen und FHEM neu starten. Bitte einen Auszug des FHEM-Logs posten ab Neustart (beginnt z.B. mit "Including fhem.cfg") bis zur letzten Ausgabe mit "FRM_Get_Device_Firmata_Status= ...". Alles was du aus Datenschutzgründen nicht posten willst vorher unkenntlich machen oder löschen (Passwörter, IPs, etc.).

Außerdem hat das FRM-Device nun wieder das Internal DRIVER_VERSION, bitte auch dessen Wert posten.

Die Testversion enthält bereits funktionelle Änderungen, die aber aus meiner Sicht noch spekulativ sind, da ich nicht weiß, warum das Problem bei dir auftritt. Vielleicht lösen diese Änderungen aber bereits das Problem.

Grüße,
Jens
FHEM 6.1 - RPi 4 Raspbian 12 + PiTFT - OPi Zero Armbian 5.35
EnOcean - (W)LAN/Firmata: BMP180, TSL2561, SHT21, Heatronic 3, OBIS - WLAN/ESP8266: Gardena 1251, Zirkulationspumpe - RTL433: Oregon - Bluetooth - MQTT
Contributions: https://svn.fhem.de/trac/browser/trunk/fhem/contrib/jensb

golem

#21
Hallo Jens,

hier der Auszug  aus der Logdatei.


2020.11.29 14:12:01 1: Including fhem.cfg
2020.11.29 14:12:01 3: telnetPort: port 7072 opened
2020.11.29 14:12:01 3: WEB: port 8083 opened
2020.11.29 14:12:01 3: WEB2: port 8082 opened
2020.11.29 14:12:01 3: WEBphone: port 8084 opened
2020.11.29 14:12:01 3: WEBtablet: port 8085 opened
2020.11.29 14:12:02 1: PERL WARNING: Subroutine HourCounter_Log redefined at ./FHEM/98_HourCounter.pm line 80, <$fh> line 425.
2020.11.29 14:12:02 1: PERL WARNING: Subroutine HourCounter_AddLog redefined at ./FHEM/98_HourCounter.pm line 91, <$fh> line 425.
2020.11.29 14:12:02 1: PERL WARNING: Subroutine HourCounter_Exec redefined at ./FHEM/98_HourCounter.pm line 107, <$fh> line 425.
2020.11.29 14:12:02 1: PERL WARNING: Subroutine HourCounter_cmdQueueAdd redefined at ./FHEM/98_HourCounter.pm line 117, <$fh> line 425.
2020.11.29 14:12:02 1: PERL WARNING: Subroutine HourCounter_ExecQueue redefined at ./FHEM/98_HourCounter.pm line 124, <$fh> line 425.
2020.11.29 14:12:02 1: PERL WARNING: Subroutine HourCounter_RoundHour redefined at ./FHEM/98_HourCounter.pm line 166, <$fh> line 425.
2020.11.29 14:12:02 1: PERL WARNING: Subroutine HourCounter_RoundDay redefined at ./FHEM/98_HourCounter.pm line 173, <$fh> line 425.
2020.11.29 14:12:02 1: PERL WARNING: Subroutine HourCounter_RoundWeek redefined at ./FHEM/98_HourCounter.pm line 180, <$fh> line 425.
2020.11.29 14:12:02 1: PERL WARNING: Subroutine HourCounter_SecondsOfDay redefined at ./FHEM/98_HourCounter.pm line 191, <$fh> line 425.
2020.11.29 14:12:02 1: PERL WARNING: Subroutine HourCounter_RoundMonth redefined at ./FHEM/98_HourCounter.pm line 198, <$fh> line 425.
2020.11.29 14:12:02 1: PERL WARNING: Subroutine HourCounter_RoundYear redefined at ./FHEM/98_HourCounter.pm line 205, <$fh> line 425.
2020.11.29 14:12:02 1: PERL WARNING: Subroutine HourCounter_Initialize redefined at ./FHEM/98_HourCounter.pm line 211, <$fh> line 425.
2020.11.29 14:12:02 1: PERL WARNING: Subroutine HourCounter_Define redefined at ./FHEM/98_HourCounter.pm line 224, <$fh> line 425.
2020.11.29 14:12:02 1: PERL WARNING: Subroutine HourCounter_Undef redefined at ./FHEM/98_HourCounter.pm line 270, <$fh> line 425.
2020.11.29 14:12:02 1: PERL WARNING: Subroutine HourCounter_Get redefined at ./FHEM/98_HourCounter.pm line 277, <$fh> line 425.
2020.11.29 14:12:02 1: PERL WARNING: Subroutine HourCounter_Set redefined at ./FHEM/98_HourCounter.pm line 290, <$fh> line 425.
2020.11.29 14:12:02 1: PERL WARNING: Subroutine HourCounter_Notify redefined at ./FHEM/98_HourCounter.pm line 397, <$fh> line 425.
2020.11.29 14:12:02 1: PERL WARNING: Subroutine HourCounter_Attr redefined at ./FHEM/98_HourCounter.pm line 430, <$fh> line 425.
2020.11.29 14:12:02 1: PERL WARNING: Subroutine HourCounter_Seconds2HMS redefined at ./FHEM/98_HourCounter.pm line 447, <$fh> line 425.
2020.11.29 14:12:02 1: PERL WARNING: Subroutine HourCounter_weekBase redefined at ./FHEM/98_HourCounter.pm line 457, <$fh> line 425.
2020.11.29 14:12:02 1: PERL WARNING: Subroutine HourCounter_Run redefined at ./FHEM/98_HourCounter.pm line 472, <$fh> line 425.
2020.11.29 14:12:02 3: HourCounter HourCounter Initialize.220 Init Done with Version 1.0.1.2 - 24.12.2014
2020.11.29 14:12:02 0: HourCounter Gaszaehler Define.228 parameters: Gaszaehler HourCounter du_in_gaszaehler.on du_in_gaszaehler.off
2020.11.29 14:12:02 0: HourCounter Ladepumpe Define.228 parameters: Ladepumpe HourCounter in_ladepumpe:reading:.off in_ladepumpe:reading:.on
2020.11.29 14:12:02 2: eventTypes: loaded 3090 events from log/eventTypes.txt
2020.11.29 14:12:03 3: ModbusRT485: defined as /dev/serial/by-id/usb-Prolific_Technology_Inc._USB-Serial_Controller-if00-port0@38400
2020.11.29 14:12:03 1: PERL WARNING: Useless use of hash element in void context at ./FHEM/50_WS300.pm line 293, <$fh> line 896.
2020.11.29 14:12:03 1: PERL WARNING: Useless use of hash element in void context at ./FHEM/50_WS300.pm line 316, <$fh> line 896.
2020.11.29 14:12:03 1: PERL WARNING: Useless use of hash element in void context at ./FHEM/50_WS300.pm line 420, <$fh> line 896.
2020.11.29 14:12:04 1: WS300 Device /dev/serial/by-id/usb-ELV_AG_eQ3_WS_300_PC_II-if00-port0 opened
2020.11.29 14:12:04 1: [Alarm_Define] data hash restored from save file with date 2020-06-08 11:18:29
2020.11.29 14:12:04 3: TABLETUI: new ext defined infix:ftui/: dir:./www/tablet:
2020.11.29 14:12:04 3: Registering HTTPSRV TABLETUI for URL /ftui   and assigned link ftui/ ...
2020.11.29 14:12:04 3: Opening sduino device /dev/serial/by-id/usb-1a86_USB2.0-Serial-if00-port0
2020.11.29 14:12:04 3: Setting sduino serial parameters to 57600,8,N,1
2020.11.29 14:12:04 1: sduino: DoInit, /dev/serial/by-id/usb-1a86_USB2.0-Serial-if00-port0
2020.11.29 14:12:04 3: sduino device opened
2020.11.29 14:12:04 3: sduino: Attr, setting Verbose to: 3
2020.11.29 14:12:05 3: FRM_Get_Device_Firmata_Status=1
2020.11.29 14:12:05 0: HourCounter Wasserzaehler Define.228 parameters: Wasserzaehler HourCounter du_in_Wasserzaehler.off du_in_Wasserzaehler.on
2020.11.29 14:12:05 0: HourCounter HC_Wohnzimmerlicht Define.228 parameters: HC_Wohnzimmerlicht HourCounter WohnzimmerLicht.on WohnzimmerLicht.off
2020.11.29 14:12:06 1: OWX_FRM::Define warning: version 7.11 not identical to OWX version 7.21
2020.11.29 14:12:06 3: OWTHERM:  Device T_TK defined.
2020.11.29 14:12:06 3: OWTHERM:  Device T_SO_1 defined.
2020.11.29 14:12:06 3: OWTHERM:  Device T_HK_vor defined.
2020.11.29 14:12:06 3: OWTHERM:  Device T_SO_2 defined.
2020.11.29 14:12:06 3: OWTHERM:  Device T_HK_rueck defined.
2020.11.29 14:12:06 3: OWTHERM:  Device T_SP_unten defined.
2020.11.29 14:12:06 3: OWTHERM:  Device T_SP_oben defined.
2020.11.29 14:12:06 3: OWTHERM:  Device T_ZI defined.
2020.11.29 14:12:06 0: [echodevice] load ECHO Device ECHO_G2A0RF037456028P
2020.11.29 14:12:06 0: [echodevice] load ECHO Device ECHO_G000MW0773440JCB
2020.11.29 14:12:06 0: [echodevice] load ECHO Device ECHO_G070L81485050AF4
2020.11.29 14:12:06 0: [echodevice] load ECHO Device ECHO_G0911M07931345N1
2020.11.29 14:12:06 0: [echodevice] load ECHO Device ECHO_G090U61091621VAB
2020.11.29 14:12:06 0: [echodevice] load ECHO Device ECHO_G0W0T8059352F2UG
2020.11.29 14:12:06 0: [echodevice] load ECHO Device ECHO_G070VM1493820B2E
2020.11.29 14:12:06 0: [echodevice] load ECHO Device ECHO_a49b4626d258447cb1e254fb61567b03
2020.11.29 14:12:06 3: umg103: defined with id 1, interval 5, protocol default (RTU), mode master
2020.11.29 14:12:06 1: Including ./log/fhem.save
2020.11.29 14:12:07 3: umg103: bad reading name 'Spannungswandler_Primär' (allowed chars: A-Za-z/\d_\.-)
2020.11.29 14:12:07 3: umg103: bad reading name 'Spannungswandler_Sekundär' (allowed chars: A-Za-z/\d_\.-)
2020.11.29 14:12:07 3: umg103: bad reading name 'Stromwandler_Primär' (allowed chars: A-Za-z/\d_\.-)
2020.11.29 14:12:07 3: umg103: bad reading name 'Stromwandler_Sekundär' (allowed chars: A-Za-z/\d_\.-)
2020.11.29 14:12:07 1: Messages collected while initializing FHEM:SecurityCheck:
  telnetPort is not password protected
  WEB2 is not password protected
  WEBtablet is not password protected
  WEBphone is not password protected

Protect this FHEM installation by configuring the allowed device allowed_WEB
You can disable this message with attr global motd none

2020.11.29 14:12:07 2: MyAlexa: starting alexa-fhem: /usr/local/bin/alexa-fhem -c ./alexa-fhem.cfg -a xx:xx
2020.11.29 14:12:07 3: MyAlexa: starting
2020.11.29 14:12:07 3: MyAlexa: using logfile: /mnt/share/fhemlog/alexa-2020-11-29.log
2020.11.29 14:12:07 3: Opening firmata device /dev/serial/by-id/usb-Arduino__www.arduino.cc__Arduino_Uno_6493534313335141C261-if00
2020.11.29 14:12:07 3: Setting firmata serial parameters to 57600,8,N,1
2020.11.29 14:12:07 3: firmata device opened
2020.11.29 14:12:07 3: harmony: starting discovery
2020.11.29 14:12:07 3: harmony: sending discovery
2020.11.29 14:12:07 3: umg103: RegisterAtIODev called from SetIODev registers umg103 at ModbusRT485 with id 1, MODE master, PROTOCOL RTU
2020.11.29 14:12:07 3: umg103: Notify / Init: using ModbusRT485 for communication
2020.11.29 14:12:07 0: Featurelevel: 6
2020.11.29 14:12:07 0: Server started with 246 defined entities (fhem.pl:23205/2020-11-21 perl:5.024001 os:linux user:fhem pid:27091)
2020.11.29 14:12:07 3: Opening ml device 192.168.0.129:62910
2020.11.29 14:12:07 3: ml device opened
2020.11.29 14:12:08 2: AttrTemplates: got 211 entries
2020.11.29 14:12:08 3: [HC_WT_Wohnzimmer5] sensor <1> not found - check name.
2020.11.29 14:12:09 1: nrw: Can't open ./FHEM/holiday/nrw.holiday: No such file or directory
2020.11.29 14:12:09 3: sduino: getAttrDevelopment, IdList ### Attribute development is in this version ignored ###
2020.11.29 14:12:09 3: sduino: IdList, attr whitelist: 0,0.1,0.2,0.3,0.4,1,3,3.1,4,6,7,8,9,10,11,12,13,13.1,13.2,14,15,16,17,17.1,18,19,21,22,23,24,25,26,27,28,29,30,31,32,33,33.1,33.2,34,35,36,37,38,39,40,41,42,44,44.1,45,46,47,48,49,50,51,52,55,56,57,58,59,60,61,62,64,65,66,67,69,70,71,72,73,74,74.1,76,79,80,81,83,84,85,86,87,89,90,91,91.1,92,93,94,95,96
2020.11.29 14:12:09 3: sduino: IdList, MS 0 0.1 0.2 0.3 0.4 1 3 3.1 4 6 7 13 13.2 14 15 17 23 25 33 33.1 33.2 35 41 49 51 55 65 74.1 87 90 91.1 93
2020.11.29 14:12:09 3: sduino: IdList, MU 8 9 13.1 16 17.1 19 21 22 24 26 27 28 29 30 31 32 34 36 37 38 39 40 42 44 44.1 45 46 48 50 56 59 60 61 62 64 66 67 69 70 71 72 73 74 76 79 80 81 83 84 85 86 89 91 92 94 95
2020.11.29 14:12:09 3: sduino: IdList, MC 10 11 12 18 47 52 57 58 96
2020.11.29 14:12:09 3: sduino: SimpleWrite_XQ, disable receiver (XQ)
2020.11.29 14:12:09 3: sduino: StartInit, get version, retry = 0
2020.11.29 14:12:09 1: 127.0.0.1:1883 reappeared (mqtt2client)
2020.11.29 14:12:09 3: harmony:discovery: new discovery response from 192.168.0.38
2020.11.29 14:12:09 3: hub: connected
2020.11.29 14:12:09 3: [AAA V5.0] Added hidden room 'AlarmRoom' to WEB_127.0.0.1_50000
2020.11.29 14:12:09 2: sduino: CheckVersionResp, initialized v3.4.4
2020.11.29 14:12:09 3: sduino: CheckVersionResp, enable receiver (XE)
2020.11.29 14:12:10 3: firmata: Firmata Firmware Version ConfigurableFirmata.ino V_2_06 (using Protocol Version V_2_06)
2020.11.29 14:12:10 1: in4 ERROR: init failed, Perl module Device::Firmata not properly installed
2020.11.29 14:12:10 1: in_gaszaehler ERROR: init failed, Perl module Device::Firmata not properly installed
2020.11.29 14:12:10 1: in_ladepumpe ERROR: init failed, Perl module Device::Firmata not properly installed
2020.11.29 14:12:11 3: hub: new config
2020.11.29 14:12:14 3: [HC_WT_Wohnzimmer5] sensor <1> not found - check name.
2020.11.29 14:12:17 0: HourCounter Gaszaehler Run.598 first run done countsOverall:64949
2020.11.29 14:12:17 0: HourCounter Ladepumpe Run.598 first run done countsOverall:2
2020.11.29 14:12:20 0: HourCounter Wasserzaehler Run.598 first run done countsOverall:4837
2020.11.29 14:12:20 0: HourCounter HC_Wohnzimmerlicht Run.598 first run done countsOverall:291
2020.11.29 14:12:21 1: OWX_Discover: 1-Wire devices found on bus oneWire (T_SO_1,T_TK,T_HK_vor,T_SO_2,T_HK_rueck,T_SP_unten,T_SP_oben,T_ZI)
2020.11.29 14:13:06 1: OWX_Init called for bus oneWire with interface state Initialized, now going for detect
2020.11.29 14:13:06 1: OWX: 1-Wire bus oneWire: interface Firmata detected in firmata
2020.11.29 14:13:06 1: OWX_Discover: 1-Wire devices found on bus oneWire (T_SO_1,T_TK,T_HK_vor,T_SO_2,T_HK_rueck,T_SP_unten,T_SP_oben,T_ZI)


edit: Fehlt  natürlich   noch der  hinweis, das  die Eingänge  jetzt   funktionieren.   Einer nicht  auf  Anhieb, in_Gaszaehler habe ich in der Definition
auf9 und dann zurück auf  3 geändert, dann war auch  da die Fehlermeldung  weg.
Gruß Denis
Pi - Max-Lan - 8x max Ht -3x Max WT - Max Fk -modbus umg103- 2x Arduino mit Firmata Ethernet- ws300 - 433Mhz Sender Empfänger - 7x 1wire ds1820

jensb

Hallo Denis,

danke für den Test, das hilft mir weiter. Das verbleibende Problem steckt hier:

2020.11.29 14:12:05 3: FRM_Get_Device_Firmata_Status=1
...
2020.11.29 14:12:10 1: in4 ERROR: init failed, Perl module Device::Firmata not properly installed
2020.11.29 14:12:10 1: in_gaszaehler ERROR: init failed, Perl module Device::Firmata not properly installed
2020.11.29 14:12:10 1: in_ladepumpe ERROR: init failed, Perl module Device::Firmata not properly installed


Obwohl also Device::Firmata einwandfrei erkannt wurde, kommt es trotzdem zu Fehlermeldungen. Ich werde versuchen das Nachzustellen, um das zu korrigieren.

Es freut mich, dass du mit der Änderung der Pin-Zuordnung einen Workaround gefunden hast, der zumindest mit der Testversion funktioniert.

Grüße,
Jens
FHEM 6.1 - RPi 4 Raspbian 12 + PiTFT - OPi Zero Armbian 5.35
EnOcean - (W)LAN/Firmata: BMP180, TSL2561, SHT21, Heatronic 3, OBIS - WLAN/ESP8266: Gardena 1251, Zirkulationspumpe - RTL433: Oregon - Bluetooth - MQTT
Contributions: https://svn.fhem.de/trac/browser/trunk/fhem/contrib/jensb

jensb

Hallo Denis,

eine Ursache, warum das Problem bei dir aufgetreten ist, konnte ich trotz deines Logs nicht finden. Es könnte daran liegen, dass bei dir die Module in einer anderen Reihenfolge geladen werden als bei mir. Daher habe ich eine weitere Testversion erstellt, die noch mehr loggt.

Bitte wiederhole damit den Test, auch wenn du inzwischen kein Problem mehr hast. Also aktuelle Modulversion sichern, neue einspielen, FHEM neu starten, ggf. bei in_gaszaehler Pin vorübergehend ändern und Logausschnitt posten. Falls du eine Möglichkeit hast vor dem neuen Test das ursprüngliche Problem zu wiederholen (z.B. mit der alten Modulversion), so dass in_gaszaehler wieder die Fehlermeldung zeigt, wäre es noch besser.

Grüße,
Jens
FHEM 6.1 - RPi 4 Raspbian 12 + PiTFT - OPi Zero Armbian 5.35
EnOcean - (W)LAN/Firmata: BMP180, TSL2561, SHT21, Heatronic 3, OBIS - WLAN/ESP8266: Gardena 1251, Zirkulationspumpe - RTL433: Oregon - Bluetooth - MQTT
Contributions: https://svn.fhem.de/trac/browser/trunk/fhem/contrib/jensb

BlackFlag

Hallo,

ich habe das gleiche Problem wie Denis. Ich habe die letzte 10_FRM.pm mal runtergeladen, aber immer noch den Fehler, dass das IODev funktioniert, ein FRM_IN aber nicht:
2020.12.17 07:39:52 1: Alarmanlage.Scharf ERROR: init failed, Perl module Device::Firmata not properly installed
Mit dem Trick, die Pinanordnung zu ändern, habe ich es geschafft, dass das Device wieder geht. Da Denis länger nicht mehr geantwortet hat, biete ich mich zum testen an ;).

Hier noch meine Dev-Listings:


list FirmataWifi
Internals:
   CONNECTS   1
   DEF        3030 global
   DRIVER_VERSION 0.69
   DeviceName 3030
   FD         4
   FUUID      5fdb7a1c-f33f-c256-e7ce-ea043cffcf7413e3
   LAST_RECEIVED 2020-12-17 16:41:15
   NAME       FirmataWifi
   NOTIFYDEV  global
   NR         304
   NTFY_ORDER 50-FirmataWifi
   PORT       3030
   STATE      Initialized
   TYPE       FRM
   analog_pins 17
   analog_resolutions 17:10
   firmware   StandardFirmataWiFi.ino
   firmware_version V_2_05
   i2c_pins   4,5
   input_pins 0,1,2,3,4,5,12,13,14,15,16
   output_pins 0,1,2,3,4,5,12,13,14,15,16
   protocol_version V_2_05
   pullup_pins 0,1,2,3,4,5,12,13,14,15,16
   pwm_pins   0,1,2,3,4,5,12,13,14,15,16
   pwm_resolutions 0:10,1:10,2:10,3:10,4:10,5:10,12:10,13:10,14:10,15:10,16:10
   servo_pins 0,1,2,3,4,5,12,13,14,15,16
   servo_resolutions 0:14,1:14,2:14,3:14,4:14,5:14,12:14,13:14,14:14,15:14,16:14
   READINGS:
     2020-12-17 16:41:18   state           Initialized
   SERIAL:
   SocketDevice:
     BUF       
     DeviceName 3030
     FD         82
     LAST_RECEIVED 2020-12-17 16:46:04
     NAME       FirmataWifi_1.1.1.1_63165
     NR         306
     PEER       1.1.1.1
     PORT       63165
     SNAME      FirmataWifi
     SSL       
     STATE      Connected
     TEMPORARY  1
     TYPE       FRM
     READINGS:
       2020-12-17 16:41:15   state           Connected
Attributes:
------------------------------
list Alarmanlage.Scharf
Internals:
   DEF        15
   FUUID      5d1f5d4e-f33f-c256-f7ba-cd3d799138d82574
   IODev      FirmataWifi
   NAME       Alarmanlage.Scharf
   NR         54
   PIN        15
   STATE      zuletzt: off 2020-12-17 16:46:04
   TYPE       FRM_IN
   READINGS:
     2020-12-17 16:46:04   reading         off
     2020-12-17 16:46:04   state           Initialized
Attributes:
   IODev      FirmataWifi
   activeLow  no
   count-mode none
   icon       secur_open
   internal-pullup on
   room       Security
   stateFormat {"zuletzt: ".ReadingsVal('Alarmanlage.Scharf','reading','')." ".ReadingsTimestamp('Alarmanlage.Scharf','reading','')}

jensb

Hallo BlackFlag,

schade dass du den "Trick" schon versucht hast. Ich brauche vorzugsweise die Logausgaben der Firmata-Module nach dem Start vom FHEM, bevor alles wieder gut ist. Vermutlich kannst du den Fehler aber jetzt nicht mehr reproduzieren. Poste bitte trotzdem einen Logauszug vom Start von FHEM bis kurz nachdem sich das Firmata-Device verbunden hat.

Grüße,
Jens
FHEM 6.1 - RPi 4 Raspbian 12 + PiTFT - OPi Zero Armbian 5.35
EnOcean - (W)LAN/Firmata: BMP180, TSL2561, SHT21, Heatronic 3, OBIS - WLAN/ESP8266: Gardena 1251, Zirkulationspumpe - RTL433: Oregon - Bluetooth - MQTT
Contributions: https://svn.fhem.de/trac/browser/trunk/fhem/contrib/jensb

JensS

Hier mal ein Device von meiner Installation. Läuft alles tadellos.Internals:
   DEF        3
   FUUID      5c7ac76e-f33f-9d8f-51ae-4b94e73b3d84b52d
   IODev      Boden
   NAME       Alarmkontakt_1
   NR         65
   PIN        3
   STATE      off
   TYPE       FRM_IN
   READINGS:
     2020-12-18 11:37:18   reading         off
     2020-12-17 14:39:02   state           Initialized
Attributes:
   IODev      Boden
   activeLow  yes
   alias      Terrassentür
   devStateIcon off:secur_locked@green on:secur_open@red
   group      Alarmkontakte
   internal-pullup on
   room       Alarm-Anlage,Wohnzimmer
   stateFormat reading

Das FRM-Device:Internals:
   DEF        /dev/serial/by-id/usb-1a86_USB2.0-Serial-if00-port0@57600
   DeviceName /dev/serial/by-id/usb-1a86_USB2.0-Serial-if00-port0@57600
   FD         5
   FUUID      5c7ac76d-f33f-9d8f-018c-14e19af6942b5771
   LAST_RECEIVED 2020-12-18 19:50:22
   NAME       Boden
   NOTIFYDEV  global
   NR         25
   NTFY_ORDER 50-Boden
   PARTIAL   
   STATE      Initialized
   TYPE       FRM
   analog_pins 54,55,56,57,58,59,60,61,62,63,64,65,66,67,68,69
   analog_resolutions 54:10,55:10,56:10,57:10,58:10,59:10,60:10,61:10,62:10,63:10,64:10,65:10,66:10,67:10,68:10,69:10
   firmware   MegaBoden.ino
   firmware_version V_2_10
   i2c_pins   20,21
   input_pins 2,3,4,5,6,7,8,9,10,11,12,13,14,15,16,17,18,19,20,21,22,23,24,25,26,27,28,29,30,31,32,33,34,35,36,37,38,39,40,41,42,43,44,45,46,47,48,49,50,51,52,53,54,55,56,57,58,59,60,61,62,63,64,65,66,67,68,69
   onewire_pins 2,3,4,5,6,7,8,9,10,11,12,13,14,15,16,17,18,19,20,21,22,23,24,25,26,27,28,29,30,31,32,33,34,35,36,37,38,39,40,41,42,43,44,45,46,47,48,49,50,51,52,53,54,55,56,57,58,59,60,61,62,63,64,65,66,67,68,69
   output_pins 2,3,4,5,6,7,8,9,10,11,12,13,14,15,16,17,18,19,20,21,22,23,24,25,26,27,28,29,30,31,32,33,34,35,36,37,38,39,40,41,42,43,44,45,46,47,48,49,50,51,52,53,54,55,56,57,58,59,60,61,62,63,64,65,66,67,68,69
   protocol_version V_2_06
   pullup_pins 2,3,4,5,6,7,8,9,10,11,12,13,14,15,16,17,18,19,20,21,22,23,24,25,26,27,28,29,30,31,32,33,34,35,36,37,38,39,40,41,42,43,44,45,46,47,48,49,50,51,52,53,54,55,56,57,58,59,60,61,62,63,64,65,66,67,68,69
   pwm_pins   2,3,4,5,6,7,8,9,10,11,12,13,44,45,46
   pwm_resolutions 2:8,3:8,4:8,5:8,6:8,7:8,8:8,9:8,10:8,11:8,12:8,13:8,44:8,45:8,46:8
   READINGS:
     2019-10-20 21:52:45   error           I2C: Too few byŹ⚊㊀㎀む℀㞀㈀㊀㜀ᜀ㒀㜀㞀
     2020-12-17 14:39:02   state           Initialized
   SERIAL:
Attributes:
   i2c-config 3000
   room       FIRMATA
Gruß Jens
Debian auf APU2C4, HM-CFG-USB2, SIGNALduino, HM-ES-PMSw1-Pl, TFA 30.3121, TFA 30.3125, ITS-150, PIR-5000, configurable Firmata USB & LAN, 1-wire: DS-18B20, DS-18S20, DS-2408, DS-2413, diverse I2C-Komponenten, zigbee2mqtt, ESPEasy etc.

BlackFlag

#27
Ich kann den Fehler leider jederzeit reproduzieren  ;).
Nachfolgend das Log mit Device::Firmata 0.64, die mit FHEM immer noch mitkommt. Danach dann das Log mit der 0.69.
Ich habe alles was nicht mit Firmata zu tun hat, rausgenommen. Das ganze Log würde ich hier nicht posten wollen, kann es aber gern auf anderem Weg zur Verfügung stellen.


2020.12.18 19:15:51 1: Including fhem.cfg
2020.12.18 19:15:52 2: eventTypes: loaded 5982 events from ./log/eventTypes.txt
2020.12.18 19:15:55 3: FRM_Client_Define Alarmanlage.Alarm=-9
2020.12.18 19:15:55 3: FRM_Client_Define Alarmanlage.Scharf=-9
2020.12.18 19:15:59 3: FRM_Client_Define Alarmanlage.An=-9
2020.12.18 19:15:59 3: FRM_Client_Define Alarmanlage.Aus=-9
2020.12.18 19:15:59 1: [Alarm_Define] data hash restored from save file with date 2020-05-02 21:49:01
2020.12.18 19:15:59 3: FRM_Client_Define Alarmanlage.An.Intern=-9
2020.12.18 19:15:59 3: FRM_Client_Define Alarmanlage.Aus.Intern=-9
2020.12.18 19:16:10 3: FRM_Get_Device_Firmata_Status=-1
2020.12.18 19:16:10 2: FirmataWifi WARNING: Perl module Device::Firmata version 0.69 or higher required, see Commandref for details how to fix
2020.12.18 19:16:10 3: FRM_Define FirmataWifi=1
2020.12.18 19:16:10 1: Including ./log/fhem.save
2020.12.18 19:16:10 3: FirmataWifi: port 3030 opened
2020.12.18 19:16:10 0: Featurelevel: 6
2020.12.18 19:16:10 0: Server started with 257 defined entities (fhem.pl:23306/2020-12-07 perl:5.028001 os:linux ...)
2020.12.18 19:16:17 1: 192.168.0.100:1883 reappeared (MQTT_Broker)
2020.12.18 19:16:18 2: AttrTemplates: got 234 entries
2020.12.18 19:16:20 3: FirmataWifi: querying Firmata versions
2020.12.18 19:16:20 3: FirmataWifi: Firmata Firmware Version StandardFirmataWiFi.ino V_2_05 (using Protocol Version V_2_05)
2020.12.18 19:16:20 1: Alarmanlage.Alarm ERROR: init failed, Perl module Device::Firmata not properly installed
2020.12.18 19:16:20 1: Alarmanlage.An ERROR: init failed, Perl module Device::Firmata not properly installed
2020.12.18 19:16:20 1: Alarmanlage.An.Intern ERROR: init failed, Perl module Device::Firmata not properly installed
2020.12.18 19:16:20 1: Alarmanlage.Aus ERROR: init failed, Perl module Device::Firmata not properly installed
2020.12.18 19:16:20 1: Alarmanlage.Aus.Intern ERROR: init failed, Perl module Device::Firmata not properly installed
2020.12.18 19:16:20 1: Alarmanlage.Scharf ERROR: init failed, Perl module Device::Firmata not properly installed


Und jetzt das Log aber Firmata von FHEM gelöscht. von CPAN ist die 0.69 systemweit installiert (war sie beim vorherigen Versuch übrigens auch schon). Meine Vermutung ist, das FirmataWifi noch die 0.69 nimmt, FRM_IN dann aber die 0.64, da beides installiert ist. Vielleicht


2020.12.18 19:17:24 1: Including fhem.cfg
2020.12.18 19:17:24 2: eventTypes: loaded 5982 events from ./log/eventTypes.txt
2020.12.18 19:17:25 3: FRM_Client_Define Alarmanlage.Alarm=-9
2020.12.18 19:17:25 3: FRM_Client_Define Alarmanlage.Scharf=-9
2020.12.18 19:17:28 3: FRM_Client_Define Alarmanlage.An=-9
2020.12.18 19:17:28 3: FRM_Client_Define Alarmanlage.Aus=-9
2020.12.18 19:17:28 1: [Alarm_Define] data hash restored from save file with date 2020-05-02 21:49:01
2020.12.18 19:17:28 3: FRM_Client_Define Alarmanlage.An.Intern=-9
2020.12.18 19:17:28 3: FRM_Client_Define Alarmanlage.Aus.Intern=-9
2020.12.18 19:17:39 3: FRM_Get_Device_Firmata_Status=1
2020.12.18 19:17:39 3: FRM_Define FirmataWifi=1
2020.12.18 19:17:39 1: Including ./log/fhem.save
2020.12.18 19:17:39 3: FirmataWifi: port 3030 opened
2020.12.18 19:17:39 0: Featurelevel: 6
2020.12.18 19:17:39 0: Server started with 257 defined entities (fhem.pl:23306/2020-12-07 perl:5.028001 os:linux ...)
2020.12.18 19:17:46 1: 192.168.0.100:1883 reappeared (MQTT_Broker)
2020.12.18 19:17:46 2: AttrTemplates: got 234 entries
2020.12.18 19:17:49 3: FirmataWifi: querying Firmata versions
2020.12.18 19:17:49 3: FirmataWifi: Firmata Firmware Version StandardFirmataWiFi.ino V_2_05 (using Protocol Version V_2_05)
2020.12.18 19:17:49 1: Alarmanlage.Alarm ERROR: init failed, Perl module Device::Firmata not properly installed
2020.12.18 19:17:49 1: Alarmanlage.An ERROR: init failed, Perl module Device::Firmata not properly installed
2020.12.18 19:17:49 1: Alarmanlage.An.Intern ERROR: init failed, Perl module Device::Firmata not properly installed
2020.12.18 19:17:49 1: Alarmanlage.Aus ERROR: init failed, Perl module Device::Firmata not properly installed
2020.12.18 19:17:49 1: Alarmanlage.Aus.Intern ERROR: init failed, Perl module Device::Firmata not properly installed
2020.12.18 19:17:49 1: Alarmanlage.Scharf ERROR: init failed, Perl module Device::Firmata not properly installed


jensb

Hallo BlackFlag,

danke für die Logauszüge, damit ist mir endlich klar woher das Problem kommt. Bei dir wird der Define für die Firmata-Client-Devicess (FRM_Client_Define Alarmanlage.*) vor dem IODev (FRM_Define) ausgeführt. Ich bin aber davon ausgegangen, dass das IODev immer vor den Clients definiert wird und habe das zur Performance-Optimierung genutzt. Das ist aber offensichtlich nicht der Fall, sondern hängt scheinbar von der Alpha-Sortierung der FHEM-Devicenamen ab.

Werde das ändern und eine weitere Testversion posten.

Grüße,
Jens
FHEM 6.1 - RPi 4 Raspbian 12 + PiTFT - OPi Zero Armbian 5.35
EnOcean - (W)LAN/Firmata: BMP180, TSL2561, SHT21, Heatronic 3, OBIS - WLAN/ESP8266: Gardena 1251, Zirkulationspumpe - RTL433: Oregon - Bluetooth - MQTT
Contributions: https://svn.fhem.de/trac/browser/trunk/fhem/contrib/jensb

jensb

Hallo BlackFlag,

die beigefügte Version von 10_FRM.pm sollte das Problem der FRM-Clients "ERROR: init failed, Perl module Device::Firmata not properly installed" lösen, dass auftreten kann, wenn man von einer alten Version von Device::Firmata auf die aktuelle Version umstellt.

Es würde mir sehr helfen, wenn du den gleichen Test wiederholst, den du zuletzt gemacht hast. Diesmal müsste es bei der neuen Version sofort klappen, ohne dass du die Pinzuordnung ändern musst. Logauszüge brauche ich nur, falls es doch nicht klappen sollte.

Grüße,
Jens
FHEM 6.1 - RPi 4 Raspbian 12 + PiTFT - OPi Zero Armbian 5.35
EnOcean - (W)LAN/Firmata: BMP180, TSL2561, SHT21, Heatronic 3, OBIS - WLAN/ESP8266: Gardena 1251, Zirkulationspumpe - RTL433: Oregon - Bluetooth - MQTT
Contributions: https://svn.fhem.de/trac/browser/trunk/fhem/contrib/jensb

BlackFlag

So, habs getestet. Mit der neuen Version funktioniert wieder alles. Vielen Dank, Jens.

Viele Grüße. Christian

jensb

Die neue Version von 10_FRM.pm, die den von @golem und @BlackFlag gemeldeten Fehler der Device::Firmata-Erkennung behebt, wird ab morgen per FHEM-Update verfügbar sein.

Gleichzeitig wird die alte Version 0.64 von Device::Firmata nicht mehr per FHEM-Update verteilt. Die neue Version 0.69 steht über CPAN zur Installation bereit.

Wer noch eine "alte" Version von Device::Firmata im Unterverzeichnis FHEM/lib/Device hat, muss manuell aufräumen. Mehr dazu unter Punkt 1 des 1. Posts. Die Installation der neuen Version wird auch in der Modulhilfe von FRM und in der Wiki beschrieben.

Noch mal vielen Dank an alle Tester für eure Rückmeldungen!

Grüße,
Jens
FHEM 6.1 - RPi 4 Raspbian 12 + PiTFT - OPi Zero Armbian 5.35
EnOcean - (W)LAN/Firmata: BMP180, TSL2561, SHT21, Heatronic 3, OBIS - WLAN/ESP8266: Gardena 1251, Zirkulationspumpe - RTL433: Oregon - Bluetooth - MQTT
Contributions: https://svn.fhem.de/trac/browser/trunk/fhem/contrib/jensb

fstefan1960

Hallo,

zunächst herzlichen Dank für all die Arbeit und das tolle Ergebnis.

Ich habe noch eine Frage, die ich trotz einigermaßen intensiver Suche im Netz nicht beantwortet bekomme:

Gibt es auch eine "apt install" - Alternative zu CPAN für Firmata? Ganz oft kann man ja alternatov lis per apt installieren. Das wäre mir deutlich lieber.

Vielen Dank
FHEM auf PC: CUL868, CUL 443, HM_LAN, JeeLink
FHEM auf Raspi: CUL868
div. LaCrosse Temp/Hum-Sensoren, HM-Heizkörperventile, Schaltaktoren, etc.

jensb

ZitatGibt es auch eine "apt install" - Alternative zu CPAN für Firmata?
Nein.

Die verschiedenen Linux-Distributionen stellen im Normalfall die relative überschaubare Anzahl von "Core" Perl Modulen und ein paar weitere über die jeweilige Paketverwaltung zur Verfügung. Alle anderen Perl-Module (ca. 250.000) installiert man sich z.B. mit dem Perl-Installer CPAN. Perl gibt es auch für andere Plattformen als Linux und auf diese Weise ist das Vorgehen beim Installieren für Perl-Nutzer weitgehend plattformunabhängig.

Grüße,
Jens
FHEM 6.1 - RPi 4 Raspbian 12 + PiTFT - OPi Zero Armbian 5.35
EnOcean - (W)LAN/Firmata: BMP180, TSL2561, SHT21, Heatronic 3, OBIS - WLAN/ESP8266: Gardena 1251, Zirkulationspumpe - RTL433: Oregon - Bluetooth - MQTT
Contributions: https://svn.fhem.de/trac/browser/trunk/fhem/contrib/jensb

presskopf

#34
@jensb
Danke für die ganz tolle Arbeit.
Besonders gut gefallen mir auch die neuen Attribute ping-interval und receiveTimeout. Ich hatte nur mit Deinem Code-Schnipsel ein paar Probleme.
client.status und ESTABLISHED waren unbekannt.

Ich habe mit folgenden Änderungen allerdings Erfolg:

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

Habe ich was Grundlegendes übersehen oder war da nur ein Tippfehler bei Dir?

jensb

Hallo presskopf,

habe nicht herausfinden können, wo ich das von dir modifizierte Ping-Beispiel mal gepostet habe, so dass ich nicht vergleichen kann. Egal, es ist jedenfalls Arduino-Code und kein FHEM-Code.

ZitatHabe ich was Grundlegendes übersehen oder war da nur ein Tippfehler bei Dir?

Es kommt dabei auf die Firmata-Variante an. Habe mal in einem bei mir laufenden Projekt nachgesehen, das auf StandardFirmataWiFi basiert und auf den ESP8266 angepasst ist. Da sieht der Code so aus:

#define PING_PERIOD 20000 // [ms]
unsigned long currentMillis;
unsigned long pingSent = 0;
...
void loop()
{
  currentMillis = millis();
  ...
  if (stream.status() == ESTABLISHED && (currentMillis - pingSent) >= PING_PERIOD)
  {
    // send some data to detect loss of connection indirectly
    sprintf(message, "ping (RSSI %d dBm)", WiFi.RSSI());   
    Firmata.sendString(message);
    pingSent = currentMillis;
  }
}


Die Variable stream wird bei StandardFirmataWiFi in der wifiConfig.h definiert und ist bei mir ein WiFiClientStream.

Wenn man statt dessen z.B. auf StandardFirmataEthernet aufbaut oder auf ConfigurableFimata hat man es mit anderen Verbingdungsobjekten zu tun, die dann auch etwas anders angesprochen werden müssen.

Wenn es bei dir so funktioniert ist das schon mal mehr als die halbe Miete. Wenn du noch 7 Codezeichen einsparen willst, könntest du "== true" weglassen. ;)

Grüße,
Jens
FHEM 6.1 - RPi 4 Raspbian 12 + PiTFT - OPi Zero Armbian 5.35
EnOcean - (W)LAN/Firmata: BMP180, TSL2561, SHT21, Heatronic 3, OBIS - WLAN/ESP8266: Gardena 1251, Zirkulationspumpe - RTL433: Oregon - Bluetooth - MQTT
Contributions: https://svn.fhem.de/trac/browser/trunk/fhem/contrib/jensb

Skusi

Hallo,
ich bin gerade dabei mein Logfile zu säubern.

Dabei ist mir folgendes aufgefallen:

PERL WARNING: Use of uninitialized value $pin in hash element at /usr/local/share/perl/5.28.1/Device/Firmata/Platform.pm line 1210.
2022.12.10 13:10:37 1: stacktrace:
2022.12.10 13:10:37 1:     main::__ANON__                      called by /usr/local/share/perl/5.28.1/Device/Firmata/Platform.pm (1210)
2022.12.10 13:10:37 1:     Device::Firmata::Platform::is_configured_mode called by /usr/local/share/perl/5.28.1/Device/Firmata/Platform.pm (586)
2022.12.10 13:10:37 1:     Device::Firmata::Platform::digital_write called by ./FHEM/20_FRM_OUT.pm (165)
2022.12.10 13:10:37 1:     (eval)                              called by ./FHEM/20_FRM_OUT.pm (164)
2022.12.10 13:10:37 1:     main::FRM_OUT_Set                   called by fhem.pl (3971)
2022.12.10 13:10:37 1:     main::CallFn                        called by fhem.pl (1964)
2022.12.10 13:10:37 1:     main::DoSet                         called by fhem.pl (1996)
2022.12.10 13:10:37 1:     main::CommandSet                    called by fhem.pl (1276)
2022.12.10 13:10:37 1:     main::AnalyzeCommand                called by fhem.pl (1127)
2022.12.10 13:10:37 1:     main::AnalyzeCommandChain           called by fhem.pl (4016)
2022.12.10 13:10:37 1:     main::fhem                          called by ./FHEM/93_PWMR.pm (956)
2022.12.10 13:10:37 1:     main::PWMR_SetRoom                  called by ./FHEM/94_PWM.pm (603)
2022.12.10 13:10:37 1:     main::PWM_Calculate                 called by fhem.pl (3501)
2022.12.10 13:10:37 1:     main::HandleTimeout                 called by fhem.pl (705)


Das kommt bei jedem Neustart 8 mal vor.

Ich steuere mit 8 FRM_OUT Modulen meinen Heizkreisverteiler der Fußbodenheizung.

Kann jemand helfen das zu beheben ???
RPI3B, SIGNALduino, NanoCul868 (a-culfw), JeeLink Clone (LaCrosse), Firmata  für FB Heizung,Wasser+Gas+Klingel+Lux, Somfy Rolladen, Pollin Steckd.,TX29DTH,ESPEasy an S0 Stromz., MAX Fensterkontakte, IButton, SonOff Tasmota, ESP LED Controler

jensb

Hallo Skusi,

da es beim Neustart passiert, besteht zum Zeitpunkt des Fehlers wahrscheinlich noch keine Verbindung zwischen FHEM und dem Firmata Device. Hier meckert der Perl-Firmata Treiber und nicht FHEM, dass es den Pin (noch) nicht gibt und das stimmt aus dessen Perspektive auch. Das Modul PWM weiß nichts von diesen Zusammenhängen und setzt einfach den Ausgang, bevor die Verbindung da ist.

Dein Ablauf müssen an irgendeiner Stelle entkoppelt werden.

PWM hat scheinbar keinen Perl-Code-Support und scheidet daher aus.

Wenn man das im Modul FRM_OUT macht, entspricht der angezeigte State dann u.U. nicht dem des Devices. Könnte ich mir über die verbleibende Weihnachtszeit vornehmen.

Als Schnelllösung könntest du aber auch ein Dummy und ein Notify kombinieren. Dein PWM steuert das Dummy on/off. Der Notify regiert auf das Dummy und du verwendest eval {} im Notify, um den Fehler abzufangen.

Grüße,
Jens
FHEM 6.1 - RPi 4 Raspbian 12 + PiTFT - OPi Zero Armbian 5.35
EnOcean - (W)LAN/Firmata: BMP180, TSL2561, SHT21, Heatronic 3, OBIS - WLAN/ESP8266: Gardena 1251, Zirkulationspumpe - RTL433: Oregon - Bluetooth - MQTT
Contributions: https://svn.fhem.de/trac/browser/trunk/fhem/contrib/jensb

JensS

#38
Mal ins Blaue geschossen - kann es sein, das mehrere FRM existieren und dem Pin-Device kein IODev-Attribut zu geordnet ist? Dann würde der Perl-Firmata Treiber anfangs an der falschen Stelle suchen.
Ist das denkbar?

Gruß Jens
Debian auf APU2C4, HM-CFG-USB2, SIGNALduino, HM-ES-PMSw1-Pl, TFA 30.3121, TFA 30.3125, ITS-150, PIR-5000, configurable Firmata USB & LAN, 1-wire: DS-18B20, DS-18S20, DS-2408, DS-2413, diverse I2C-Komponenten, zigbee2mqtt, ESPEasy etc.

jensb

#39
Zitat... kann es sein, das mehrere FRM existieren und dem Pin-Device kein IODev-Attribut zu geordnet ist?

Das ist bei Firmata nicht so. Ob es einen Pin gibt oder nicht, kann vom Host (hier: FHEM) erst nach dem Connect ermittelt werden. Das Firmata Device sendet auf Anfrage seine Metadaten und erst dann kann der Host feststellen, ob ein konfigurierter Pin auch physikalisch möglich ist. Das hat damit zu tun, dass man Firmata im Prinzip auf jeder Arduino Hardware und auch auf nicht-Arduinos installieren kann. Die dabei in Frage kommenden MCU haben völlig unterschiedliche Anzahl von digitalen, analogen und speziellen I/Os.

Solange dieser Ablauf nicht durch ist, sagt der Treiber "nein", wenn man versucht auf einen Pin zuzugreifen.

Es ist natürlich vorstellbar, dass IODev am FRM_OUT nicht explizit gesetzt ist und mehrere FRM-Module vorhanden sind, aber dann würde es wahrscheinlich auch nach dem Neustart noch zu Fehlern kommen.
FHEM 6.1 - RPi 4 Raspbian 12 + PiTFT - OPi Zero Armbian 5.35
EnOcean - (W)LAN/Firmata: BMP180, TSL2561, SHT21, Heatronic 3, OBIS - WLAN/ESP8266: Gardena 1251, Zirkulationspumpe - RTL433: Oregon - Bluetooth - MQTT
Contributions: https://svn.fhem.de/trac/browser/trunk/fhem/contrib/jensb