Wie kann ich einige S0-Zähler mit fhem auf einer Fritz!Box 7390 auslesen?

Begonnen von Christian., 03 Juni 2013, 15:29:39

Vorheriges Thema - Nächstes Thema

Christian.

Ein weiteres Problem ist gelöst: der Aufruf von update stable check wird wohl (derzeit) nicht unterstützt. Dann bleibt mir ja noch die Möglichkeit, den development-Zweig auszuprobieren.
Raspberry Pi 3 mit FHEM; Arduino Nano mit ConfigurableFirmata (S0-Stromzähler); nanoCUL (MAX!); SIGNALduino (RXB6, 433 MHz); eBus; RS485 & D0 (SolarView); DVB-T (Thermo-/Hygrometer); Z-Wave; ZigBee

Christian.

Ich habe jetzt ein update development fhem durchgeführt, am Verhalten hat sich aber nichts geändert. Auf der Firmata-Detail-Seite enthält die Dropdown-Box für die erlaubten set-Befehle immer noch eine Fehlermeldung.
Raspberry Pi 3 mit FHEM; Arduino Nano mit ConfigurableFirmata (S0-Stromzähler); nanoCUL (MAX!); SIGNALduino (RXB6, 433 MHz); eBus; RS485 & D0 (SolarView); DVB-T (Thermo-/Hygrometer); Z-Wave; ZigBee

Christian.

Auf der Details-Seite zum Modul FRM ist die set-Liste ja falsch befüllt. Ich habe mal ausgeben lassen, wer den set-Aufruf macht und was übergeben wird. Das Argument ist das Fragezeichen (Hex 3F), und der Aufruf-Stack lautet2013.07.08 07:12:45 3: /usr/bin/fhem.pl:1185 in function main::CallFn
2013.07.08 07:12:45 3: /usr/bin/fhem.pl:1218 in function main::DoSet
2013.07.08 07:12:45 3: /usr/bin/fhem.pl:1735 in function main::CommandSet
2013.07.08 07:12:45 3: /usr/share/fhem/FHEM/01_FHEMWEB.pm:824 in function main::getAllSets
2013.07.08 07:12:45 3: /usr/share/fhem/FHEM/01_FHEMWEB.pm:583 in function main::FW_doDetail
2013.07.08 07:12:45 3: /usr/share/fhem/FHEM/01_FHEMWEB.pm:308 in function main::FW_answerCall
2013.07.08 07:12:45 3: /usr/bin/fhem.pl:2448 in function main::FW_Read
2013.07.08 07:12:45 3: /usr/bin/fhem.pl:479 in function main::CallFn
Kann damit jemand was anfangen? Verwendet evtl. FHEMWEB ein falsches Argument?
Raspberry Pi 3 mit FHEM; Arduino Nano mit ConfigurableFirmata (S0-Stromzähler); nanoCUL (MAX!); SIGNALduino (RXB6, 433 MHz); eBus; RS485 & D0 (SolarView); DVB-T (Thermo-/Hygrometer); Z-Wave; ZigBee

Christian.

Ich schätze, ich hab's schon selbst gefunden. In 10_FRM sollte Zeile 117 wie folgt geändert werdenreturn "Unknown argument $a[1], choose one of reset reinit";Denn fhem.pl prüft auf den String "choose one of ".

Jetzt bleibt nur noch das Hauptproblem, dass FRM_IN keine Werte erhält.
Raspberry Pi 3 mit FHEM; Arduino Nano mit ConfigurableFirmata (S0-Stromzähler); nanoCUL (MAX!); SIGNALduino (RXB6, 433 MHz); eBus; RS485 & D0 (SolarView); DVB-T (Thermo-/Hygrometer); Z-Wave; ZigBee

ntruchsess

ja, das ist der Grund für die fehlerhafte Anzeige der set-werte im Web-gui. Ist natürlich eher ein kosmetisches Problem, ich habs trotzdem endlich mal behoben und ins svn committed.

Für das FRM_IN-modul habe ich auch ein Paar Anpassungen für die Verwendung des Zählers vorgenommen, bitte probiere das mal aus. (aus dem svn auschecken oder per 'update development' installieren).

Unter Anderem wird der Zähler jetzt gleich auf 0 initialisiert, wenn man das Attribute count-mode setzt. Weiterhin kann man jetzt per 'attr reset-on-threshold-reached yes' den Zähler bei Erreichen des per 'attr count-threshold <x>' setzbaren Grenzwert automatisch zurücksetzen lassen.

