FHEM2FHEM überträgt state nicht korrekt

Begonnen von clumsy, 04 September 2017, 21:02:19

Vorheriges Thema - Nächstes Thema

clumsy

Hallo

ich hab 2 fhem instanzen, eine remote instanz läuft einem RPI und liest I2C sensoren aus. Die Hauptinstanz auf dem server verbindet sich mit:
define fhem_raspi_1 FHEM2FHEM raspi-1.clumsy.ch LOG:.*
per FHEM2FHEM auf den RPI.

Auf der Remote-Instanz ist ein Sensor definiert:
list bme280_innen
Internals:
   DEF        0x77
   DeviceType BME280
   I2C_Address 119
   IODev      i2c_bus
   NAME       bme280_innen
   NR         23
   STATE      T: 31.0 H: 33.8 P: 974.1 P-NN: 1018.6
   TYPE       I2C_BME280
   i2c_bus_SENDSTAT Ok
   READINGS:
     2017-09-04 20:55:12   humidity        33.8
     2017-09-04 20:55:12   pressure        974.1
     2017-09-04 20:55:12   pressure-nn     1018.6
     2017-09-04 20:55:12   state           T: 31.0 H: 33.8 P: 974.1 P-NN: 1018.6
     2017-09-04 20:55:12   temperature     31.0
[... calibration data deleted...]
Attributes:
   IODev      i2c_bus
   poll_interval 1

welcher soweit korrekt funktioniert.

auf der server instanz ist ein device mit gleichem Namen definiert, die einzelnen Readings werden auch korrekt übernommen ausser dem state:
list bme280_innen
Internals:
   CFGFN      /etc/fhem/raspi-1.cfg
   NAME       bme280_innen
   NR         181
   STATE      ???
   TYPE       dummy
   READINGS:
     2017-09-04 20:55:12   T               31.0 H: 33.8 P: 974.1 P-NN: 1018.6
     2017-09-04 20:55:12   humidity        33.8
     2017-09-04 20:55:12   pressure        974.1
     2017-09-04 20:55:12   pressure-nn     1018.6
     2017-09-04 20:55:12   temperature     31.0
Attributes:

Der state scheint aufgesplittet zu werden. und ein "T" reading entsteht... etwas unschön.... scheint mir ein Bug zu sein? Oder mach ich da was falsch?


franky08

In deiner remote instanz gibt es doch auch das Reading T... du musst mittels regex dieses Reading "aussperren" indem du in der Log def nur die Readings setzt die du haben möchtest.

VG
Frank
Debian Wheezy auf ZBOX nano/ Debian Bullseye auf 2.ter ZBOX nano F2F an 2x RaspiB
22Zoll ViewSonic als Infodislay (WVC)
3xHMLAN mit vccu ,fhem5.8, CCU2,
ECMD an AVR-NET-IO mit DAC u. ADC an Junkers Stetigregelung, Siemens LOGO!8, JeeLink uvm...

clumsy

Hallo

Nein, ein T: reading gibts auf der remote instanz nicht, es gibt lediglich das "state" reading, welches mit T: beginnt (zusammengesetzt aus temperature, humidity, etc.).

Ich denke das ist auch genau das problem. Wenn ich ein "inform" mache und mir den log ansehe des Device (auf der remote Instanz) dann sieht das folgendermassen aus:
I2C_BME280 bme280_innen temperature: 30.7
I2C_BME280 bme280_innen pressure: 975.1
I2C_BME280 bme280_innen pressure-nn: 1019.6
I2C_BME280 bme280_innen humidity: 33.9
I2C_BME280 bme280_innen T: 30.7 H: 33.9 P: 975.1 P-NN: 1019.6


Alle readings werden mit dem reading-namen erst angezeigt, nur der state selbst kommt ohne etwas (ich glaube das ist bei state "normal"... da kommt auch bei anderen devices kein reading-name davor im log).

Wie soll nun FHEM2FHEM wissen ob es sich um das reading "T:" handelt oder um den state... das scheint insbesondere bei sensoren, welche ihre Werte im State zusammenfassen (T/H Sensoren etc.) ein Problem zu sein!

Klar kann man es mit regex's umgehen aber ich meine das eigentliche Problem ist, dass es nicht korrekt übertragen resp. abgefangen wird... wobei ich auch nicht wüsste wie man das verhindern könnte ausser bei der log-ausgabe (inform) bei state-ausgaben jeweils explizit das "state" davor zu schreiben!

rudolfkoenig

Ich habe in FHEM2FHEM ein addStateEvent Attribut eingefuehrt, damit sollte dieses Problem vermieden werden. Aus dem Commandref:
Zitatif set, state events are transmitted correctly. Notes: this is relevant
      only with LOG mode, setting it will generate an additional "reappeared"
      Log entry, and the remote FHEM must support inform onWithState (i.e. must
      be up to date).

clumsy

Hallo Rudi

Danke! Das gabs schon oder das ist neu eingeführt jetzt? So wie's aussieht kennt das meine installation auf jeden fall noch nicht... auch nach dem update nicht, also geh ich davon aus, dass das dann irgendwann nächstens mal in einem commit drin ist?

auf jeden fall besten dank wie immer für den super-prompten service!

schönen tag und sonnige grüsse aus der schweiz!!

rudolfkoenig

Habs gerade eingebaut, per update ab morgen, oder ab sofort aus dem SVN.

clumsy

cool, vielen dank!! top wie immer... ich werds mal testen... und melde mich wenns nicht klappt...