Strange updates to zero

Discussion about Z-Uno product. Visit http://z-uno.z-wave.me for more details.
Post Reply
jucs
Posts: 35
Joined: 28 Dec 2016 17:56

Strange updates to zero

Post by jucs »

Hello everyone,

I'm currently trying to implement a simple temperature sensor in FLiRS mode. The sensor works when it initiates an update of the temperature (using an interrupt, for example); however, if I query the temperature from the device using my my Z-Wave controller, I oftentimes get readings of the value 0. Does anyone have an idea what I'm doing wrong?

By going through the log, I recognized that there are often two updates that follow a request; one that updates the temperature value to a realistic value and one that updates it to zero.

I'm usually using OpenHAB, however I've also tried the Z-Way server.

The problem also occurs when I return a constant value (other than 0) from the getter function of the channel. Thus, it's not a problem with the sensor.

Here is my current implementation:

Code: Select all

// demo sketch for connecting OneWire temperature sensor DS18B20 to Z-Uno

// add library ds18b20
#include "ZUNO_DS18B20.h"

// pin connection ds18b20
#define PIN_DS18B20 11

OneWire ow(PIN_DS18B20);

// onewire connection temperature sensors
DS18B20Sensor ds1820(&ow); 


byte addr1[8];
int temp;

// set up channel
ZUNO_SETUP_CHANNELS(
   ZUNO_SENSOR_MULTILEVEL(ZUNO_SENSOR_MULTILEVEL_TYPE_TEMPERATURE, 
                          SENSOR_MULTILEVEL_SCALE_CELSIUS, 
                          SENSOR_MULTILEVEL_SIZE_TWO_BYTES, 
                          SENSOR_MULTILEVEL_PRECISION_TWO_DECIMALS,
                          getterTemp)
);

ZUNO_SETUP_SLEEPING_MODE(ZUNO_SLEEPING_MODE_FREQUENTLY_AWAKE);

ZUNO_SETUP_DEBUG_MODE(DEBUG_ON);

void setup() {
}


void loop() {
    delayMicroseconds(250);
    ds1820.scanAloneSensor(addr1);
    float temperature = ds1820.getTemperature(addr1);
    temp = int(temperature*100);
    zunoSendReport(1);

    zunoSendDeviceToSleep();
}

int getterTemp() {
  return temp;
}

Thank you very much for help!!
michap
Posts: 442
Joined: 26 Mar 2013 10:35
Contact:

Re: Strange updates to zero

Post by michap »

Hi,

I'm not sure, ZUNO_SENSOR_MULTILEVEL is allowed in ZUNO_SLEEPING_MODE_FREQUENTLY_AWAKE mode due to Z-Wave certification....
Developers want to add a parameter to disable this restriction - I think in next releases.

Have you the same issue if you are working with a sleeping device (standard for sensors)?

Michael
jucs
Posts: 35
Joined: 28 Dec 2016 17:56

Re: Strange updates to zero

Post by jucs »

There is a remark for "ZUNO_SWITCH_MULTILEVEL()" on the reference page that says "This type is allowed only in ZUNO_SLEEPING_MODE_ALWAYS_AWAKE power mode"; however, I can't find the same remark on the reference page for ZUNO_SENSOR_MULTILEVEL(). I have also tried ZUNO_METER() with the same results.

Regarding sleeping devices: I think sleeping devices can't be queried by the controller, right? So this problem is not applicable there. As far as I know, sleeping devices only wake up themselves and then send the sensor value. However, if I wake up my FLiRS device manually (like the sleeping device), the update always works. The problem only occurs if the device is woken up by the controller ("the FLiRS feature")...
jucs
Posts: 35
Joined: 28 Dec 2016 17:56

Re: Strange updates to zero

Post by jucs »

If it's any help, this is how such a polling looks in the OpenHAB log file:

Code: Select all

2017-01-04 00:47:46.612 [ItemStateChangedEvent     ] - zwave_device_86d1d009_node76_sensor_temperature changed from 30.25 to 0
2017-01-04 00:47:46.793 [ItemStateChangedEvent     ] - zwave_device_86d1d009_node76_sensor_temperature changed from 0 to 30.25
Sometimes the zero update comes first, sometimes it comes last. The two updates correspond to the getter function of the channel being called twice.
User avatar
PoltoS
Posts: 7579
Joined: 26 Jan 2011 19:36

Re: Strange updates to zero

Post by PoltoS »

Z-Uno in FLiRS mode wakes up on RF signal. This means getter will be called almost immediatelly. Looks we need to force enter into the loop() before getter.

As a workaround please save last value in NZRAM and report it.
jucs
Posts: 35
Joined: 28 Dec 2016 17:56

Re: Strange updates to zero

Post by jucs »

Thanks for your answer!

Unfortunately, I've already tried your workaround. It even doesn't work if I return a constant value (other than zero, obviously) from the getter, so I'm pretty sure there is something deeper going wrong...