Gruß,

Norbert
while (!asleep()) {sheep++};

Christian.

Hallo Norbert,

zuerst nochmal vielen Dank für Deinen Einsatz.

Ich habe die beiden Module FRM und FRM_IN aus dem Subversion-Repository heruntergeladen und eingebunden. update development hatte ich auch versucht, da wurden aber keine Updates angezeigt.

Ich kann aber nach startfhem shutdown restart, reload FRM und reload FRM_IN leider überhaupt keinen Unterschied im Verhalten feststellen. Auch das Log sieht unverändert aus. Das neue Attribut reset-on-threshold-reached kann ich aber sehen.

Hier nochmal ein paar aktuelle Screenshots:

(siehe Anhang / see attachement)


(siehe Anhang / see attachement)

2013.07.08 21:06:19 1: arduino_pin_02_frm is against deletion (2), continuing with rereadcfg anyway
2013.07.08 21:06:19 1: /dev/ttyACM0 disconnected, waiting to reappear
2013.07.08 21:06:19 1: Including /etc/fhem.cfg
2013.07.08 21:06:19 3: telnetPort: port 7072 opened
2013.07.08 21:06:19 3: WEB: port 8083 opened
2013.07.08 21:06:19 3: WEBphone: port 8084 opened
2013.07.08 21:06:19 3: WEBtablet: port 8085 opened
2013.07.08 21:06:19 3: Opening fbaha device localhost:2002
2013.07.08 21:06:19 3: Can't connect to localhost:2002: Connection refused
2013.07.08 21:06:19 3: Opening FIRMATA device /dev/ttyACM0
2013.07.08 21:06:19 3: Setting FIRMATA baudrate to 57600
2013.07.08 21:06:19 3: FIRMATA device opened
2013.07.08 21:06:22 3: querying Firmata Firmware Version
2013.07.08 21:06:22 3: Firmata Firmware Version: ConfigurableFirmata.ino V_2_05
2013.07.08 21:06:24 3: >d0,01
2013.07.08 21:06:24 3: SW: �
2013.07.08 21:06:24 3: >f4,02,00
2013.07.08 21:06:24 3: SW: �
2013.07.08 21:06:24 1: Including /var/log/fhem/fhem.save
2013.07.08 21:06:24 3: <92,01,00
2013.07.08 21:06:26 3: <92,00,00
2013.07.08 21:06:28 3: <92,01,00
2013.07.08 21:06:30 3: <92,00,00

Wo muss ich denn fürs Debugging ansetzen? Da die Signale es bis ins Log schaffen, wird FRM wohl funktionieren. Ich habe aber noch nicht verstanden, wie die Übergabe zwischen FRM und FRM_IN abläuft. Da könnte ich doch vielleicht noch ein paar Log-Ausgaben einbauen, um der Sache auf die Spur zu kommen.
Raspberry Pi 3 mit FHEM; Arduino Nano mit ConfigurableFirmata (S0-Stromzähler); nanoCUL (MAX!); SIGNALduino (RXB6, 433 MHz); eBus; RS485 & D0 (SolarView); DVB-T (Thermo-/Hygrometer); Z-Wave; ZigBee

ntruchsess

hm... das ist ja echt verblüffend.

im FRM_IN gibt es die sub FRM_IN_observer, die wird im FRM_IN_Init mit $firmata->observe_digital($hash->{PIN},\&FRM_IN_observer,$hash); im perl-firmata-device registriert.

Bei Eingang einer digital-message wird die Methode dann von perl-firmata in der methode Device::Firmata::Platform::messages_handle() aufgerufen.

Wenn beim registrieren (aufruf von observer_digital) die methode Device::Firmata::Platform::is_supported_mode feststellt, dass der Mode an diesem Pin gar nicht geht, dann sollte dieser Fehler per 'die' bis in die Methode 10_FRM::FRM_Init_Pin_Client hochkommen, der per eval abgefangen werden und zu einer Logausgabe (loglevel 2) führen.

Kann gut sein, dass es daran liegt. Deine FRM details Seite listed auch gar keine supported Pinmodes auf. Hast Du vieleicht das Firmata_Ext aus der ConfigurableFirmata auskommentiert?

Gruß,

Norbert



while (!asleep()) {sheep++};

Christian.

