Version 1.7.1 made a mess; reverted to 1.4.1

[pofs]

I've looked into your log, but it is still somewhere in the middle of the Version interview. It did not start querying command classes on channels yet, so I cannot tell you where it fails to get your temperature sensor.
Please provide the entire log from the beginning of inclusion up to the moment there was no jobs left in the queue (use inspect queue window to monitor that). Snapshot of /ZWaveAPI/Run/devices[id] after inclusion is also welcome.

[pz1]

I have to wait until devices are returned from by my supplier. I expect to respond in a couple of days

[pz1]

I've looked into your log, but it is still somewhere in the middle of the Version interview. It did not start querying command classes on channels yet, so I cannot tell you where it fails to get your temperature sensor.
Please provide the entire log from the beginning of inclusion up to the moment there was no jobs left in the queue (use inspect queue window to monitor that). Snapshot of /ZWaveAPI/Run/devices[id] after inclusion is also welcome.

Attached is the log file

z-way-server-log-fragment.zip

(203.86 KiB) Downloaded 315 times

from the start of Z-Way. The fragments I published before, are part of this file, so the relevant starting point can be found by comparing date/time. I hope this helps.
Note: My system is calling the OpenRemoteHelper functions frequently.

[pofs]

Ok, I think here is the relevant fragment:

Code: Select all

[2014-07-08 16:26:00.254] RECEIVED: ( 01 0A 00 04 00 27 04 60 08 40 02 F8 )
[2014-07-08 16:26:00.254] SENT ACK
[2014-07-08 16:26:00.255] SETDATA devices.39.data.lastReceived = 0 (0x00000000)
[2014-07-08 16:26:00.255] SETDATA devices.39.instances.0.commandClasses.96.data.dynamic = False
[2014-07-08 16:26:00.255] SETDATA devices.39.instances.0.commandClasses.96.data.identical = True
[2014-07-08 16:26:00.255] SETDATA devices.39.instances.0.commandClasses.96.data.endPoints = 2 (0x00000002)
[2014-07-08 16:26:00.255] SETDATA devices.39.instances.0.commandClasses.96.data.endPoints.1 = Empty
[2014-07-08 16:26:00.255] SETDATA devices.39.instances.0.commandClasses.96.data.endPoints.2 = Empty
[2014-07-08 16:26:00.256] Node 39:0 CC MultiChannel: 2 endpoint(s)
[2014-07-08 16:26:00.256] Node 39:0 CC MultiChannel: Endpoints identical - check only 1
[2014-07-08 16:26:00.256] Adding job: MultiChannel capabilities (v2) get
[2014-07-08 16:26:00.313] SENDING (cb 0x4a): ( 01 0A 00 13 27 03 60 09 01 25 4A C5 )
[2014-07-08 16:26:00.324] RECEIVED ACK
[2014-07-08 16:26:00.334] RECEIVED: ( 01 04 01 13 01 E8 )
[2014-07-08 16:26:00.335] SENT ACK

For some reason, device reports only two endpoints, while temperature Multilevel Sensor should be on the third one. Because of that, channel 3 is never interviewed, so there's no temperature sensor.

Not sure why it happens. Would be interesting to compare with 1.4.1 log.

[pz1]

I am slowly coming to the conclusion that it may be a wiring issue. More details to follow

[pz1]

More details to follow

Capture.JPG (45.75 KiB) Viewed 9638 times

My wiring is as shown in the above image. To the left there are 4 RJ45 connectors to which I intended to connect the respective sensors using Cat5 twisted pair cables. The setup is in essence a short bus connecting the 4 RJ 45 jacks to the 1-wire lines of the Fibaro device. The connectors also do supply power and ground via orange/orange-white wires to the sensors.

From these connectors there are drop-down lines planned of a couple of meters length. The data line(green), is twisted with the white/green that is terminated to ground on the Fibaro end, but not connected to the ground on the sensor end.
NOTE The Fibaro requires you to re-include the device every time one or more sensors are added/deleted/replaced.

If I attach four sensors as described above, the device will not include properly. It does work if I connect only one sensor to any of the four that are available. So it seems all connections ar OK.
If, using a "breadboard" I connect four sensors on a row via one single cable. All sensors show up after inclusion, and the temperatures do show correctly.

If I read other documentation on 1-wire topologies, the short bus with moderate length wires is allowed. My total wiring length is far less than the 30m specified by Fibaro.
I have tested with two Fibaro Universal Sensors, that came in identical boxes with identical version numbers and identical manuals. The interview results are different however. Also the product ID as seen in the Expert UI differ. The recently bought device has ProductId: 4098, the one I got in 2012 has ProductId: 258

I am puzzled.

PS: This device is rather hard to include with RaZberry. My experience is that you have to position it quite close to the controller. It is also important to watch the queue while including. Only make a second attempt after the queue is empty of calls to this device. My most recent experiments were done using version 1.7.2

[pofs]

> The recently bought device has ProductId: 4098, the one I got in 2012 has ProductId: 258
This is actually very strange, especially if you write down numbers in hex. First one will be 0x1002, and the second is 0x0102 (the correct one).
My guess is, there was some flashing error, and 0x0102 turned into 0x1002. Who knows what else might go wrong

Also, I found the recommended wiring for cat5 cable, and it appears to be different from yours:

Cat5_cable_connect.jpg (27.86 KiB) Viewed 9548 times

A Cat5 cable has 4 twisted pairs. Connections would go like so:
Take 1 of the twisted pairs, and...
- connect the sensor data pin to one lead,
- and connect the sensor ground pin to the other lead.
- take another twisted pair, and connect the sensor V+ pin to one lead.

Some people have suggested grounding unused leads in a cable. The document above (1-Wire Design Guide) says don't, as this will increase capacitance, which increases loading, which degrades the data signal.

[pz1]

Also, I found the recommended wiring for cat5 cable, and it appears to be different from yours:

Because the forum does not register updates to posts, I had not spotted your update of this post until just now.
As a matter of fact I had done the same modification, i.e. in my case use the green for data, and the green/white for gnd. Made no difference as a matter of fact.

There are other documents suggesting some pull-up resistors for the data line. In other places it is said that Fibaro already contains a pull-up resistor. So I did not try that, as it might harm the Fibaro.

As to the Product Id's; the devices may be different, as the new one reports in the interview that it does support FirmwareUpdate. I can post interview results of both if you want.

PS: none of the three FGBS001 definitions from Pepper1 has this number, but also none mention the capability.
PS2: Added the JSON files of both devices

[pofs]

As to the Product Id's; the devices may be different, as the new one reports in the interview that it does support FirmwareUpdate. I can post interview results of both if you want.

PS: none of the three FGBS001 definitions from Pepper1 has this number, but also none mention the capability.
PS2: Added the JSON files of both devices

I don't actually think that adding a new CC (FirmwareUpdate) is a reason strong enough to change the entire product identification.
The interesting thing is, the new device has lower application version (2.1) than the old one (3.49). Maybe that's why product id was changed.

[pz1]

In the meantime I did write to Fibaro for suggestions. I'll be back on this then.