Aeon Labs MultiSensor 6 configTemperatureReportingThreshold

Begonnen von 3dmanipulator, 11 September 2016, 14:10:44

Vorheriges Thema - Nächstes Thema

3dmanipulator

ich möchte diesen wert gerne einstellen, aber was ich auch eingebe, beim auslesen bekomme ich mir unverständliche werte (auch mit conigWord 41).

Beispiel:

Zielwert 0.3

eingabe  Ergebnis
  3             769
  03           769

das verstehe ich leider nicht. könnt ihr mir das bitte erklären.

danke horst
raspberry pi, razberry, fibaro sensor, fibaro dimmer,  nodon fb, tkb dual dimmer Switch, milight e27 + stripe, hmlan, hm-TC, hm-RT

Firefield

hab auch so einen, also
set <sensor> configTemperatureReportingThreshold 03
und nachfolgendes
get <sensor> configTemperatureReportingThreshold
produziert dann 3. schaut aus als wenns funktioniert. läuft deiner mit batterie und ist noch nicht aufgewacht?
meiner hängt am usb und configGroup1Interval steht auf 30. drum hatte ich das bisher nicht gesetzt.
Gigabyte GB-BACE-3150, 8GB RAM, 120GB SSD, Proxmox mit FHEM-VM und DB-VM| (ab und an aktuelles) FHEM mit ConfigDB+LogDB. MariaDB + phpmyadmin. | Zwave.me USB dongle, Jeelink, HM, BTLE und HUEbridge.

3dmanipulator

meiner hängt auch an usb.

Intervall ist 2400.

aber bei mir gibt es im reading leider immer dieses seltsame Ergebnis.
bei allen anderen readings kommen die erwarteten Ergebnisse.
raspberry pi, razberry, fibaro sensor, fibaro dimmer,  nodon fb, tkb dual dimmer Switch, milight e27 + stripe, hmlan, hm-TC, hm-RT

Firefield

