Samsung SmartThings MultiSensor shows in deCONZ, not in Phoscon's app or JowiHue

[HouseholdGeek]

Newbie. Maybe I'm missing something about the proper procedure...

I've finally got deCONZ GUI working, and Phoscon's app sees it (and shows the virtual 'Daylight Sensor').

I've Registered the bridge in JowiHue, and HomeSeer's Control shows three "Devices":
- 'Phoscon GW'
- 'All Lights (root)'
'- All Lights'
I have a Samsung SmartThings Multi-Sensor, that seems to be listed in the compatible devices list, it shows in deCONZ, but nothing comes up in either Phoscon's app or in JowiHue when I Select add sensor and initialize the device.

It should show a temperature sensor, a shock sensor, and a door open/close switch.

What am I missing?

There might be two Samsung Multisensor products, but I'm not sure if that's the case, or if I have a different one than is listed.

Should this device show with either Phoscon or JowiHue or both?

Thanks for any help!

[w.vuyk]

How does the device show in the deCONZ map? Does it have a name like 0xnnnnn or a readable name like "multisensor nn"?
If deCONZ map shows the name with the oxnnnnn, it means deCONZ has seen the device, but the REST API plugin has not yet recognized the device. Which either means it is not yet supported or more effort is needed to get all attributes filled.
What is the type information on this device, at this point I can only guess?

A trick to help the device being recognized that often works is to go to the bridge maintenance of the plugin (no need for Phoscon!) and select scan for devices. This will run for 2 minutes. In that time, go to the deCONZ GUI, go to the device and click on the far right dot (can be a bit of a hassle to get that done).

A menu will appear with the basic cluster line as top choice (check image). Select this basic cluster. Then select the cluster info tab and click the button read. You should see the device information appear in the attributes. If after this read the name changes from 0xnnnn to a readable name, you will see the device appear in the JowiHue plugin and the first device is active.
If not, it might not (yet) be supported.

What is the version of deCONZ you are running running at this point?

Wim

[HouseholdGeek]

Ahhh! Thanks Wim. deCONZ v2.10.4 , and yes the name for the device is in the form 0xnnnnn.

