Neuigkeiten:

Am Sonntag den 8.12.2024 kann es ab ca. 8:00 Uhr zu kurzzeitigen Einschränkungen / Ausfällen bei den Diensten des FHEM Vereines kommen.
Die Server müssen mal gewartet und dabei neu gestartet werden ;)

Hauptmenü

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

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

Vorheriges Thema - Nächstes Thema

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