Ja, das war ein guter Hinweis. Natürlich habe ich alles bis auf DigitalInputFirmata aus ConfigurableFirmata entfernt, weil ich für die S0-Zähler sonst nichts brauche. Jetzt habe ich mal alles drin gelassen und bekomme einen (vermutlich den von Dir prophezeiten) Fehler:

(siehe Anhang / see attachement)


Jetzt muss ich vermutlich noch den pin mode setzen? Wäre das im Arduino-Sketch?
Raspberry Pi 3 mit FHEM; Arduino Nano mit ConfigurableFirmata (S0-Stromzähler); nanoCUL (MAX!); SIGNALduino (RXB6, 433 MHz); eBus; RS485 & D0 (SolarView); DVB-T (Thermo-/Hygrometer); Z-Wave; ZigBee

ntruchsess

Zitat von: fhem-user schrieb am Mo, 08 Juli 2013 22:26Jetzt muss ich vermutlich noch den pin mode setzen? Wäre das im Arduino-Sketch?

Nein, das mach das FRM_IN-modul remote über das Firmata-protocol.

Wenn das nur im Sketch gemacht wird, dann weiß FRM bzw. FRM_IN da ja nix von und ignoriert die Nachrichten.

(den 'Unknown Pin Mode'-error in den FRM-details kannst Du erst mal ignorieren, der kommt daher, dass in der Systemreset-methode des Sketches irrtümlich auch pin 0 und 1 initialisiert werden)

Gruß,

Norbert
while (!asleep()) {sheep++};

Christian.

Hallo Norbert,

ich habe jetzt noch ein paar Log-Statements eingebaut und komme der Sache langsam auf die Spur. Es scheint, als würden bei eingehenden Nachrichten andere Observer informiert als der registrierte.
Initialisierung:

2013.07.09 06:57:34 3: >f0,7a,68,07,f7
2013.07.09 06:57:34 3: SW: �zh�
2013.07.09 06:57:34 3: Platform::is_supported_mode(pin=2)?
2013.07.09 06:57:34 3: Platform::is_supported_mode(pin=2): yes, still alive
2013.07.09 06:57:34 3: >d0,01
2013.07.09 06:57:34 3: SW: �
2013.07.09 06:57:34 3: >f4,02,00
2013.07.09 06:57:34 3: SW: �
2013.07.09 06:57:34 3: observe_digital
2013.07.09 06:57:34 3: Platform::observe_digital(pin=2)
2013.07.09 06:57:34 3: Platform::is_supported_mode(pin=2)?
2013.07.09 06:57:34 3: Platform::is_supported_mode(pin=2): yes, still alive
2013.07.09 06:57:34 3: Platform::observe_digital: is supported(pin=2, observer=CODE(0xbb1d00))

Bei jeder eingehenden Nachricht:

2013.07.09 06:57:52 3: <92,01,00
2013.07.09 06:57:52 3: Platform::messages_handle
2013.07.09 06:57:52 3: Platform::messages_handle: command DIGITAL_MESSAGE
2013.07.09 06:57:52 3: Platform::messages_handle: port_number = 2
2013.07.09 06:57:52 3: Platform::messages_handle: observers = ARRAY(0xb97018)
2013.07.09 06:57:52 3: Platform::messages_handle: pinbase=16
2013.07.09 06:57:52 3: Platform::messages_handle: pin=16
2013.07.09 06:57:52 3: Platform::messages_handle: observer is undefined
2013.07.09 06:57:52 3: Platform::messages_handle: pin=17
2013.07.09 06:57:52 3: Platform::messages_handle: observer is undefined
2013.07.09 06:57:52 3: Platform::messages_handle: pin=18
2013.07.09 06:57:52 3: Platform::messages_handle: observer is undefined
2013.07.09 06:57:52 3: Platform::messages_handle: pin=19
2013.07.09 06:57:52 3: Platform::messages_handle: observer is undefined
2013.07.09 06:57:52 3: Platform::messages_handle: pin=20
2013.07.09 06:57:52 3: Platform::messages_handle: observer is undefined
2013.07.09 06:57:52 3: Platform::messages_handle: pin=21
2013.07.09 06:57:52 3: Platform::messages_handle: observer is undefined
2013.07.09 06:57:52 3: Platform::messages_handle: pin=22
2013.07.09 06:57:52 3: Platform::messages_handle: observer is undefined
2013.07.09 06:57:52 3: Platform::messages_handle: pin=23
2013.07.09 06:57:52 3: Platform::messages_handle: observer is undefined