(So Phoscon is not required to use JowiHue? I didn't realize that.)

I confess, I completely missed the 'two right' buttons. I thought they might be lights. (😳 I guess I need to go sit in the corner & RTFM - do my homework)

I did as you suggested, and the name did not change, so I have to guess that the MultiSensor model that I have is different from the one they have listed.

I guess I'll be learning the next step of submitting a request for adding a device to the 'compatible' list. I'm hoping not too a difficult a process?

My "main reason" for adding the ZigBee capability to my HomeSeer system is because of a LeakSmart valve that I like (which only comes in Zigbee). I had it working with Wink, and it works really well (needless to say, have dropped Wink). So the valve has been my primary goal, at this point.

I had a couple of these ZigBee sensors sitting around that I thought I'd start with, to see how deCONZ/Phoscon/JowiHue all works.

Learning....!

Thanks for your help!

--
Chan

[w.vuyk]

Do you have the modelid of the multisensor? Also, after you did the read on the basic cluster, I expect the cluster information was filled in deCONZ? Could you post an image of the attributes? I can seek for more confirmation if the device is supported or not.
Do you have the same info for the LeakSmart valve? Im am not sure if those are supported yet? What is its function?

Thanks,

Wim

[HouseholdGeek]

Wim, interesting 'development'. I re-paired the MultiPurpose Sensor, and "Read" the Basic attributes again. The device has now adopted a name, and JowiHue has taken it in.

A couple of problems though:
In HomeSeer it shows a number of devices, tilt sensors, vibration sensor, no temperature sensor, no door/window switch at all.
In Phoscon, it shows Vibration and Temperature, and a little Door, but the door doesn't change to a "Closed" indicator when closed (images below)



Also, to see if the door sensor would come up, I re-paired the device again, (after 'deleting' the devices in the HomeSeer Device Management screen, deleting in Phoscon, and attempted deleting in deConz, in deCONZ the device immediately popped back up with the 0xnnnnn name). After this re-pairing, and 'Read' in deCONZ, the Temperature sensor doesn't come up in the JowiHue HomeSeer devices, though it does show in the Phoscon app. Also, The NAme of the device was changed in deCONZ, from "Vibration 7" to "Vibration 10" to "Alarm 9" - Don't know if this is normal.

The deCONZ info for the Waxman LeakSmart Valve (it's a 1" whole-house valve), is below:



I wasn't sure if you wanted all the attributes' images or only the "Basic" ones. If you need more, I'll gladly provide them...

Thanks for all your help!

--
Chan

[w.vuyk]

Two issues I can see here. The plugin has not yet fully got all attributes (battery is 0%) it can take up to an hour before the sensor sends an report that will be telling the tru value of the battery. Another is that I am not 100% sure the vibration sensor wil be including the two extra sensors for temperature and the window switch. This does work with the HS4 version of the plugin as it is more 'dynamic' in combining devices. But I seem to remember there was another user with the same sensor on HS3 and he did get it to work.
It might be a good idea to stop and start the plugin in the plugins page to force the plugin to refresh things once.

Wim

[HouseholdGeek]

Ok great, that's helpful. I'll search for the user who got it to work. Looking over the deCONZ screens gives me absolutely no idea how I might get it to see the door switch. But then I am completely ignorant here.

I've re-paired it a few times now, to see what might come up. The image I showed here seems to be the 'all' of it. I've learned that it really helps when pairing to leave the device close to the hub while it populates its capabilities.

After stopping and restarting the plug-in HS shows fewer devices for the MultiSensor...




Do I understand you to be saying I should sometimes leave it close to the hub for an hour after pairing, to aquire all the device's capabilities? Or are the basic attributes read relatively quickly, and then the values for those attributes are acquired over time, possibly over a longer distance connection, with handshaking of some sort? Forgive me my ignorance, I'm comparing RS-232 type communications...

Thanks.

--
Chan

[w.vuyk]

No need to keep it close to the hub. When you have "routers" (lights, plugs, repeaters etc) in the house you do not need to be holding the device close to the hub at all. The routers build the mesh network which allow you to go beyond the range of the hub. When you have only a hub you can place a battery device up to 30 meters (90 feet) away from the conbee, depending on walls, interference etc. I limit it for myself to 15 meters (45 feet) as I have concrete walls in the house. If you want larger distances, add a plug or a light (not Sengleds!) which will act as a router and extend the range with another 15 meters, if you place the device 15 meters away.

Reporting is automatically done from the spot where the battery device (-=end device) is placed. No problem.
Looking at the image you posted, I think the temperature device is placed in another grouped device as the vibration sensor is expected to be a single device. Samsung is joining this in one device, which is not what the HS3 plugin is expecting. In the HS4 plugin this is caught indeed and all are joined in a single device.
But I stil do not see the open/close sensor. It might be worth trying to remove the multipurpose sensor from HS3 (not deCONZ!) and restart the plugin to see if the device gets created correctly. It is a bit of a challenge to get this one right...

[HouseholdGeek]

Thanks much Wim.

I understand the mesh (I think) but it seems that I remember instructions that recommend 'on initial pairing the device should be near the hub'...? I assumed it was to be sure that all the capabilities of the device were communicated accurately to the hub? Or maybe that's only a Z-Wave thing?

About the sensor... I did find the thread in GitHub where they discussed this sensor, and the solution they found for getting the door-open attribute (is that the correct word?) recognized (https://github.com/dresden-elektroni...eta/issues/199), so that's on its way to working.

The door-open function now shows in JowiHue & HS (and oddly does not show in Phoscon). And yes, now I see that sometimes the JowiHue plugin takes a bit of time to adopt all the device's functions.

Again though, after starting and stopping the plug-in, the HS devices are thinned out, and the following from the above screenshot go missing:

• Orientation x, y, and z
• Tilt angle
• Vibration
• Vibration strength
• Position

And all that remains today is this (with 2 "Roots"?):


edit: and now I see that those missing attributes in the JowiHue/HS, after restart that I mentioned above, are all listed in deCONZ in the 'manufacturer specific' cluster, the Samjin cluster.

So I'm making some headway...

Thanks again.

--
Chan