Binary Temperature Sensor will no longer sync in 6.0.3

I was quite excited to see that you have added temperature and (I hope) associations to the little temperature sensor. It is the cheapest way to measure temperature in the UK and will be a Godsend when it starts to work.

The resync failed so I excluded and re-included into the system ... no luck, it would not sync.

Setting parameter 7 failed, the instructions say it should be 0 (Off) or 255 (On - default). I tried to upload the instructions but the pdf extension was rejected. Are uploads not permitted?

Here is the log:

Z-Wave Syncing - started for device "035 - Binary Sensor"
Z-Wave Debug SENT getNodeNeighbors: 01 06 00 80 23 01 01 5A
Z-Wave Debug RCVD getNodeNeighbors: 01 20 01 80 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 5E
Z-Wave Debug . . getNodeNeighbors: nodeId 035, neighbors: - none -
Z-Wave Syncing - retrieved module neighbors list: - none -
Z-Wave Syncing - requesting neighbor list update of "035 - Binary Sensor"
Z-Wave Debug SENT requestNeighborUpdate: 01 04 00 48 23 90
Z-Wave Debug RCVD requestNeighborUpdate: 06 (ACK)
Z-Wave Debug RCVD requestNeighborUpdate: 01 05 00 48 01 21 92
Z-Wave Debug . . requestNeighborUpdate: node 035, update starting
Z-Wave Debug RCVD requestNeighborUpdate: 01 05 00 48 01 22 91
Z-Wave Debug . . requestNeighborUpdate: node 035, update finished
Z-Wave Debug SENT getNodeNeighbors: 01 06 00 80 23 01 01 5A
Z-Wave Debug RCVD getNodeNeighbors: 01 20 01 80 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 5E
Z-Wave Debug . . getNodeNeighbors: nodeId 035, neighbors: - none -
Z-Wave Syncing - neighbor list update complete (no change)
Z-Wave Syncing - assigning return route to "035 - Binary Sensor"
Z-Wave Debug SENT assignReturnRoute: 01 05 00 46 23 01 9E
Z-Wave Debug RCVD assignReturnRoute: 01 04 01 46 01 BD
Z-Wave Debug RCVD assignReturnRoute: 01 05 00 46 01 00 BD
Z-Wave Debug . . assignReturnRoute: node 035, success 1
Z-Wave Syncing - assigned return route
Z-Wave Debug SENT requestNodeInfo: 01 06 00 60 23 04 42 FC
Z-Wave Debug RCVD requestNodeInfo: 01 14 00 49 84 23 0E 04 20 00 71 85 80 70 72 30 86 84 31 EF 20 95
Z-Wave Debug . . requestNodeInfo: node 035, combined class list: 20v1 80v1 84v1 85v1 86v1 71v1 70v1 30v1 31v1 72v1
Z-Wave Debug SENT requestManufactureInfo: 01 09 00 13 23 02 72 04 05 43 F4
Z-Wave Debug RCVD requestManufactureInfo: 01 0E 00 04 00 23 08 72 05 00 97 11 82 45 01 E9
Z-Wave Debug . . requestManufactureInfo: node 035, manufacturerId 0097, productId 11824501
Z-Wave Debug . . requestManufactureInfo: Digital Home Systems, Temperature/Binary Sensor (iTemp)
Z-Wave Syncing - retrieved manufacture and model names: Digital Home Systems - 0097, Temperature/Binary Sensor (iTemp) - 11824501
Z-Wave Debug SENT requestVersInfoGen: 01 09 00 13 23 02 86 11 05 44 12
Z-Wave Debug RCVD requestVersInfoGen: 01 0D 00 04 00 23 07 86 12 06 02 61 00 27 04
Z-Wave Debug . . requestVersInfoGen: node 035, protoVers 2.97, appVers 0.39
Z-Wave Syncing - retrieved protocol version 2.97, app version 0.39
Z-Wave Debug SENT requestVersInfoCmdClass: 01 0A 00 13 23 03 86 13 84 05 45 97
Z-Wave Debug RCVD requestVersInfoCmdClass: 01 0A 00 04 00 23 04 86 14 84 01 C1
Z-Wave Debug . . requestVersInfoCmdClass: node 035, class command 84 using version 1
Z-Wave Debug SENT requestVersInfoCmdClass: 01 0A 00 13 23 03 86 13 31 05 46 21
Z-Wave Debug RCVD requestVersInfoCmdClass: 01 0A 00 04 00 23 04 86 14 31 01 74
Z-Wave Debug . . requestVersInfoCmdClass: node 035, class command 31 using version 1
Z-Wave Syncing - retrieved class hierarchy: Routing Slave : Binary Sensor : -- (04 : 20 : 00, base 30)
Z-Wave Syncing - retrieved command classes: 20v1 80v1 84v1 85v1 86v1 71v1 70v1 30v1 31v1 72v1
Z-Wave Debug SENT requestWakeInterval: 01 09 00 13 23 02 84 05 05 47 07
Z-Wave Debug RCVD requestWakeInterval: 01 0C 00 04 00 23 06 84 06 00 0E 10 01 4F
Z-Wave Debug . . requestWakeInterval: node 035, interval 60 minutes, wakeTarget 001
Z-Wave Syncing - retrieved wake interval of 60 minutes
Z-Wave Debug SENT requestAssociationGroupCount: 01 09 00 13 23 02 85 05 05 48 09
Z-Wave Debug RCVD requestAssociationGroupCount: 01 09 00 04 00 23 03 85 06 02 53
Z-Wave Debug . . requestAssociationGroupCount: node 035, group count: 2
Z-Wave Debug SENT requestAssociations: 01 0A 00 13 23 03 85 02 01 05 49 0C
Z-Wave Debug RCVD requestAssociations: 01 0C 00 04 00 23 06 85 03 01 05 00 01 51
Z-Wave Debug . . requestAssociations: node 035, group: 1, num associations: 1, max associations: 5, replies left: 0
Z-Wave Debug . . requestAssociations: node 035, group: 1, associations: [1]
Z-Wave Syncing - retrieved group 1 associations: [1]
Z-Wave Debug SENT requestAssociations: 01 0A 00 13 23 03 85 02 02 05 4A 0C
Z-Wave Debug RCVD requestAssociations: 01 0B 00 04 00 23 05 85 03 02 05 00 57
Z-Wave Debug . . requestAssociations: node 035, group: 2, num associations: 0, max associations: 5, replies left: 0
Z-Wave Debug . . requestAssociations: node 035, group: 2, associations: []
Z-Wave Syncing - retrieved group 2 associations: []
Z-Wave Syncing - group 1 association to interface already exists (skipping)
Z-Wave Debug SENT requestConfigVal: 01 0A 00 13 23 03 70 05 03 05 4B FE
Z-Wave Debug RCVD requestConfigVal: 01 0B 00 04 00 23 05 70 06 03 01 00 A2
Z-Wave Debug . . requestConfigVal: node 035, parm index 3, value 0 (size 1)
Z-Wave Syncing - retrieved setting: "External switch mode" is 0
Z-Wave Debug . . requestConfigVal: node 035, combined config vals: 3:0
Z-Wave Debug SENT requestConfigVal: 01 0A 00 13 23 03 70 05 06 05 4C FC
Z-Wave Debug RCVD requestConfigVal: 01 0C 00 04 00 23 06 70 06 06 02 00 00 A0
Z-Wave Debug . . requestConfigVal: node 035, parm index 6, value 0 (size 2)
Z-Wave Syncing - retrieved setting: "Enable external switch sensor" is 0
Z-Wave Debug SENT setConfigVal: 01 0C 00 13 23 05 70 04 06 01 FF 05 4D 02
Z-Wave Syncing - device "035 - Binary Sensor" setting "Enable external switch sensor" changed to 255
Z-Wave Debug . . pushNewValToNode: node 035, combined config vals: 3:0 6:255
Z-Wave Debug SENT requestConfigVal: 01 0A 00 13 23 03 70 05 07 05 4E FF
Z-Wave Debug module failed to reply to request (non-fatal, skipping request)
Z-Wave Syncing - failed to retrieve setting for parm 7: "Enable upper temperature trigger" (skipping)
Z-Wave Debug SENT requestConfigVal: 01 0A 00 13 23 03 70 05 08 05 4F F1
Z-Wave Debug RCVD requestConfigVal: 01 05 00 13 4F 01 A7 (node NAK)
Z-Wave Error Syncing - failed
Z-Wave Error No response from "035 - Binary Sensor". Module might be asleep, or is unreachable.