Ich hoffe, es ist soweit klar, wo ich die Log-Ausgaben gesetzt habe.

Ich verstehe nicht: weshalb werden hier die Observer der Pins 16-23 überprüft?

Hier nochmal der Sende-Vorgang im Arduino-Sketch:
   if (millis() - currentMillis > 2000) {
      Firmata.sendDigitalPort(2, low ? LOW : HIGH);
      low = !low;
      currentMillis = millis();
    }
Raspberry Pi 3 mit FHEM; Arduino Nano mit ConfigurableFirmata (S0-Stromzähler); nanoCUL (MAX!); SIGNALduino (RXB6, 433 MHz); eBus; RS485 & D0 (SolarView); DVB-T (Thermo-/Hygrometer); Z-Wave; ZigBee

ntruchsess

na jetzt is klar. Du sendest auf Port 2 (= pin 16-23) und lauscht auf Pin2 (= port 0). Ein Port (das ist ein Hardwareregister der MCU) fasst immer 8 Pins zusammen. Die 'digitalWrite/digitalRead'-methoden der Arduino-api setzen das Mapping Pin<->Port in Software um, unter der Haube wird immer ein 8-Bit Register gelesen/beschrieben. Weil man sowieso die Bits nicht einzeln lesen und auch nicht effektiv transportieren kann, wird im Firmata-Protocol immer ein ganzes Port-Byte übertragen. Schau mal im Sourcecode der DigitalInputFirmata klasse wie das gemappt wird.

Gruß,

Norbert
while (!asleep()) {sheep++};

Christian.

Ja super, das war's! Ich habe meinen Demo-Sketch geändert

    if (millis() - currentMillis > 2000) {
      // Find the correct port (each port holds 8 pins)
      byte portNumber = PIN_NUMBER / 8;
      // A pin is represented by a bit within the port
      // find this bit and set the current value
      byte portValue = (low ? LOW : HIGH) << (PIN_NUMBER % 8);
      Firmata.sendDigitalPort(portNumber, portValue);
      low = !low;
      currentMillis = millis();
    }

Jetzt hab ich eine blinkende Glühbirne - tausend Dank, Norbert!

Als nächstes werde ich dann die Umrechnung von Signalen in kWh angehen.

Eine Frage hab ich noch: den pinMode möchte ich nach der Testphase gern wieder auf INPUT_PULLUP setzen - kann ich das über Firmata von FHEM aus machen?

Raspberry Pi 3 mit FHEM; Arduino Nano mit ConfigurableFirmata (S0-Stromzähler); nanoCUL (MAX!); SIGNALduino (RXB6, 433 MHz); eBus; RS485 & D0 (SolarView); DVB-T (Thermo-/Hygrometer); Z-Wave; ZigBee

Christian.

Ich habe es jetzt fast geschafft: die Integration von S0-Zählern über einen Arduino ist möglich, ohne selbst Arduino-Code oder ein FHEM-Modul zu schreiben. Auf den Arduino kommt z.B. die ConfigurableFirmata, in FHEM genügt folgende Konfiguration:

# Firmata Basis-Modul für die Kommunikation mit dem Arduino
define FIRMATA FRM /dev/ttyACM0@57600
attr FIRMATA room Arduino

# Pin 2 als digitalen Eingang konfigurieren
define arduino_pin_02 FRM_IN 2
attr arduino_pin_02 alias Demo-Stromzähler
attr arduino_pin_02 room Arduino

# User-Readings zu Pin 2
# ----------------------
# 'time'  enthält den Zeitstempel des letzten Signals in Mikrosekunden-Genauigkeit;
#         wird zur Berechnung von 'power' benötigt, da sonst nur sehr grobe
#         Näherungswerte für die Leistung berechnet werden könnten
#         (nämlich "3600/n" wobei n eine natürliche Zahl ist, also z.B.
#         3600, 1800, 1200, 900, 720, 600, 514, 450, 400, 360, ...)
#
# 'power' enthält die gemessene Leistung (in Kilowatt)
#
attr arduino_pin_02 userReadings time:reading:.off { use Time::HiRes qw(time);; time();; }, power:reading:.off { use Time::HiRes qw(time);; sprintf("%.5f", 3.6 / (time() - OldValue("arduino_pin_02"))) . " kW";; }

