Selbstbau HM_WDS10_TH_O mit Luftdruckmessung

Begonnen von trilu, 23 Februar 2014, 12:23:22

Vorheriges Thema - Nächstes Thema

Tom Major

Früher: FHEM 5.x
Jetzt: RaspberryMatic / ioBroker

gregor

Hallo Tom, - kurze Frage.
Ich habe in meinen HB-UNI-Sensor1 inzwischen einen DS18X20 eingebaut. Der Sensor funktioniert und liefert Temperaturwerte (sichtbar in Serieller Monitor).
Ich glaube aber, dass in FHEM die Temperaturwerte vom BME280 ankommen und nicht die vom DS18X20.
Muss ich in Sketch die Zeile
temperature10 = bme280.temperature();
auskommentieren oder müsste das so gehen ?

Danke
Gregor
Übrigens mein Bewegungssensor funktioniert jetzt mit HB-UNI-Sensor1. Ich habe, wie Du vorgeschlagen hast, den Interrupt während des Sendevorgangs 'disabled'. Jetzt wird kein Signal an A0 erkannt, während gesendet wird.

Tom Major

Eventuell hast du einen älteren Stand vom Unisensor.
Ich habe vor ein paar Wochen die Logik so geändert dass die DS18 Temp. der BME280 Temp. vorgezogen wird, das war eine Anfrage von harvey, siehe "Issues" auf github.
Das Vorziehen passiert hier:
https://github.com/TomMajor/AskSinPP_Examples/blob/master/HB-UNI-Sensor1/HB-UNI-Sensor1.ino#L359

Gilt nur wenn beide vorhanden (definiert) sind. Hilft das?

Im seriellen Monitor kann man auch die Messwerte der Sensoren sehen und somit prüfen welche an die Zentrale übertragen werden. Das hast du ja auch schon gemacht denke ich, nur noch mal als allgemeiner Hinweis.
Früher: FHEM 5.x
Jetzt: RaspberryMatic / ioBroker

gregor

Hallo Tom,
ja, da war ich also auf der richtigen Spur. Das Tauschen der defines BME280 und DS18X20 ist universeller.
Danke, Gregor

gregor

