Alternative culfw

Begonnen von bjoernh, 15 März 2015, 12:01:06

Vorheriges Thema - Nächstes Thema
Drucken
Nach unten Seiten 1 ... 48 49 50 51 52 ... 128
Benutzer-Aktionen

kadettilac89

#735
13 Januar 2016, 13:15:21
Zitat von: spike am 13 Januar 2016, 12:01:31
pi@raspberrypi ~ $ cd nanoCUL
pi@raspberrypi ~/nanoCUL $ make program
make: *** No rule to make target 'program'.  Stop.
was mache ich Falsch ? Bitte um Hilfe

was mache ich Falsch? --> Du liest die Anleitung nicht. Verwende die vorgegenen Parameter.

==>
To update firmware with culfw execute:

   make program-433
  or
  make program-868
  or use the script ./flash.sh

spike

#736
13 Januar 2016, 19:41:06
Danke jetzt läuft's

kadettilac89

#737
13 Januar 2016, 21:19:56

szoller

#738
20 Januar 2016, 07:59:13 Letzte Bearbeitung: 20 Januar 2016, 13:43:45 von szoller
Hallo,

mal eine kurze Frage:
Habe ich durch die alternative Firmware Nachteile gegenüber der Originalen? Also kann die Originale etwas (besser), was die Alternative nicht (so gut) kann?
Hätte mehrere Möglichkeiten, 433 Mhz Signale zu empfangen/senden (SCC, NanoCul, evtl. Signalduino, Hardware wäre alles da), aber wenn das mit dem einen SCC genauso gut geht kann ich mir das ja sparen und es reicht ein 433 Mhz-Modul für alles  :-)

Edit:
Gibts da beim SCC Unterschiede zwischen 433 und 868 Mhz?
make program-433 geht nicht, "no rule"...

./flash ginge, geht das für die 433er?

Talkabout

#739
23 Januar 2016, 13:32:12
Hallo zusammen,

ich habe nun einen USB CUL an meinem Raspberry PI 2 für das Senden/Empfangen von 433 MHZ Signalen. Das Senden funktioniert problemlos, aber beim Empfang habe ich folgendes komisches Verhalten:

Ich habe einen Feuchtigkeitssensor Typ "Prologue (CUL_TCM97001)" in Empfangsreichweite. Allerdings passiert jedes mal wenn der Sensor sendet Folgendes in FHEM:

Code Auswählen

2016-01-23_13:26:45 HOFeuchtigkeitsmesser humidity: 39
2016-01-23_13:26:45 HOFeuchtigkeitsmesser T: 23.7 H: 39 D: 8.9
2016.01.23 13:26:46 1: /dev/ttyACM0 disconnected, waiting to reappear (SCCIT)
2016-01-23_13:26:46 SCCIT DISCONNECTED
2016.01.23 13:26:46 3: Setting SCCIT serial parameters to 9600,8,N,1
2016.01.23 13:26:46 1: /dev/ttyACM0 reappeared (SCCIT)
2016.01.23 13:26:46 3: SCCIT: Possible commands: BCFiANEkGMKUYRTVWXefmLltux
2016-01-23_13:26:46 SCCIT Initialized
2016-01-23_13:26:46 SCCIT CONNECTED


Wie man sieht kommen tatsächlich Werte an, aber der CUL wird jedes mal getrennt und wieder reconnected. Da dies nur beim Empfang passiert und ich mit Absicht die aculfw geflashed habe, vermute ich ich das Problem in der alternativen Firmware.

Wäre für Tipps dankbar!

Gruss

khk123

#740
23 Januar 2016, 18:28:20
Hallo bjoernh,

in der a-culfw ist wohl eine ältere Version von rpiaddon enthalten. locutus hat Anfang Dezember eine neue Version für die culfw bereitgestellt. Siehe http://forum.fhem.de/index.php/topic,14156.msg370558.html#msg370558 Wird die Version auch in der a-culfw berücksichtigt?