# 'time' als STATE-Wert für Pin 2 festlegen
attr arduino_pin_02 stateFormat time

# Eine Log-Datei pro Tag für Pin 2, enthält nur 'power'-Einträge
define log_arduino_pin_02 FileLog %L/arduino_pin_02-%Y-%m-%d.log arduino_pin_02.power:.*
attr log_arduino_pin_02 alias Demo-Log
attr log_arduino_pin_02 room Arduino

# Diagramm zur Log-Datei von Pin 2
define weblink_pin_02 weblink fileplot log_arduino_pin_02:power4:CURRENT
attr weblink_pin_02 alias Demo-Diagramm
attr weblink_pin_02 room Arduino
attr weblink_pin_02 title "Demo-Stromzähler"


Im Webfrontend sieht das das so aus:

(siehe Anhang / see attachement)


Auszug aus dem Log:

2013-07-11_23:53:26 arduino_pin_02 power: 0.80755 kW
2013-07-11_23:53:31 arduino_pin_02 power: 0.75362 kW
2013-07-11_23:53:35 arduino_pin_02 power: 0.80159 kW
2013-07-11_23:53:39 arduino_pin_02 power: 0.80125 kW
2013-07-11_23:53:42 arduino_pin_02 power: 0.80501 kW
2013-07-11_23:53:47 arduino_pin_02 power: 0.79367 kW

Das FHEM-Modul IMPCOUNT und der zugehörige Arduino-Sketch sind damit überflüssig.

Ich möchte mich an dieser Stelle bei allen Beteiligten, insbesondere und ausdrücklich noch einmal bei Norbert, für die Unterstützung bedanken!

Einzig ungeklärt bleibt für mich, ob der pinMode über das FHEM-Firmata-Modul auf INPUT_PULLUP gesetzt werden kann; dazu habe ich noch nichts gefunden.
Raspberry Pi 3 mit FHEM; Arduino Nano mit ConfigurableFirmata (S0-Stromzähler); nanoCUL (MAX!); SIGNALduino (RXB6, 433 MHz); eBus; RS485 & D0 (SolarView); DVB-T (Thermo-/Hygrometer); Z-Wave; ZigBee

nusselt

fhem-user schrieb am Fr, 12 Juli 2013 00:01

# User-Readings zu Pin 2
# ----------------------
# 'time'  enthält den Zeitstempel des letzten Signals in Mikrosekunden-Genauigkeit;
#         wird zur Berechnung von 'power' benötigt, da sonst nur sehr grobe
#         Näherungswerte für die Leistung berechnet werden könnten
#         (nämlich "3600/n" wobei n eine natürliche Zahl ist, also z.B.
#         3600, 1800, 1200, 900, 720, 600, 514, 450, 400, 360, ...)
#
# 'power' enthält die gemessene Leistung (in Kilowatt)
#
attr arduino_pin_02 userReadings time:reading:.off { use Time::HiRes qw(time);; time();; }, power:reading:.off { use Time::HiRes qw(time);; sprintf("%.5f", 3.6 / (time() - OldValue("arduino_pin_02"))) . " kW";; }

Erstmal herzlichen Glückwunsch das Du es mit Hilfe von Norbert geschafft hast und die beiden Programme IMCOUNT und imcount.ino für fhem nicht benötigst. Gleichwohl kann imcount.ino weiter gute Dienste bei Anwendungen ohne fhem leisten. Denn es ist möglich, mittels imcount.ino die Impulse auf die Fritzbox-shell zu bringen und mit einem shellscript die Impulse mit einem Zeitstempel zu versehen und in eine log-Datei zuschreiben. Will sagen, imcount.ino hat weiterhin seine Berechtigung.

Wäre es möglich, das Du das o.g. attr userReadings erklärst? Was passiert bei time:reading:.off, power:reading:.off und sprintf(...)? Mir ist nicht klar, welche Zeitdifferenz Du zur Berechnung von Power heranziehst. Ist das die Differenz zwischen zwei abfallenden Flanken, w.s zwei Impulsen? Welche Rolle spielt dabei der Faktor 3600/n, Auflösung von 1 bis 60 min? Warum erfolgt die Übergabe der Werte(portnumber, portvalue(low?)) im demo-sketch bei > 2000 ms? Werden die millis und current millis ebenfalls an fhem übergeben oder werden die erst in fhem gebildet?

Christian.

Hallo HJü,