Hallo Tom,
falls Du die Änderung von mir noch einbauen willst. Damit wird ein ungewollter Interrupt durch den Sendevorgang vermieden, falls der Sensor (z.B. PIR oder Radar Sensor RCWL-0516 sehr empfindlich ist.

Änderung HB-UNI-Sensor1.ino
1.
    virtual void trigger(AlarmClock& clock)
    {
        uint8_t msgcnt = device().nextcount();
++       digitalInput.disableINT();                  // Interrupt abschalten, könnte durch Senden ausgelöst werden
        measure();
        msg.init(msgcnt, temperature10, airPressure10, humidity, brightness, digInputState, batteryVoltage, device().battery().low());
        device().sendPeerEvent(msg, *this);
        // reactivate for next measure
        uint16_t updCycle = this->device().getList0().updIntervall();
        set(seconds2ticks(updCycle));
        clock.add(*this);
++        digitalInput.enableINT();                  // Interrupt einschalten
    }

2.
#ifdef SENSOR_DIGINPUT
        if (digitalInput.notifyEvent()) {
            digitalInput.resetEvent();
            DPRINTLN(F("DIGINPUT change"));
            digitalInput.disableINT();
            sdev.channel(1).forceSend();
            delay(250);    // Entprellen
--          digitalInput.enableINT();            // nicht erforderlich da nach Senden ausgeführt
        }

3. in Sens_DIGINPUT.h
    void enableINT()
    {
        if (digitalPinToInterrupt(_pin) == NOT_AN_INTERRUPT) {
            enableInterrupt(_pin, isr, FALLING);
            DPRINTLN(F("Sens_DIGINPUT enable INT"));
        } /*else {
            attachInterrupt(digitalPinToInterrupt(_pin), isr, CHANGE);
            DPRINTLN(F("Sens_DIGINPUT attach INT"));
        }*/
    }

++    void disableINT()
++    {
++            disableInterrupt(_pin);
++            DPRINTLN(F("Sens_DIGINPUT disable INT"));
++    }

    uint8_t pinState() { return digitalRead(_pin); }



Gruß
Gregor

PSI69

Zitat von: PSI69 am 11 Februar 2019, 08:40:18
Mit Pech darf ich den jetzt auslöten; dafür ist erst am WE wieder Zeit.

Er lebt wieder! Externen Takt vom Diamex angelegt, Fuses neu gesetzt, geflashed incl. Debug und ohne OTA, läuft...

Nur das hier:
#ifdef SENSOR_TSL2561
#include "Sensors/Sens_TSL2561.h"    // HB-UNI-Sensor1 custom sensor class
#define TSL2561_ADDR TSL2561_ADDR_FLOAT
//#define TSL2561_ADDR TSL2561_ADDR_LOW
#endif

... mußte ich wieder auf _FLOAT ändern, damit der TSL2561 erkannt wird.

Schönes Restwochenende!
Peter
FHEM auf RPi 5 unter Bookworm mit inzwischen einem ganzen Zoo von Geräten...

Tom Major

#2796
Zitat von: gregor am 16 Februar 2019, 20:46:36
Hallo Tom,
falls Du die Änderung von mir noch einbauen willst. Damit wird ein ungewollter Interrupt durch den Sendevorgang vermieden, falls der Sensor (z.B. PIR oder Radar Sensor RCWL-0516 sehr empfindlich ist.

Gruß
Gregor

Hi Gregor,

ja, so in etwa hatte ich mir das auch damals vorgestellt.
Wobei das disableINT/enableINT nicht in die Funktion trigger() gehört sonder unten in den #ifdef SENSOR_DIGINPUT Block, weil sonst der sketch nicht kompiliert wenn SENSOR_DIGINPUT nicht aktiviert ist.

Ich zögere noch etwas mit der Umsetzung da ich gerade mit fhemfreund einigen Austausch bezüglich PIR und HB-UNI-Sensor1 habe, ich habe die aktuellen Erkenntnisse heute hier veröffentlicht:
https://github.com/TomMajor/AskSinPP_Examples/tree/master/HB-UNI-Sensor1#bewegungsmelder-mit-pir-as312-am-digitalen-eingang

Bei ihm treten mit dem Transistor keinerlei Probleme auf.
Außerdem glaube ich dass wegen dem 20k in Reihe am Ausgang des AS312
https://unusualelectronics.co.uk/as312-am312-mini-pir-module-review/
und aktiviertem pull-up am dig. Eingang der AVR einen verbotenen digitalen Pegel bekommt (bei Low), das könnte auch die Ursache für die Empfindlichkeit/Fehlauslösungen sein.


Edit: was ich über die Stelle für disableINT/enableINT schrieb klappt leider nur für das wake-up bei PIR Aktivität, nicht für das reguläre wake-up über Sendeintervall. Deswegen muss man das disableINT/enableINT wohl in trigger() lassen, braucht aber dann zwei weitere #ifdef SENSOR_DIGINPUT Blöcke.
Früher: FHEM 5.x
Jetzt: RaspberryMatic / ioBroker

fhemfreund

#2797
... es ist tatsächlich so, wie Tom beschreibt. Er hat (wie oben beschrieben) meine Infos (inkl. Bilder etc.) auf seinen Github hochgeladen. Wir haben z.Z. meinen Universalsensor inkl. PIR im Test - ich habe mal einen Counter (digitalInputCount) im Fhem definiert, der die PIR Trigger zählt (siehe Bild im Anhang. Zur Info: die Anzahl der Sendezyklen ist 2x so hoch, da je PIR Trigger der Zustand 2x übertragen wird - nämlich an/aus). Der Sensor läuft seit ca. 9 Tagen mit einer CR2450 Knopfzelle und bis dato sieht es schon mal nicht schlecht aus. Angedacht ist noch, die Anzahl der Sendezyklen zu reduzieren, da der PIR Sensor alle 2 sek. einen Update liefert - daher auch die hohe Anzahl von Sendezyklen in der kurzen Zeit.

Andreas

vbs

Mal ne Frage bzgl. Lagerung von Bauteilen:
Spricht etwas dagegen, SMD-Hühnerfutter wie Widerstände und Kondensatoren aus diesen Papp-Bändern rauszunehmen und dann lose in solche Platikdöschen umzufüllen?
aliexpi.com/tfk

Würde das Gleiche auch mit komplexeren Bauteile wie BME280 o.ä. gehen? Ich denke mal, mindestens bei allem was verbiegbare Teile hat, sollte man das aber nicht machen, oder?

PeMue

Zitat von: vbs am 08 März 2019, 21:31:57
Mal ne Frage bzgl. Lagerung von Bauteilen:
Spricht etwas dagegen, SMD-Hühnerfutter wie Widerstände und Kondensatoren aus diesen Papp-Bändern rauszunehmen und dann lose in solche Platikdöschen umzufüllen?
Link funktioniert bei mir zwar nicht, aber ich mache das ähnlich. Für aktive Bauteile würde ich ESD Dosen verwenden oder sie in den (ESD)-Bändern lassen.

Gruß PeMue
RPi3Bv1.2 rpiaddon 1.66 6.0 1xHM-CC-RT-DN 1.4 1xHM-TC-IT-WM 1.1 2xHB-UW-Sen-THPL-O 0.15 1x-I 0.14OTAU  1xCUNO2 1.67 2xEM1000WZ 2xUniroll 1xASH2200 3xHMS100T(F) 1xRFXtrx 90 1xWT440H 3xTFA30.3150 5xFA21
RPi1Bv2 LCDCSM 1.63 5.8 2xMAX HKT 1xMAX RT V200KW1 Heizung Wasser

vbs

Ah ok danke... Link hab ich irgendwie versemmelt scheinbar... neuer Versuch

100 Widerstände sind echt klein  :o Oder meine "Mäuseklos" extrem groß...


vbs

#2801
Ok, hab jetzt einen Tom-Sensor gebastelt und da lebt etwas :D

Ein aktuelles Problem:
Immer wenn ich ein "getConfig" mache und der Sensor diese Nachrichten verarbeitet, hab ich folgendes im Log:

2019.04.03 23:01:43.251 3 : CUL_HM set HM_A5A502 statusRequest
2019-04-03 23:01:43.261 CUL_HM HM_A5A502 batVoltage: 3.38
2019-04-03 23:01:43.261 CUL_HM HM_A5A502 battery: ok
2019-04-03 23:01:43.261 CUL_HM HM_A5A502 brightness: 88000
2019-04-03 23:01:43.261 CUL_HM HM_A5A502 digitalInput: 0
2019-04-03 23:01:43.261 CUL_HM HM_A5A502 humidity: 88
2019-04-03 23:01:43.261 CUL_HM HM_A5A502 pressure: 1088.0
2019-04-03 23:01:43.261 CUL_HM HM_A5A502 T: 18.8 P: 1088.0 H: 88 B: 88000 I: 0
2019-04-03 23:01:43.261 CUL_HM HM_A5A502 temperature: 18.8
2019.04.03 23:01:43.874 1 : PERL WARNING: Use of uninitialized value in string eq at ./FHEM/10_CUL_HM.pm line 8150.
2019.04.03 23:01:43.874 1 : stacktrace:
2019.04.03 23:01:43.874 1 : main::__ANON__ called by ./FHEM/10_CUL_HM.pm (8150)
2019.04.03 23:01:43.874 1 : main::CUL_HM_getRegFromStore called by ./FHEM/10_CUL_HM.pm (8363)
2019.04.03 23:01:43.875 1 : main::CUL_HM_updtRegDisp called by ./FHEM/10_CUL_HM.pm (3437)
2019.04.03 23:01:43.875 1 : main::CUL_HM_parseCommon called by ./FHEM/10_CUL_HM.pm (1526)
2019.04.03 23:01:43.875 1 : main::CUL_HM_Parse called by fhem.pl (3893)
2019.04.03 23:01:43.875 1 : main::Dispatch called by ./FHEM/00_HMUARTLGW.pm (1463)
2019.04.03 23:01:43.875 1 : main::HMUARTLGW_Parse called by ./FHEM/00_HMUARTLGW.pm (1566)
2019.04.03 23:01:43.875 1 : main::HMUARTLGW_Read called by fhem.pl (3697)
2019.04.03 23:01:43.875 1 : main::CallFn called by fhem.pl (744)
2019.04.03 23:01:43.875 1 : PERL WARNING: Use of uninitialized value in string eq at ./FHEM/10_CUL_HM.pm line 8150.
2019.04.03 23:01:43.875 1 : stacktrace:
2019.04.03 23:01:43.875 1 : main::__ANON__ called by ./FHEM/10_CUL_HM.pm (8150)
2019.04.03 23:01:43.875 1 : main::CUL_HM_getRegFromStore called by ./FHEM/10_CUL_HM.pm (8363)
2019.04.03 23:01:43.875 1 : main::CUL_HM_updtRegDisp called by ./FHEM/10_CUL_HM.pm (3437)
2019.04.03 23:01:43.875 1 : main::CUL_HM_parseCommon called by ./FHEM/10_CUL_HM.pm (1526)
2019.04.03 23:01:43.875 1 : main::CUL_HM_Parse called by fhem.pl (3893)
2019.04.03 23:01:43.875 1 : main::Dispatch called by ./FHEM/00_HMUARTLGW.pm (1463)
2019.04.03 23:01:43.875 1 : main::HMUARTLGW_Parse called by ./FHEM/00_HMUARTLGW.pm (1566)
2019.04.03 23:01:43.875 1 : main::HMUARTLGW_Read called by fhem.pl (3697)
2019.04.03 23:01:43.876 1 : main::CallFn called by fhem.pl (744)
2019.04.03 23:01:43.876 1 : PERL WARNING: Use of uninitialized value in string eq at ./FHEM/10_CUL_HM.pm line 8150.
2019.04.03 23:01:43.876 1 : stacktrace:
2019.04.03 23:01:43.876 1 : main::__ANON__ called by ./FHEM/10_CUL_HM.pm (8150)
2019.04.03 23:01:43.876 1 : main::CUL_HM_getRegFromStore called by ./FHEM/10_CUL_HM.pm (8363)
2019.04.03 23:01:43.876 1 : main::CUL_HM_updtRegDisp called by ./FHEM/10_CUL_HM.pm (3437)
2019.04.03 23:01:43.876 1 : main::CUL_HM_parseCommon called by ./FHEM/10_CUL_HM.pm (1526)
2019.04.03 23:01:43.876 1 : main::CUL_HM_Parse called by fhem.pl (3893)
2019.04.03 23:01:43.876 1 : main::Dispatch called by ./FHEM/00_HMUARTLGW.pm (1463)
2019.04.03 23:01:43.876 1 : main::HMUARTLGW_Parse called by ./FHEM/00_HMUARTLGW.pm (1566)
2019.04.03 23:01:43.876 1 : main::HMUARTLGW_Read called by fhem.pl (3697)
2019.04.03 23:01:43.876 1 : main::CallFn called by fhem.pl (744)
2019.04.03 23:01:43.876 1 : PERL WARNING: Use of uninitialized value in string eq at ./FHEM/10_CUL_HM.pm line 8150.
2019.04.03 23:01:43.876 1 : stacktrace:
2019.04.03 23:01:43.876 1 : main::__ANON__ called by ./FHEM/10_CUL_HM.pm (8150)
2019.04.03 23:01:43.877 1 : main::CUL_HM_getRegFromStore called by ./FHEM/10_CUL_HM.pm (8363)
2019.04.03 23:01:43.877 1 : main::CUL_HM_updtRegDisp called by ./FHEM/10_CUL_HM.pm (3437)
2019.04.03 23:01:43.877 1 : main::CUL_HM_parseCommon called by ./FHEM/10_CUL_HM.pm (1526)
2019.04.03 23:01:43.877 1 : main::CUL_HM_Parse called by fhem.pl (3893)
2019.04.03 23:01:43.877 1 : main::Dispatch called by ./FHEM/00_HMUARTLGW.pm (1463)
2019.04.03 23:01:43.877 1 : main::HMUARTLGW_Parse called by ./FHEM/00_HMUARTLGW.pm (1566)
2019.04.03 23:01:43.877 1 : main::HMUARTLGW_Read called by fhem.pl (3697)
2019.04.03 23:01:43.877 1 : main::CallFn called by fhem.pl (744)
2019.04.03 23:01:43.877 1 : PERL WARNING: Use of uninitialized value in string eq at ./FHEM/10_CUL_HM.pm line 8150.
2019.04.03 23:01:43.877 1 : stacktrace:
2019.04.03 23:01:43.877 1 : main::__ANON__ called by ./FHEM/10_CUL_HM.pm (8150)
2019.04.03 23:01:43.877 1 : main::CUL_HM_getRegFromStore called by ./FHEM/10_CUL_HM.pm (8363)
2019.04.03 23:01:43.877 1 : main::CUL_HM_updtRegDisp called by ./FHEM/10_CUL_HM.pm (3437)
2019.04.03 23:01:43.877 1 : main::CUL_HM_parseCommon called by ./FHEM/10_CUL_HM.pm (1526)
2019.04.03 23:01:43.877 1 : main::CUL_HM_Parse called by fhem.pl (3893)
2019.04.03 23:01:43.877 1 : main::Dispatch called by ./FHEM/00_HMUARTLGW.pm (1463)
2019.04.03 23:01:43.877 1 : main::HMUARTLGW_Parse called by ./FHEM/00_HMUARTLGW.pm (1566)
2019.04.03 23:01:43.877 1 : main::HMUARTLGW_Read called by fhem.pl (3697)
2019.04.03 23:01:43.877 1 : main::CallFn called by fhem.pl (744)
2019.04.03 23:01:43.877 1 : PERL WARNING: Use of uninitialized value in string eq at ./FHEM/10_CUL_HM.pm line 8150.
2019.04.03 23:01:43.877 1 : stacktrace:
2019.04.03 23:01:43.878 1 : main::__ANON__ called by ./FHEM/10_CUL_HM.pm (8150)
2019.04.03 23:01:43.878 1 : main::CUL_HM_getRegFromStore called by ./FHEM/10_CUL_HM.pm (8363)
2019.04.03 23:01:43.878 1 : main::CUL_HM_updtRegDisp called by ./FHEM/10_CUL_HM.pm (3437)
2019.04.03 23:01:43.878 1 : main::CUL_HM_parseCommon called by ./FHEM/10_CUL_HM.pm (1526)
2019.04.03 23:01:43.878 1 : main::CUL_HM_Parse called by fhem.pl (3893)
2019.04.03 23:01:43.878 1 : main::Dispatch called by ./FHEM/00_HMUARTLGW.pm (1463)
2019.04.03 23:01:43.878 1 : main::HMUARTLGW_Parse called by ./FHEM/00_HMUARTLGW.pm (1566)
2019.04.03 23:01:43.878 1 : main::HMUARTLGW_Read called by fhem.pl (3697)
2019.04.03 23:01:43.878 1 : main::CallFn called by fhem.pl (744)
2019.04.03 23:01:43.878 1 : PERL WARNING: Use of uninitialized value in string eq at ./FHEM/10_CUL_HM.pm line 8150.
2019.04.03 23:01:43.878 1 : stacktrace:
2019.04.03 23:01:43.878 1 : main::__ANON__ called by ./FHEM/10_CUL_HM.pm (8150)
2019.04.03 23:01:43.878 1 : main::CUL_HM_getRegFromStore called by ./FHEM/10_CUL_HM.pm (8363)
2019.04.03 23:01:43.878 1 : main::CUL_HM_updtRegDisp called by ./FHEM/10_CUL_HM.pm (3437)
2019.04.03 23:01:43.878 1 : main::CUL_HM_parseCommon called by ./FHEM/10_CUL_HM.pm (1526)
2019.04.03 23:01:43.878 1 : main::CUL_HM_Parse called by fhem.pl (3893)
2019.04.03 23:01:43.878 1 : main::Dispatch called by ./FHEM/00_HMUARTLGW.pm (1463)
2019.04.03 23:01:43.878 1 : main::HMUARTLGW_Parse called by ./FHEM/00_HMUARTLGW.pm (1566)
2019.04.03 23:01:43.878 1 : main::HMUARTLGW_Read called by fhem.pl (3697)
2019.04.03 23:01:43.878 1 : main::CallFn called by fhem.pl (744)
2019.04.03 23:01:43.878 1 : PERL WARNING: Use of uninitialized value in string eq at ./FHEM/10_CUL_HM.pm line 8150.
2019.04.03 23:01:43.878 1 : stacktrace:
2019.04.03 23:01:43.879 1 : main::__ANON__ called by ./FHEM/10_CUL_HM.pm (8150)
2019.04.03 23:01:43.879 1 : main::CUL_HM_getRegFromStore called by ./FHEM/10_CUL_HM.pm (8363)
2019.04.03 23:01:43.879 1 : main::CUL_HM_updtRegDisp called by ./FHEM/10_CUL_HM.pm (3437)
2019.04.03 23:01:43.879 1 : main::CUL_HM_parseCommon called by ./FHEM/10_CUL_HM.pm (1526)
2019.04.03 23:01:43.879 1 : main::CUL_HM_Parse called by fhem.pl (3893)
2019.04.03 23:01:43.879 1 : main::Dispatch called by ./FHEM/00_HMUARTLGW.pm (1463)
2019.04.03 23:01:43.879 1 : main::HMUARTLGW_Parse called by ./FHEM/00_HMUARTLGW.pm (1566)
2019.04.03 23:01:43.879 1 : main::HMUARTLGW_Read called by fhem.pl (3697)
2019.04.03 23:01:43.879 1 : main::CallFn called by fhem.pl (744)


Habt ihr das auch? Ist das ein Problem bei mir, mit der Firmware oder allgemein mit 10_CUL_HM?  ???

So sieht mein Device aus:

Historie löschen
Internals:
   DEF        A5A502
   FUUID      5ca3923e-f33f-af31-f00a-6d4e5662fbab03bf
   IODev      sys_culHm
   LASTInputDev sys_culHm
   MSGCNT     65
   NAME       HM_A5A502
   NOTIFYDEV  global
   NR         630
   NTFY_ORDER 50-HM_A5A502
   STATE      T: 18.8 P: 1088.0 H: 88 B: 88000 I: 0
   TYPE       CUL_HM
   chanNo     01
   lastMsg    No:01 - t:70 s:A5A502 d:<VCCUID> 00BC2A8058000157C0000D36
   protCmdDel 3
   protLastRcv 2019-04-03 23:02:25
   protRcv    55 last_at:2019-04-03 23:02:25
   protResnd  12 last_at:2019-04-03 23:01:46
   protResndFail 1 last_at:2019-04-03 22:29:47
   protSnd    46 last_at:2019-04-03 23:01:44
   protState  CMDs_pending
   rssi_at_sys_culHm cnt:65 min:-68 max:-56 avg:-61.13 lst:-60
   rssi_sys_culHm cnt:10 min:-79 max:-72 avg:-76.1 lst:-77
   sys_culHm_MSGCNT 65
   sys_culHm_RAWMSG 0501003C018470A5A502<VCCUID>00BC2A8058000157C0000D36
   sys_culHm_RSSI -60
   sys_culHm_TIME 2019-04-03 23:02:25
   READINGS:
     2019-04-03 22:32:32   Activity        alive
     2019-04-03 22:31:00   CommandAccepted yes
     2019-04-03 22:32:32   D-firmware      1.2
     2019-04-03 22:32:32   D-serialNr      UNISENS001
     2019-04-03 23:01:43   PairedTo        <VCCUID>
     2019-04-03 22:31:13   R-pairCentral   <VCCUID>
     2019-04-03 23:01:43   RegL_00.         00:00 05:40 0A:F1 0B:55 0C:44 12:15 14:06 20:02 21:58 22:00 23:00
     2019-04-03 23:02:25   batVoltage      3.38
     2019-04-03 23:02:25   battery         ok
     2019-04-03 23:02:25   brightness      88000
     2019-04-03 23:02:25   digitalInput    0
     2019-04-03 23:02:25   humidity        88
     2019-04-03 22:50:17   powerOn         2019-04-03 22:50:17
     2019-04-03 23:02:25   pressure        1088.0
     2019-04-03 23:01:44   recentStateType info
     2019-04-03 23:02:25   state           T: 18.8 P: 1088.0 H: 88 B: 88000 I: 0
     2019-04-03 23:02:25   temperature     18.8
   cmdStack:
   helper:
     HM_CMDNR   1
     PONtest    1
     cSnd       01<VCCUID>A5A5020103,01<VCCUID>A5A502010E
     mId        F103
     peerFriend
     peerIDsRaw ,00000000
     peerOpt    p:UniSensor1
     regLst     0
     rxType     156
     supp_Pair_Rep 0
     expert:
       def        1
       det        0
       raw        1
       tpl        0
     io:
       newCh      1
       newChn     +A5A502,02,00,00
       nextSend   1554325345.15859
       rxt        2
       vccu       VCCU
       p:
         A5A502
         00
         00
         00
       prefIO:
         sys_culHm
     mRssi:
       mNo        01
       io:
         sys_culHm:
           -56
           -56
     prt:
       bErr       0
       sProc      2
       sleeping   0
       wuReSent   2
     q:
       qReqConf   
       qReqStat   
     regCollect:
     role:
       chn        1
       dev        1
     rssi:
       at_sys_culHm:
         avg        -61.1384615384615
         cnt        65
         lst        -60
         max        -56
         min        -68
       sys_culHm:
         avg        -76.1
         cnt        10
         lst        -77
         max        -72
         min        -79
     shadowReg:
     tmpl:
Attributes:
   IODev      sys_culHm
   IOgrp      VCCU:sys_culHm
   actCycle   000:10
   actStatus  alive
   autoReadReg 4_reqStatus
   expert     2_raw
   firmware   1.2
   model      HB-UNI-Sensor1
   peerIDs    00000000,
   room       CUL_HM
   serialNr   UNISENS001
   subType    UniSensor1


Danke! Und vor allem danke und Hut ab für die tolle Dokumentation des Sensors!

vbs

Hm, also dann wirklich ein Problem von CUL_HM? hab es dort mal gepostet:
https://forum.fhem.de/index.php/topic,99333.0.html

Tom Major

Habe nur auf die Schnelle das hier gefunden
https://forum.fhem.de/index.php/topic,59456.30.html
da ging es auch um einen Selbstbau-Sensor.
Ich stecke aber zu wenig in den FHEM CUL interna drin, kann nicht sagen woran es liegt.
Hat eigentlich @fhemfreund auch das Problem bei seinem Nachbau?
Früher: FHEM 5.x
Jetzt: RaspberryMatic / ioBroker

fhemfreund

Zitat von: Tom Major am 04 April 2019, 23:56:48
Hat eigentlich @fhemfreund auch das Problem bei seinem Nachbau?

Hat er eigentlich nicht ;-) Stacktraces habe ich bis jetzt in meinen Logs nicht gefunden. Was ich aber in vbs's log sehe, dass er ein HMUARTLGW hat. Habe meine Sensoren direkt via HM-MOD-RPI-PCB in Verbindung mit einem USB-UART konfiguriert. Meine CUL-HM ist vom '10_CUL_HM.pm 17532 2018-10-14 17:50:45Z martinp876'.

Andreas