Gruß
Karlheinz
FHEM6.2, RasPi4, RasPi Zero W,
CUL V3, HM, ZWave, IT, vcontrol, owntracks, alexa

Talkabout

#741
24 Januar 2016, 12:52:34
Hallo zusammen,

bezugnehmend auf meinen oberen Post (http://forum.fhem.de/index.php/topic,35064.msg396831.html#msg396831) habe ich noch ein paar weitere Entdeckungen gemacht:

- mit dem SCC (vorher) habe ich Signale von meiner Intertechno-Fernbedienung empfangen. Dies funktioniert zwar mit dem CUL auch, aber dieser disconnected danach genau so wie auch bei dem Feuchtigkeitssensor
- ich habe bereits verschiedene Firmware-Versionen der a-culfw probiert (1.20.00, 1.20.01, 1.20.02), in allen Fällen habe ich das gleiche Verhalten.

Demnach scheint das Problem nicht beim Sensor zu liegen sondern generell ein Problem mit dem Empfang zu sein. Die "Disconnected"-Nachricht kommt aus der Datei "FHEM/DevIo.pm", die aber im Endeffekt nur prüft, was von dem Device zurück kommt.

Hier noch eine Ausgabe mit verbose 5 wenn ich die Intertechno-Fernbedienung betätige:

Code Auswählen
2016.01.24 12:50:48 3: WZStehlampeRechts aus->off
2016-01-24_12:50:48 WZStehlampeRechts aus
2016-01-24_12:50:48 EGLicht aus
2016-01-24_12:50:48 WZStehlampen aus
2016.01.24 12:50:49 1: /dev/ttyACM0 disconnected, waiting to reappear (SCCIT)
2016-01-24_12:50:49 SCCIT DISCONNECTED
2016.01.24 12:50:49 3: Setting SCCIT serial parameters to 38400,8,N,1
2016.01.24 12:50:49 1: /dev/ttyACM0 reappeared (SCCIT)
2016.01.24 12:50:49 5: SW: V
2016.01.24 12:50:49 5: CUL/RAW (ReadAnswer): V 1.20.01 a-culfw Build: 176 (2015-12-07_23-24-58) CUL433 (F-Band: 433MHz)

2016.01.24 12:50:49 5: SW: ?
2016.01.24 12:50:49 5: CUL/RAW (ReadAnswer): ? (? is unknown) Use one of B C F i A N E k G M K U Y R T V W X e f m L l t u x

2016.01.24 12:50:49 3: SCCIT: Possible commands: BCFiANEkGMKUYRTVWXefmLltux
2016.01.24 12:50:49 5: SW: X21
2016.01.24 12:50:49 5: SW: T01
2016.01.24 12:50:49 5: CUL/RAW (ReadAnswer): 1034

2016.01.24 12:50:49 5: GOT CUL fhtid: 1034
2016.01.24 12:50:49 2: Setting CUL fhtid from 1034 to 2345
2016.01.24 12:50:49 5: SW: T012345
2016-01-24_12:50:49 SCCIT Initialized
2016-01-24_12:50:49 SCCIT CONNECTED

und die Definition meines CULs:

Code Auswählen
define SCCIT CUL /dev/ttyACM0@38400 2345
attr SCCIT group CUL
attr SCCIT rfmode SlowRf
attr SCCIT room Server

Gruss

Talkabout

#742
25 Januar 2016, 20:17:24 Letzte Bearbeitung: 25 Januar 2016, 20:59:35 von Talkabout
Hallo zusammen,

hat wirklich keiner einen Tipp für mich, was die Disconnects meines CULs verursachen könnte? Wenn ich tatsächlich der einzige mit einem solchen Problem bin, dann muss es doch ein Problem mit dem CUL geben oder? Gib es Parameter, die ein solches Verhalten beeinflussen könnten?

Unter welchen Umständen liefert denn die Firmware nichts zurück, so dass die DevIo.pm den Disconnect verursacht. Gibt es da spezielle Bedingungen, die man prüfen könnte?

Danke!

Edit: hier noch ein paar Log-Auszüge mit verbose 5

Code Auswählen
2016.01.25 20:33:17 5: CUL/RAW: /i01401410^M

2016.01.25 20:33:17 4: CUL_Parse: CUL_0 i01401410 -66
2016.01.25 20:33:17 5: CUL_0 dispatch i014014
2016.01.25 20:33:17 4: message "i014014" (7)
2016.01.25 20:33:17 3: WZStehlampeRechts aus->off
2016.01.25 20:33:17 5: Triggering WZStehlampeRechts (1 changes)
2016.01.25 20:33:17 5: Notify loop for WZStehlampeRechts aus
2016.01.25 20:33:17 5: Notify from Device: WZStehlampeRechts recieved
2016-01-25_20:33:17 WZStehlampeRechts aus
2016.01.25 20:33:17 5: Update structure 'WZStehlampen' to off because device WZStehlampeRechts has changed
2016.01.25 20:33:17 5: Triggering WZStehlampen (1 changes)
2016.01.25 20:33:17 5: Notify loop for WZStehlampen aus
2016.01.25 20:33:17 5: Update structure 'EGLicht' to off because device WZStehlampen has changed
2016.01.25 20:33:17 5: Triggering EGLicht (1 changes)
2016.01.25 20:33:17 5: Notify loop for EGLicht aus
2016.01.25 20:33:17 5: Notify from Device: EGLicht recieved
2016-01-25_20:33:17 EGLicht aus
2016.01.25 20:33:17 5: Notify from Device: WZStehlampen recieved
2016-01-25_20:33:17 WZStehlampen aus
2016.01.25 20:33:17 5: SET: Unknown argument ?, choose one of off:noArg on:noArg  on-for-timer on-till off-for-timer on-till-overnight blink toggle off-till-overnight intervals off-till
Unknown argument ?, choose one of off:noArg on:noArg  on-for-timer on-till off-for-timer on-till-overnight blink toggle off-till-overnight intervals off-till
2016.01.25 20:33:18 1: /dev/ttyACM0 disconnected, waiting to reappear (SCCIT)
2016.01.25 20:33:18 5: Triggering SCCIT (1 changes)
2016.01.25 20:33:18 5: Notify loop for SCCIT DISCONNECTED
2016.01.25 20:33:18 5: Notify from Device: SCCIT recieved
2016-01-25_20:33:18 SCCIT DISCONNECTED
2016.01.25 20:33:18 3: Setting SCCIT serial parameters to 38400,8,N,1
2016.01.25 20:33:18 1: /dev/ttyACM0 reappeared (SCCIT)
2016.01.25 20:33:18 5: SW: V
2016.01.25 20:33:18 5: CUL/RAW (ReadAnswer): V 1.20.01 a-culfw Build: 176 (2015-12-07_23-24-58) CUL433 (F-Band: 433MHz)^M

2016.01.25 20:33:18 5: SW: ?
2016.01.25 20:33:18 5: CUL/RAW (ReadAnswer): ? (? is unknown) Use one of B C F i A N E k G M K U Y R T V W X e f m L l t u x^M

2016.01.25 20:33:18 3: SCCIT: Possible commands: BCFiANEkGMKUYRTVWXefmLltux
2016.01.25 20:33:18 5: SW: X21
2016.01.25 20:33:18 5: SW: T01
2016.01.25 20:33:18 5: CUL/RAW (ReadAnswer): 1034^M

2016.01.25 20:33:18 5: GOT CUL fhtid: 1034
2016.01.25 20:33:18 2: Setting CUL fhtid from 1034 to 2345
2016.01.25 20:33:18 5: SW: T012345
2016.01.25 20:33:18 5: Triggering SCCIT (1 changes)
2016.01.25 20:33:18 5: Notify loop for SCCIT Initialized
2016.01.25 20:33:18 5: Notify from Device: SCCIT recieved
2016-01-25_20:33:18 SCCIT Initialized
2016.01.25 20:33:18 5: Triggering SCCIT (1 changes)
2016.01.25 20:33:18 5: Notify loop for SCCIT CONNECTED
2016.01.25 20:33:18 5: Notify from Device: SCCIT recieved
2016-01-25_20:33:18 SCCIT CONNECTED


Code Auswählen
2016.01.25 20:35:51 5: CUL/RAW: /Z0B0E000
2016.01.25 20:35:51 5: CUL/RAW: Z0B0E000/21234560
2016.01.25 20:35:51 5: CUL/RAW: Z0B0E00021234560/AA526000
2016.01.25 20:35:51 5: CUL/RAW: Z0B0E00021234560AA526000/000^M
Z0B
2016.01.25 20:35:51 4: CUL_Parse: SCCMAX Z0B0E00021234560AA526000000 -74
2016.01.25 20:35:51 5: SCCMAX dispatch Z0B0E00021234560AA5260000
2016.01.25 20:35:51 5: CUL_MAX_Parse: len 11, msgcnt 0E, msgflag 00, msgTypeRaw Ack, src 123456, dst 0aa526, groupid 0, payload 00
2016.01.25 20:35:51 5: CUL/RAW: Z0B/0E06300AA5261234560010F5^M

2016.01.25 20:35:51 4: CUL_Parse: SCCMAX Z0B0E06300AA5261234560010F5 -79.5
2016.01.25 20:35:51 5: SCCMAX dispatch Z0B0E06300AA5261234560010
2016.01.25 20:35:51 5: CUL_MAX_Parse: len 11, msgcnt 0E, msgflag 06, msgTypeRaw ShutterContactState, src 0aa526, dst 123456, groupid 0, payload 10
2016.01.25 20:35:51 5: CUL_MAX_Parse: rssi: -79.5
2016.01.25 20:35:51 5: CULMAX0 dispatch MAX,1,ShutterContactState,0aa526,10
2016.01.25 20:35:51 5: MAX_Parse MAX,1,ShutterContactState,0aa526,10
2016.01.25 20:35:51 5: ShutterContact isopen 0, rferror 0, battery 0, unkbits 0
2016.01.25 20:35:51 5: Triggering SZFensterkontakt01 (1 changes)
2016.01.25 20:35:51 5: Notify loop for SZFensterkontakt01 RSSI: -79.5
2016.01.25 20:35:51 5: Notify from Device: SZFensterkontakt01 recieved
2016-01-25_20:35:51 SZFensterkontakt01 RSSI: -79.5
2016.01.25 20:35:55 5: CUL/RAW: /omAAAAAAAACCB532CD55354D2B55552D55552AAAA0E2^M

2016.01.25 20:35:55 4: CUL_Parse: CUL_0 omAAAAAAAACCB532CD55354D2B55552D55552AAAA0E2
2016.01.25 20:35:55 5: CUL_0 dispatch omAAAAAAAACCB532CD55354D2B55552D55552AAAA0E2
2016.01.25 20:35:55 5: CUL_REDIRECT (mAAAAAAAACCB532CD55354D2B55552D55552AAAA0E2) length: 43 RSSI: -89
2016.01.25 20:35:55 5: CUL_REDIRECT (mAAAAAAAACCB532CD55354D2B55552D55552AAAA0E2) match Manchester COODE length: 43
2016.01.25 20:35:55 5: CUL_REDIRECT decode Oregon 2 (AAAAAAAACCB532CD55354D2B55552D55552AAAA0E2)
2016.01.25 20:35:55 5: bitdata: 101010101010101010101010101010101100110010110101001100101100110101010101001101010100110100101011010101010101010100101101010101010101010100101010101010101010000011100010
2016.01.25 20:35:55 5: OSV2 protocol detected (AAAAAAAACCB532CD55354D2B55552D55552AAAA0E2)
2016.01.25 20:35:55 5: CUL_REDIRECT: ERROR: To short: OSV2 protocol converted to hex: (401A2D10720003F09F) with length (72) bits

2016.01.25 20:35:55 5: CUL_REDIRECT decode Oregon 3 (AAAAAAAACCB532CD55354D2B55552D55552AAAA0E2)
2016.01.25 20:35:55 5: bitdata: 101010101010101010101010101010101100110010110101001100101100110101010101001101010100110100101011010101010101010100101101010101010101010100101010101010101010000011100010
2016.01.25 20:35:55 5: CUL_REDIRECT decode Hideki (AAAAAAAACCB532CD55354D2B55552D55552AAAA0E2)
2016.01.25 20:35:55 5: CUL_0: search in 101010101010101010101010101010101100110010110101001100101100110101010101001101010100110100101011010101010101010100101101010101010101010100101010101010101010000011100010

2016.01.25 20:35:55 5: protocol does not match, ignore received package (AAAAAAAACCB532CD55354D2B55552D55552AAAA0E2) Reason: Not a hideki protocol
2016.01.25 20:35:56 1: /dev/ttyACM0 disconnected, waiting to reappear (SCCIT)
2016.01.25 20:35:56 5: Triggering SCCIT (1 changes)
2016.01.25 20:35:56 5: Notify loop for SCCIT DISCONNECTED
2016.01.25 20:35:56 5: Notify from Device: SCCIT recieved
2016-01-25_20:35:56 SCCIT DISCONNECTED
2016.01.25 20:35:57 3: Setting SCCIT serial parameters to 38400,8,N,1
2016.01.25 20:35:57 1: /dev/ttyACM0 reappeared (SCCIT)
2016.01.25 20:35:57 5: SW: V
2016.01.25 20:35:57 5: CUL/RAW (ReadAnswer): V 1.20.01 a-culfw Build: 176 (2015-12-07_23-24-58) CUL433 (F-Band: 433MHz)^M

2016.01.25 20:35:57 5: SW: ?
2016.01.25 20:35:57 5: CUL/RAW (ReadAnswer): ? (? is unknown) Use one of B C F i A N E k G M K U Y R T V W X e f m L l t u x^M

2016.01.25 20:35:57 3: SCCIT: Possible commands: BCFiANEkGMKUYRTVWXefmLltux
2016.01.25 20:35:57 5: SW: X21
2016.01.25 20:35:57 5: SW: T01
2016.01.25 20:35:57 5: CUL/RAW (ReadAnswer): 2345^M
2016.01.25 20:35:57 5: GOT CUL fhtid: 2345
2016.01.25 20:35:57 5: Triggering SCCIT (1 changes)
2016.01.25 20:35:57 5: Notify loop for SCCIT Initialized
2016.01.25 20:35:57 5: Notify from Device: SCCIT recieved
2016-01-25_20:35:57 SCCIT Initialized
2016.01.25 20:35:57 5: Triggering SCCIT (1 changes)
2016.01.25 20:35:57 5: Notify loop for SCCIT CONNECTED
2016.01.25 20:35:57 5: Notify from Device: SCCIT recieved
2016-01-25_20:35:57 SCCIT CONNECTED


Gruss

mchilli

#743
27 Januar 2016, 13:31:38
Halli Hallo
Ich habe vor kurzem meinen CUL 433MHz auf die Version 1.20.02 geupdatet, jetzt empfang ich allerdings auch Daten meiner Nachbarn.
Eines konnt ich schon als Hideki Thermometer idendifizieren, jetzt wird mein Log aber immernoch von solchen Meldungen zugespammt:
Code Auswählen
2016.01.27 08:55:29 3: CUL0: Unknown code P12#75E5BA4A8240D1AD2B07, help me!
2016.01.27 09:00:29 3: CUL0: Unknown code P12#75E5BACA7D40D13B0173, help me!
2016.01.27 09:13:54 3: CUL0: Unknown code P12#7510BACA734022EE, help me!
2016.01.27 09:24:52 3: CUL0: Unknown code P12#75E5BA4AB87FCB0327, help me!
2016.01.27 09:33:28 3: CUL0: Unknown code P12#75E5BA4A87402F1E, help me!

Hat jemand vielleicht eine Idee wie ich die Logs unterbinden kann bzw. was das für Geräte sein könnten?
Mehr als 3, der eine macht das, der andere was ganz anderes und einer was ganz ähnliches, was ein anderer auch machen soll.

pejonp

#744
27 Januar 2016, 14:37:13
Zitat von: mchilli am 27 Januar 2016, 13:31:38
...
Eines konnt ich schon als Hideki Thermometer idendifizieren, jetzt wird mein Log aber immernoch von solchen Meldungen zugespammt:
2016.01.27 08:55:29 3: CUL0: Unknown code P12#75E5BA4A8240D1AD2B07, help me!
2016.01.27 09:00:29 3: CUL0: Unknown code P12#75E5BACA7D40D13B0173, help me!
2016.01.27 09:13:54 3: CUL0: Unknown code P12#7510BACA734022EE, help me!
2016.01.27 09:24:52 3: CUL0: Unknown code P12#75E5BA4AB87FCB0327, help me!
...
Hallo mchilli,

das könnte auch das Hidiki-Protokoll sein. Hier wird schon daran gearbeitet (http://forum.fhem.de/index.php/topic,38831.msg394773.html#msg394773).
Mach einmal ein Update:

update all https://raw.githubusercontent.com/RFD-FHEM/RFFHEM/dev-r32/controls_signalduino.txt

dann kommt das aktuelle 14_Hideki.pm mit. Vielelicht wird schon mehr erkannt.

pejonp
LaCrossGW 868MHz:WT470+TFA+TX37-IT+EMT7110+W136+WH25A HP1003+WH2621
SignalD(CC1101):Bresser+WS-0101(868MHz WH1080)+Velux KLF200+MAX!+HM-MOD-UART:Smoke HM-SEC-SD+VITOSOLIC 200 RESOL VBUS-LAN+SolarEdge SE5K(Modbus)+Sonnen!eco8(10kWh)+TD3511+DRT710M(Modbus)+ZigBee+Z-Wave+MQTT+vitoconnect

PSI69

#745
27 Januar 2016, 16:38:03
Hi bjoernh,

ich versuche derzeit ein Brennenstuhl Funksteckdosen Set RSC 2044 (ist ohne DIP Schalter und Pairing per Knopf) mit dem 433 MHz CUL CC1101 zu steuern. Leider klappt das nicht! Ich habe mal mit raw X25 das Drücken der Tasten auf der FB mitgeschnitten und das hier gepostet <http://forum.fhem.de/index.php/topic,47901.msg399211.html#msg399211>.

Kannst Du mal bitte schauen; Was ist das für ein Protokoll und kann das der CUL ggf. auch mit Deiner FW bedienen?

Danke!
Peter
FHEM auf RPi 5 unter Bookworm mit inzwischen einem ganzen Zoo von Geräten...

Talkabout

#746
27 Januar 2016, 19:48:18
Hallo zusammen,

mein Problem aus diesem Post

http://forum.fhem.de/index.php/topic,35064.msg396831.html#msg396831

hat sich erledigt. Problem war, dass das USB-Device 2 mal in meiner fhem.cfg definiert war. Einmal von mir und dann wurde es am Ende der Datei noch mal von FHEM angelegt.

Danke an alle die sich meine Posts durchgelesen haben!

Gruss

mchilli

#747
27 Januar 2016, 20:58:17
Danke pejonp
scheinst recht gehabt zu haben, ich hab zumindest schonmal ein neues Reading im Device vielleicht wird es ja ein bisschen weniger im Log.

Heißt also immer fleißig updaten ;)

Danke nochmal
MCHilli
Mehr als 3, der eine macht das, der andere was ganz anderes und einer was ganz ähnliches, was ein anderer auch machen soll.

Talkabout

#748
28 Januar 2016, 19:08:58 Letzte Bearbeitung: 28 Januar 2016, 19:11:09 von Talkabout
Hallo zusammen,

nachdem mein USB CUL nun läuft habe ich einen Feuchtigkeitssensor eingebunden. Dieser sendet auch fleißig Daten, allerdings passiert es ab und zu, dass die Temperatur plötzlich einen invaliden Wert hat. Im Anhang dazu mal die internals, die readings und die attributes. Bei den Readings sieht man sehr schön, dass im state eine Temperatur von 19.8 steht, im reading temperature aber 1.2. Wie kann so etwas sein und kann man das verhindern? Ich bin mir nämlich ziemlich sicher, dass wir heute in diesem Raum keine Temperatur von nur 1.2 Grad hatten :)