hm, allzutief bin ich da leider nicht drinnen. bin bloß user (:
hatte sowas in der art allerdings mal mir irgend einem anderen gerät (leider ka mehr welches/wann und das hat sich dann auch mit einem update gelegt), da hats dann geholfen das einzutippen anstatt das dropdown menü zu nehmen.
was ich auch schon hatte, dass die klassen nicht komplett angelegt waren. obs daran liegt und warum - ebenfalls ka
meiner hat hier:
classes: ZWAVEPLUS_INFO VERSION MANUFACTURER_SPECIFIC ASSOCIATION_GRP_INFO ASSOCIATION POWERLEVEL ALARM BATTERY SENSOR_BINARY SENSOR_MULTILEVEL CONFIGURATION FIRMWARE_UPDATE_MD MARK DEVICE_RESET_LOCALLY
vclasses: ALARM:3 ASSOCIATION:2 ASSOCIATION_GRP_INFO:1 BATTERY:1 CONFIGURATION:1 DEVICE_RESET_LOCALLY:1 FIRMWARE_UPDATE_MD:2 MANUFACTURER_SPECIFIC:2 POWERLEVEL:1 SENSOR_BINARY:1 SENSOR_MULTILEVEL:5 VERSION:2 ZWAVEPLUS_INFO:2

als modell ist gemeldet
model: Aeotec MultiSensor 6
modelConfig: aeotec/multisensor6.xml
modelId: 0086-0002-0064
version: Lib 3 Prot 4.05 App 1.6 HW 100 FWCounter 0
Gigabyte GB-BACE-3150, 8GB RAM, 120GB SSD, Proxmox mit FHEM-VM und DB-VM| (ab und an aktuelles) FHEM mit ConfigDB+LogDB. MariaDB + phpmyadmin. | Zwave.me USB dongle, Jeelink, HM, BTLE und HUEbridge.

3dmanipulator

Lib 3 Prot 4.05 App 1.7 HW 100 FWCounter 0

also App 1.7 statt 1.6 ???
was immer das bedeutet
raspberry pi, razberry, fibaro sensor, fibaro dimmer,  nodon fb, tkb dual dimmer Switch, milight e27 + stripe, hmlan, hm-TC, hm-RT


3dmanipulator

#6
ja, aber das hieße ja dann dass die neuere Firmware den fehler hat.

es sieht übrigens so aus als ob die Funktion trotz der falschen rückmeldung richtig arbeitet.

bei 0.5 ist der reading wert übrigens 1281.

scheint wohl mit: V1.07 Changes to Parameter 201, zu tun zu haben. muss ich ich mir noch mal in ruhe durchlesen.
https://aeotec.freshdesk.com/support/solutions/articles/6000120736-calibrating-offsetting-temperature-on-multisensor-6

grüße horst

raspberry pi, razberry, fibaro sensor, fibaro dimmer,  nodon fb, tkb dual dimmer Switch, milight e27 + stripe, hmlan, hm-TC, hm-RT

Firefield

#7
könnt dann wohl so sein.
glaub aber momentan nicht, dass ich das update mach, denn das teil funktioniert und auf ausm netzwerk rausschmeißen und danach wieder adden hab ich momentan keine lust. da steht zwar, dass temp/feuchte besser ist, allerdings hatte ich die möglichkeit das ding mit einem referenzfühler abzugleichen und eine kleine korrektur einzubauen (was ich mit allen temp und temp/feuchte getan hab) 
korrekturen hab ich mitm userreading gemacht. das mit den zahlensetzten hat bei mir fragezeichen entstehen lassen, da es nicht so ganz ging wie beschrieben. zumal das dann nur eine ein punkt korrektur ist.
Gigabyte GB-BACE-3150, 8GB RAM, 120GB SSD, Proxmox mit FHEM-VM und DB-VM| (ab und an aktuelles) FHEM mit ConfigDB+LogDB. MariaDB + phpmyadmin. | Zwave.me USB dongle, Jeelink, HM, BTLE und HUEbridge.

krikan

Zitat von: 3dmanipulator am 11 September 2016, 17:50:07
ja, aber das hieße ja dann dass die neuere Firmware den fehler hat.
Kann sein, muss aber nicht. In dem Bereich gab es mEn Aenderungen.

Mein Multisensor hat auch 1.7.
Und ich habe gerade auch festgestellt, das dort etwas nachdenkenswert ist.
Hatte auf 5121 stehen, habe dann Deine 03 mit Ergebnis 769 gesetzt.
Wenn ich jetzt 5121 setze, bekomme ich als Ergebnis 1310977.  ???

Firefield

#9
lol. ich lasses dann mal mit dem update. so ähnlich ist das übrigens mit der tempkorrektur...
ich würds mit einem at umschiffen.

\edit der satz mit dem at ist natürlich unsinn...war aufm falschen dampfer
Gigabyte GB-BACE-3150, 8GB RAM, 120GB SSD, Proxmox mit FHEM-VM und DB-VM| (ab und an aktuelles) FHEM mit ConfigDB+LogDB. MariaDB + phpmyadmin. | Zwave.me USB dongle, Jeelink, HM, BTLE und HUEbridge.

3dmanipulator

#10
das reading ist:

256 x zehntelgrad +1
bspl.:
256 x 5 +1 =1281

eingabe:
configTemperatureReportingThreshold 5
configTemperatureReportingThreshold 05

und es funktioniert auch

grüße horst

geht auch mit configWord 41
raspberry pi, razberry, fibaro sensor, fibaro dimmer,  nodon fb, tkb dual dimmer Switch, milight e27 + stripe, hmlan, hm-TC, hm-RT

Firefield

hat sich das dann wohl von firmware 1.6 zu 1.7 geändert? weil bei mir gings ja. und der help text müsste dann eigentlich geändert werden
Gigabyte GB-BACE-3150, 8GB RAM, 120GB SSD, Proxmox mit FHEM-VM und DB-VM| (ab und an aktuelles) FHEM mit ConfigDB+LogDB. MariaDB + phpmyadmin. | Zwave.me USB dongle, Jeelink, HM, BTLE und HUEbridge.

A.Harrenberg

Hi,

das ist ja schon etwas merkwürdig...

Mein Sensor ist noch 1.6 und da funktioniert es.

Könnte mal einer von euch ein kurzes Log posten mit der Rawmessage von "get <device> configTemperatureReportingThreshold"?
Bei mir kommt z.B. 06700629020014 wenn der Wert 20 ist, und das ist auch so in Ordnung... ;-)
Allerdings verstehe ich noch nicht was da in der Auswerteroutine von FHEM passiert, negative Zahlen sind da nämlich z.B. noch gar nicht berücktsichtigt, das müsste man bei Gelegenheit mal ändern. Sollte aber hier keinen Unterschied machen...

Sieht für mich erst mal so aus als ob das z.B. die Reihenfolge der Bytes vertauscht gesendet wird... Das Ding sendet bei mir die Werte als 2 Byte -> dez. 20 = 0x0014, wenn das jetzt als 0x1400 gesendet wird, dann wird das gleich 5120. Sieht also wirklich nach einem FIrmwarebug aus.