ZitatWas passiert bei time:reading:.off, power:reading:.off und sprintf(...)? Mir ist nicht klar, welche Zeitdifferenz Du zur Berechnung von Power heranziehst. Ist das die Differenz zwischen zwei abfallenden Flanken, w.s zwei Impulsen? Welche Rolle spielt dabei der Faktor 3600/n, Auflösung von 1 bis 60 min?
dann versuche ich mal, den Code zu erläutern.

time:reading:.off { use Time::HiRes qw(time);; time();; }Das User Reading time reagiert auf FHEM-Benachrichtigungen, die auf den regulären Ausdruck reading:.off passen ('.' steht für 1 beliebiges Zeichen, also z.B. auch 1 Leerzeichen). Diese Benachrichtigungen werden vom Firmata-Modul versendet, sobald vom Arduino ein LOW-Signal (0 V) eintrifft. HIGH-Signale hingegen werden ignoriert. Im zugehörigen Sketch ConfigurableFirmata wird ein LOW immer nur gesendet, wenn der vorige Wert HIGH war, das entspricht also einer fallenden Flanke.
use Time::HiRes qw(time);; erlaubt die Mikrosekunden-genaue Abfrage der Zeit über das Perl-Modul Time, ansonsten wäre der Zeitstempel nur sekundengenau. time();; ruft den aktuellen Zeitstempel vom System ab. Dieser Wert wird im Reading gespeichert. Wichtig ist auch die Zeile etwas weiter unten
attr arduino_pin_02 stateFormat timeDiese belegt den State des Gerätes arduino_pin_02 mit dem User Reading time. Der State ist gewissermaßen das Haupt-Reading; ich nutze hier aus, dass für den State nicht nur auf den aktuellen Wert, sondern auch auf den vorigen Wert zugegriffen werden kann.

power:reading:.off { use Time::HiRes qw(time);; sprintf("%.5f", 3.6 / (time() - OldValue("arduino_pin_02"))) . " kW";; }Ein User Reading namens power, das auf dieselben FHEM-Benachrichtigungen reagiert wie time, also auf fallende Flanken. Auch hier wird zunächst die Genauigkeit des Zeitstempels erhöht. Dann wird der Wert für power berechnet:
OldValue("arduino_pin_02"): den vorigen State laden; State enthält den Wert des User Readings time, das ergibt also den Zeitstempel der letzten fallenden Flanke.
  • Die aktuelle Zeit bestimmen und die Differenz bilden; damit haben wir die Dauer zwischen zwei fallenden Flanken in Sekunden, z.B. 2.345
  • Berechnung des Stromverbrauchs. Der Stromzähler gibt 1 Signal pro Wh ab, also 1000 Signale pro kWh; eine Stunde hat 3600 Sekunden. Aus der gemessenen Dauer (x Sekunden) berechne ich die momentane Leistung p in kW:
       p kW = 1 Wh / x s
    <=> p kW = 3600 Wh / x * 3600s
    <=> p kW = 3,6 kWh / x * 1h
    <=> p kW = 3,6 kW / x
    <=> p = 3,6/x
  • sprintf("%.5f", ...: Das Ergebnis wird bei 5 Nachkommastellen abgeschnitten und in einen String umgewandelt.
  • . " kW": Einheit ergänzen (falls man später vielleicht mal auf Wh umstellt oder so).[/list]
    ZitatWarum erfolgt die Übergabe der Werte(portnumber, portvalue(low?)) im demo-sketch bei > 2000 ms?
    Das ist ein willkürlicher Wert, den ich zum Testen gewählt habe; er entspricht einem Verbrauch von ca. 1800 W. Sobald ein Stromzähler angeschlossen wird, ist der komplette if-Block überflüssig; dann kann die ConfigurableFirmata unverändert verwendet werden.

    ZitatWerden die millis und current millis ebenfalls an fhem übergeben oder werden die erst in fhem gebildet?
    In impcount.ino wurde die Dauer zwischen zwei Flanken noch vom Arduino berechnet; in der aktuellen Variante geschieht das wie oben beschrieben durch FHEM.
    Raspberry Pi 3 mit FHEM; Arduino Nano mit ConfigurableFirmata (S0-Stromzähler); nanoCUL (MAX!); SIGNALduino (RXB6, 433 MHz); eBus; RS485 & D0 (SolarView); DVB-T (Thermo-/Hygrometer); Z-Wave; ZigBee