Danke!

Gruss

Talkabout

#749
28 Januar 2016, 19:48:37 Letzte Bearbeitung: 28 Januar 2016, 20:00:20 von Talkabout
Hallo zusammen,

ich habe das oben beschriebe Problem etwas weiter analysiert. Es scheint wohl so zu sein, dass der Sensor ab und zu mal unvollständige Daten sendet. Normalerweise sieht eine Nachricht im Log so aus:

Code Auswählen
2016-01-28_18:35:26 HOFeuchtigkeitsmesser temperature: 18.9
2016-01-28_18:35:26 HOFeuchtigkeitsmesser humidity: 50
2016-01-28_18:35:26 HOFeuchtigkeitsmesser T: 18.9 H: 50

Manchmal kommt aber auch etwas in dieser Richtung:

Code Auswählen
2016-01-28_18:42:05 HOFeuchtigkeitsmesser mode: forced
2016-01-28_18:42:05 HOFeuchtigkeitsmesser temperature: 1.2
2016-01-28_18:42:05 HOFeuchtigkeitsmesser T: 1.2

Wie man sieht fehlt hier in der Nachricht die Luftfeuchtigkeit. In der Modul-Datei wird für bestimmte Modelle eine Plausibilitätsprüfung durchgeführt, ob die übergebenen Werte überhaupt realistisch sind. Wenn die Nachricht aber unvollständig ist, kann auch der Typ nicht korrekt ausgewertet werden, wodurch auch die Plausibilitätsprüfung nicht gemacht wird. Damit wird dann für das Reading "temperature" die Temperatur 1.2 Grad gesetzt. Bei allen folgenden Nachrichten, die komplett sind, steht dann wieder die korrekte Temperatur. Leider greift dann auch die Plausibilitätsprüfung, die sicherstellt, dass die neue Temperatur nicht mehr als 5 Grad von der aktuell gesetzten abweichen kann. Da hier aber der Unterschied größer ist, wird die korrekte Temperatur nie wieder ins Reading geschrieben.

Was mich etwas verwundert ist der Wert von "mode", denn dieser ist forced, es hat aber keiner auf das Knöpfchen am Sensor gedrückt...

Eine einfache Lösung dafür gibt es nicht, aber vielleicht kann man das Update der Readings einfach unterlassen, wenn der "mode" auf "forced" steht?

Gruss

Edit: im Anhang ein Diff welches dafür sorgt, dass bei diesem Sensor das Reading nur dann gesetzt wird, wenn der "mode" nicht "forced" ist.
Drucken
Nach oben Seiten 1 ... 48 49 50 51 52 ... 128
Benutzer-Aktionen