Gruß,
Andreas.
FB 7360, Homematic und ZWave
Support for ZWave-SECURITY

A.Harrenberg

Hi,
Zitat von: Firefield am 12 September 2016, 20:18:31
hat sich das dann wohl von firmware 1.6 zu 1.7 geändert? weil bei mir gings ja. und der help text müsste dann eigentlich geändert werden
hier scheint es sich um einen Firmwarebug zu handeln, da sollte man nicht die Doku verbiegen, bei Geräten mit 1.6 oder demnächst vielleicht 1.8 passt es dann wieder nicht, obwohl dort alles richtig ist.

Machmal frage ich mich wirklich wie solche Sachen durch die Zertifizierungstests bei Sigma kommen, wo die doch angeblich so viel Wert auf Prüfen und Einhaltung Ihrer Spezifikationen legen...

Gruß,
Andreas.
FB 7360, Homematic und ZWave
Support for ZWave-SECURITY

krikan

Hallo Andreas!
Abfrage mit dem Ergebnis  1310977:
2016.09.12 20:41:39.732 3: ZWave get ZWave_SENSOR_MULTILEVEL_8 configTemperatureReportingThreshold
2016.09.12 20:41:39.734 5: ZWDongle_Write 00130803700529253c (e345c452)
2016.09.12 20:41:39.738 5: SW: 010a00130803700529253ca8
2016.09.12 20:41:39.741 5: ACK received, WaitForAck=>2 for 010a00130803700529253ca8
2016.09.12 20:41:39.747 4: ZWDongle_Read ZWDongle_0: rcvd 011301 (answer ZW_SEND_DATA), sending ACK
2016.09.12 20:41:39.747 5: SW: 06
2016.09.12 20:41:39.749 5: ZWDongle_0 dispatch 011301
2016.09.12 20:41:39.762 4: ZWDongle_Read ZWDongle_0: rcvd 00133c000002 (request ZW_SEND_DATA), sending ACK
2016.09.12 20:41:39.762 5: SW: 06
2016.09.12 20:41:39.764 5: device ack reveived, removing 010a00130803700529253ca8 from dongle sendstack
2016.09.12 20:41:39.764 5: ZWDongle_0 dispatch 00133c000002
2016.09.12 20:41:39.765 4: CMD:ZW_SEND_DATA ID:00 ARG:0002 CB:3c
2016.09.12 20:41:39.765 4: ZWDongle_0 transmit OK for CB 3c, target ZWave_SENSOR_MULTILEVEL_8
2016.09.12 20:41:39.775 4: ZWDongle_Read ZWDongle_0: rcvd 000400080770062903140101 (request APPLICATION_COMMAND_HANDLER), sending ACK
2016.09.12 20:41:39.775 5: SW: 06
2016.09.12 20:41:39.776 5: ZWDongle_0 dispatch 000400080770062903140101
2016.09.12 20:41:39.777 4: CMD:APPLICATION_COMMAND_HANDLER ID:08 ARG:0770062903140101 CB:00


Setzen
2016.09.11 18:08:28.062 3: ZWave set ZWave_SENSOR_MULTILEVEL_8 configTemperatureReportingThreshold 5121
2016.09.11 18:08:28.062 5: ZWDongle_Write 001308067004290214012526 (e345c452)
2016.09.11 18:08:28.063 5: SW: 010d001308067004290214012526a6
2016.09.11 18:08:28.082 5: ACK received, WaitForAck=>2 for 010d001308067004290214012526a6
2016.09.11 18:08:28.083 4: ZWDongle_Read ZWDongle_0: rcvd 011301 (answer ZW_SEND_DATA), sending ACK
2016.09.11 18:08:28.083 5: SW: 06
2016.09.11 18:08:28.084 5: ZWDongle_0 dispatch 011301
2016.09.11 18:08:28.088 4: ZWDongle_Read ZWDongle_0: rcvd 001326000002 (request ZW_SEND_DATA), sending ACK
2016.09.11 18:08:28.088 5: SW: 06
2016.09.11 18:08:28.090 5: device ack reveived, removing 010d001308067004290214012526a6 from dongle sendstack
2016.09.11 18:08:28.090 5: ZWDongle_0 dispatch 001326000002
2016.09.11 18:08:28.090 4: CMD:ZW_SEND_DATA ID:00 ARG:0002 CB:26
2016.09.11 18:08:28.090 4: ZWDongle_0 transmit OK for CB 26, target ZWave_SENSOR_MULTILEVEL_8


Gruß, Christian