Could it be that the getter is called (because, as I've tried with the NZRAM counter it actually is called multiple times) but the value returned is not sent correctly for some reason? Maybe because the device is not yet ready at that point?

I have even tried to hard-code pushing a non-zero value onto the stack in zunoCallback() of your library, but I still saw updates to zero.
jucs
Posts: 35
Joined: 28 Dec 2016 17:56

Re: Strange updates to zero

Post by jucs »

Here is a more extensive log from the Z-Way server:

Code: Select all

[2017-01-05 16:00:08.207] [I] [core] ---  ZWayVDev_zway_76-1-49-1 performCommand processing: {"0":"update","1":{}}
[2017-01-05 16:00:08.208] [I] [zway] Adding job: SensorMultilevel V5 Get
[2017-01-05 16:00:08.217] [D] [zway] SENDING (cb 0x22): ( 01 0F 00 13 4C 08 60 0D 00 01 31 04 01 00 05 22 D8 )
[2017-01-05 16:00:08.219] [D] [zway] RECEIVED ACK
[2017-01-05 16:00:08.223] [D] [zway] RECEIVED: ( 01 04 01 13 01 E8 )
[2017-01-05 16:00:08.224] [D] [zway] SENT ACK
[2017-01-05 16:00:08.224] [D] [zway] Delivered to Z-Wave stack
[2017-01-05 16:00:09.443] [D] [zway] RECEIVED: ( 01 07 00 13 22 00 00 7A B3 )
[2017-01-05 16:00:09.444] [D] [zway] SENT ACK
[2017-01-05 16:00:09.444] [I] [zway] Job 0x13 (SensorMultilevel V5 Get): Delivered
[2017-01-05 16:00:09.444] [D] [zway] SETDATA controller.data.outgoingPacket.delivered = True
[2017-01-05 16:00:09.445] [D] [zway] SETDATA controller.data.outgoingPacket.deliveryTime = 1220 (0x000004c4)
[2017-01-05 16:00:09.445] [D] [zway] SETDATA controller.data.outgoingPacket.packetLength = 11 (0x0000000b)
[2017-01-05 16:00:09.446] [D] [zway] SETDATA controller.data.outgoingPacket = **********
[2017-01-05 16:00:09.446] [D] [zway] SendData Response with callback 0x22 received: received by recipient
[2017-01-05 16:00:09.446] [D] [zway] SETDATA devices.76.data.lastSend = 223461 (0x000368e5)
[2017-01-05 16:00:09.447] [D] [zway] Job 0x13 (SensorMultilevel V5 Get): success
[2017-01-05 16:00:09.447] [I] [zway] Removing job: SensorMultilevel V5 Get
[2017-01-05 16:00:09.457] [D] [zway] RECEIVED: ( 01 0C 00 04 00 4C 06 31 05 01 42 06 40 8C )
[2017-01-05 16:00:09.457] [D] [zway] SENT ACK
[2017-01-05 16:00:09.457] [D] [zway] SETDATA controller.data.incomingPacket.nodeId = 76 (0x0000004c)
[2017-01-05 16:00:09.458] [D] [zway] SETDATA controller.data.incomingPacket.frameType = "singlecast"
[2017-01-05 16:00:09.459] [D] [zway] SETDATA controller.data.incomingPacket = **********
[2017-01-05 16:00:09.459] [D] [zway] SETDATA devices.76.data.lastReceived = 0 (0x00000000)
[2017-01-05 16:00:09.459] [D] [zway] SETDATA devices.76.instances.0.commandClasses.49.data.1.deviceScale = 0 (0x00000000)
[2017-01-05 16:00:09.462] [D] [zway] SETDATA devices.76.instances.0.commandClasses.49.data.1.scaleString = "°C"
[2017-01-05 16:00:09.462] [D] [zway] SETDATA devices.76.instances.0.commandClasses.49.data.1.val = 16.000000
[2017-01-05 16:00:09.463] [D] [zway] SETDATA devices.76.instances.0.commandClasses.49.data.1 = Empty
[2017-01-05 16:00:09.480] [D] [zway] RECEIVED: ( 01 10 00 04 00 4C 0A 60 0D 01 00 31 05 01 42 06 40 F0 )
[2017-01-05 16:00:09.481] [D] [zway] SENT ACK
[2017-01-05 16:00:09.481] [D] [zway] SETDATA controller.data.incomingPacket.nodeId = 76 (0x0000004c)
[2017-01-05 16:00:09.481] [D] [zway] SETDATA controller.data.incomingPacket.frameType = "singlecast"
[2017-01-05 16:00:09.482] [D] [zway] SETDATA controller.data.incomingPacket = **********
[2017-01-05 16:00:09.483] [D] [zway] SETDATA devices.76.data.lastReceived = 0 (0x00000000)
[2017-01-05 16:00:09.483] [D] [zway] SETDATA devices.76.instances.1.commandClasses.49.data.1.deviceScale = 0 (0x00000000)
[2017-01-05 16:00:09.486] [D] [zway] SETDATA devices.76.instances.1.commandClasses.49.data.1.scaleString = "°C"
[2017-01-05 16:00:09.486] [D] [zway] SETDATA devices.76.instances.1.commandClasses.49.data.1.val = 16.000000
[2017-01-05 16:00:09.488] [D] [zway] SETDATA devices.76.instances.1.commandClasses.49.data.1 = Empty
[2017-01-05 16:00:09.505] [D] [zway] RECEIVED: ( 01 0C 00 04 00 4C 06 31 05 01 42 06 40 8C )
[2017-01-05 16:00:09.505] [D] [zway] SENT ACK
[2017-01-05 16:00:09.505] [D] [zway] SETDATA controller.data.incomingPacket.nodeId = 76 (0x0000004c)
[2017-01-05 16:00:09.506] [D] [zway] SETDATA controller.data.incomingPacket.frameType = "singlecast"
[2017-01-05 16:00:09.507] [D] [zway] SETDATA controller.data.incomingPacket = **********
[2017-01-05 16:00:09.507] [D] [zway] SETDATA devices.76.data.lastReceived = 0 (0x00000000)
[2017-01-05 16:00:09.507] [D] [zway] SETDATA devices.76.instances.0.commandClasses.49.data.1.deviceScale = 0 (0x00000000)
[2017-01-05 16:00:09.510] [D] [zway] SETDATA devices.76.instances.0.commandClasses.49.data.1.scaleString = "°C"
[2017-01-05 16:00:09.511] [D] [zway] SETDATA devices.76.instances.0.commandClasses.49.data.1.val = 16.000000
[2017-01-05 16:00:09.512] [D] [zway] SETDATA devices.76.instances.0.commandClasses.49.data.1 = Empty
[2017-01-05 16:00:09.526] [D] [zway] RECEIVED: ( 01 0C 00 04 00 4C 06 31 05 01 42 06 40 8C )
[2017-01-05 16:00:09.527] [D] [zway] SENT ACK
[2017-01-05 16:00:09.527] [D] [zway] SETDATA controller.data.incomingPacket.nodeId = 76 (0x0000004c)
[2017-01-05 16:00:09.528] [D] [zway] SETDATA controller.data.incomingPacket.frameType = "singlecast"
[2017-01-05 16:00:09.528] [D] [zway] SETDATA controller.data.incomingPacket = **********
[2017-01-05 16:00:09.528] [D] [zway] SETDATA devices.76.data.lastReceived = 0 (0x00000000)
[2017-01-05 16:00:09.529] [D] [zway] SETDATA devices.76.instances.0.commandClasses.49.data.1.deviceScale = 0 (0x00000000)
[2017-01-05 16:00:09.531] [D] [zway] SETDATA devices.76.instances.0.commandClasses.49.data.1.scaleString = "°C"
[2017-01-05 16:00:09.532] [D] [zway] SETDATA devices.76.instances.0.commandClasses.49.data.1.val = 16.000000
[2017-01-05 16:00:09.532] [D] [zway] SETDATA devices.76.instances.0.commandClasses.49.data.1 = Empty
[2017-01-05 16:00:09.549] [D] [zway] RECEIVED: ( 01 0F 00 04 00 4C 09 60 0D 01 00 31 05 01 00 00 E8 )
[2017-01-05 16:00:09.550] [D] [zway] SENT ACK
[2017-01-05 16:00:09.551] [D] [zway] SETDATA controller.data.incomingPacket.nodeId = 76 (0x0000004c)
[2017-01-05 16:00:09.552] [D] [zway] SETDATA controller.data.incomingPacket.frameType = "singlecast"
[2017-01-05 16:00:09.553] [D] [zway] SETDATA controller.data.incomingPacket = **********
[2017-01-05 16:00:09.555] [D] [zway] SETDATA devices.76.data.lastReceived = 0 (0x00000000)
[2017-01-05 16:00:09.556] [D] [zway] SETDATA devices.76.instances.1.commandClasses.49.data.1.deviceScale = 0 (0x00000000)
[2017-01-05 16:00:09.559] [D] [zway] SETDATA devices.76.instances.1.commandClasses.49.data.1.scaleString = "°C"
[2017-01-05 16:00:09.561] [D] [zway] SETDATA devices.76.instances.1.commandClasses.49.data.1.val = 0.000000
[2017-01-05 16:00:09.562] [D] [zway] SETDATA devices.76.instances.1.commandClasses.49.data.1 = Empty
[2017-01-05 16:00:09.685] [I] [core] Notification: device-info (device-temperature): {"dev":"Z-Wave.Me Temperature (76.1.49.1)","l":"0 °C"}
jucs
Posts: 35
Joined: 28 Dec 2016 17:56

Re: Strange updates to zero

Post by jucs »

Another update:

The problem also (sometimes) occurs in ZUNO_SLEEPING_MODE_SLEEPING mode, namely when waking up after the configured wake-up period.

Update: It seems like this happens again if the controller has queued some command for the sensor. In particular, it seems to happen at the next wake-up after the end of the configured polling time.
Post Reply