[matt (support)]

Does it consistently fail in the same spot (showing the same error in the Event Log)?

Try checking the Skip finding neighbor nodes checkbox in the Define and Sync dialog. Does it still fail in the exact same location?

Does it consistently fail in the same spot (showing the same error in the Event Log)?

Try checking the Skip finding neighbor nodes checkbox in the Define and Sync dialog. Does it still fail in the exact same location?

With Skip finding neighbour nodes checked it failed like this:

12 Oct 2013 09:07:26
Z-Wave Debug intiatingSyncUI (timeout in 300 seconds)
Z-Wave Syncing - started for device "035 - Binary Sensor"
Z-Wave Debug SENT getNodeNeighbors: 01 06 00 80 23 01 01 5A
Z-Wave Debug RCVD getNodeNeighbors: 01 20 01 80 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 5E
Z-Wave Debug . . getNodeNeighbors: nodeId 035, neighbors: - none -
Z-Wave Syncing - retrieved module neighbors list: - none -
Z-Wave Syncing - assigning return route to "035 - Binary Sensor"
Z-Wave Debug SENT assignReturnRoute: 01 05 00 46 23 01 9E
Z-Wave Debug RCVD assignReturnRoute: 01 04 01 46 01 BD
Z-Wave Debug RCVD assignReturnRoute: 01 05 00 46 01 01 BC
Z-Wave Debug . . assignReturnRoute: node 035, success 0
Z-Wave Error Syncing - failed to assign return route
Z-Wave Debug SENT requestNodeInfo: 01 06 00 60 23 04 F0 4E
Z-Wave Debug RCVD requestNodeInfo: 01 06 00 49 81 00 00 31
Z-Wave Debug RCVD requestNodeInfo: failed (module asleep or doesn't support command)
Z-Wave Error Syncing - failed
Z-Wave Error No response from "035 - Binary Sensor". Module might be asleep, or is unreachable.
Z-Wave Debug RCVD nodeAwake: 01 08 00 04 00 02 02 84 07 70
Z-Wave Debug . . nodeAwake: node 002 (queued awake processing because sync in progress)

[matt (support)]

Are you sure the module is awake? It is failing in a different (actually earlier) spot, so it looks like it is either going to sleep or there is a range/interference problem. Keep trying it several times (and keep waking it up, however that module has you wake it up) and see if it eventually succeeds.

Are you sure the module is awake? It is failing in a different (actually earlier) spot, so it looks like it is either going to sleep or there is a range/interference problem. Keep trying it several times (and keep waking it up, however that module has you wake it up) and see if it eventually succeeds.

I don't know enough about the protocol (Zensys is insane for not publishing imho) but it seems to me that the device does not stay awake for long enough to receive all the configuration commands you are sending. If I wake it up a second time, the "awake processing" is queued because sync is in progress and so the configuration fails, thinking the unit did not wake up.

Z-Wave Debug RCVD nodeAwake: 01 08 00 04 00 27 02 84 07 55
Z-Wave Debug . . nodeAwake: node 039 (queued awake processing because sync in progress) <---- I TRIED TO WAKE IT
Z-Wave Debug module failed to reply to request (non-fatal, skipping request)
Z-Wave Syncing - failed to retrieve setting for parm 8: "Enable lower temperature trigger" (skipping)
Z-Wave Debug SENT requestConfigVal: 01 0A 00 13 27 03 70 05 0A 05 58 E0
Z-Wave Debug RCVD requestConfigVal: 01 05 00 13 58 01 B0 (node NAK)
Z-Wave Error Syncing - failed
Z-Wave Error No response from "039 - Binary Sensor". Module might be asleep, or is unreachable.

Perhaps the solution is make the sync as quick as possible, just the bare minimum of commands and queue the configuration commands for the next wake up interval. They will get there eventually or could be helped out with another manual wakeup (quick press of the tamper switch) after the sync is done.

Another option may be to ignore the nodeAwake command when sync is in process instead of queueing its processing? But if you take this approach your customers will HAVE to wake it twice for the sync to complete.

Please forgive me if any of the above is utter nonsense. As mentioned above I am fumbling in the dark with insufficient information from Zensys and the sensor manufacturer.

I'm also unable to get the temperature working with my FGK 101 module. The Sensor itself is working fine since I started playing with Indigo and some modules (just had to tripple click the tamper button again to get it synced).
Now I just received some Dallas DS18B20 chips and added one to my sensor but there is no way to get the temp shown/added in Indigo. I even removed the battery in the sensor, reassociated it or resynced it. The sensor itself is just fine with open/close signal and tamper button recognized but no temp signal shown.

Has someone already added a FGK101 and than added a DS18B20 chip? Is there something special to get the temp added or should a simple resync work?

@Additional Note: I just added a second FGK101 with temp chip added before inclusion and this worked as ecpected. So Indigo 6.0.3 shows all 3 inputs (door/tamper/temp). Just can't get the already included sensor to show the temp chip I just added.

Hi,

It is an issue that I have for a long, and not only with 6.0.3.
The only way I found is :
- delete the sensor from Indigo
- unpair it
- reboot the sensor as explained in the sensor documentation
- then pair it again an so on...

This worked for the 3 sensors I have when I added temperature sensor inside.

[matt (support)]

Perhaps the solution is make the sync as quick as possible, just the bare minimum of commands and queue the configuration commands for the next wake up interval.

That does appear to be the case -- it isn't staying awake long enough. You might try removing the batteries; some modules will stay awake N minutes after batteries are inserted.

Another option may be to ignore the nodeAwake command when sync is in process instead of queueing its processing?

The way the wake command protocol works is the module sends an "I'm Awake" message to the controller, then the controller should have some time to do communication with that module, then when it is done the controller (Indigo) sends a message to the module for it go back to sleep. That is why Indigo ignores incoming nodeAwake commands while it is processing. If it processed them then it would command the module to go back to sleep, which would cause the sync to fail.

In this case I'm not sure what exactly is happening. Indigo is trying to sync, and then the module becomes unresponsive and you try to wake it but your wake doesn't really keep the module awake (even though Indigo isn't sending the go-back-to-sleep command).

Do you only have one of these modules? If not, do they all fail to sync?

MacDefender and bip.philippe: are you able to sync your modules with Indigo 6.0.3?

@Additional Note: I just added a second FGK101 with temp chip added before inclusion and this worked as ecpected. So Indigo 6.0.3 shows all 3 inputs (door/tamper/temp). Just can't get the already included sensor to show the temp chip I just added.

That is correct. I believe the instructions manual says you have to add the 1-wire sensor while the module is totally excluded from the Z-Wave network, then you have to include it with the Z-Stick. Otherwise, it won't recognize the temp sensor.

Just an observation, I think this thread may be discussing two different modules. The one I am using does not need a Dallas 1-wire temperature sensor, the sensor is built in.

The device is called ZME_ITEMP and can be seen here:

http://bit.ly/1dIEp51

Good news though, I have been able to get the unit to sync with 6.0.4 using the following approach:

1. Check “Skip finding neighbour nodes during sync"
2. Press and hold tamper switch for five seconds then RELEASE four times
3. Press indigo SYNC, then keep clicking tamper switch over and over

I *think* that the device only wakes for 2.5 seconds, so clicking the tamper switch repeatedly keeps waking it up. After about 30 seconds the sync completes. This appears to be repeatable.

Spoke too soon.

It may have synched but it seems to think the temperature is -70.48 C. I'm pretty sure it is warmer than that in here.

Any ideas?

2013-10-25 15:48:14 Z-Wave Debug RCVD requestVarSensorStatus: 01 0C 00 04 00 29 06 31 05 01 42 E4 78 33
2013-10-25 15:48:14 Z-Wave Debug . . requestVarSensorStatus: node 041, endpoint None, type 1, raw value 42E4...
2013-10-25 15:48:14 Z-Wave Debug . . requestVarSensorStatus: -70.48 °C (float: -70.480000)

Now it is reporting -66.80, so something is changing. Could the translation to degrees C be buggy?


Z-Wave Debug RCVD requestVarSensorStatus: 01 0C 00 04 00 29 06 31 05 01 42 E5 E8 A2
Z-Wave Debug . . requestVarSensorStatus: node 041, endpoint None, type 1, raw value 42E5...
Z-Wave Debug . . requestVarSensorStatus: -66.80 °C (float: -66.800000)
Z-Wave Debug . . nodeAwake: inhibit count-- to 0
Z-Wave Debug . . nodeAwake: stopping inhibit sleep timer
Z-Wave received "Cheap Probe - Temperature" sensor update to -66.80 °C
Z-Wave Debug SENT goToSleep: 01 09 00 13 29 02 84 08 05 6E 29

[matt (support)]

I just manually decoded it and it is indeed sending the value -70.48 °C. If I ignore the negative sign bit then it decodes to 588.56 °C which is even more wrong.

That module does have a temperature offset parameter setting (Indigo doesn't have UI for that parameter yet), so perhaps it is in a bad state and has a large negative offset in that parameter. Try what bip.philippe suggested to see if that can get it to reset:

- delete the sensor from Indigo
- unpair it (from Z-Stick)
- reboot the sensor as explained in the sensor documentation
- then pair it again an so on...

(I just noticed bip.philippe is probably talking about the Fibaro not the sensor you have, regardless do try to factory reset your sensor by unpairing it with the Z-Stick)

Thanks Matt.

I must say, this z-wave stuff is very hard work. I seem to have issues with nearly every z-wave device, it is pretty clear that z-wave just isn't ready for prime time yet, it kinda feels Mickey Mouse. Yours is by far the best server software though (I have Vera and HC2), the problem is with devices that just don't seem to work out of the box.

The pair/unpair was already done several times because pairing is such a pain in the neck with this device, it took hours of fiddling before I came up with the sequence that works.

The temp sense can go in the "naughty device" box with all the other problematic devices.

Thanks

Steve

[matt (support)]

I don't think it is much Z-Wave as some specific modules/manufactures. I've had great luck, for example, with Aeotec's Multi-Sensor and Door/Window sensor, and the Trane thermostat. Some modules definitely have issues though, but I think it is just flakey firmware and not really the Z-Wave comm stack.