Is there a way to read deviceData visible in the Data section of a device

I’m trying to read the data section for IP, model, port and username from a LAN Hue Bridge" instance.

getDeviceNetworkId() returns perfectly the device ID, however I would need to read the username value visible in the “Data” section of the device page.

currentValue(“username”) returns null, so that is not the answer here.

Best regards,
Tapio

I’ve seen getDataValue mentioned in the context of getting IP information, so perhaps getDataValue(“username”) might be worth a look.

Uhm…that’s settings.username in the DTH. Is there a reason you can’t use that? Or are you trying to get this from an app? You can’t read device settings in an app because they’re not published.

I am assuming Super LAN connect sets those up when a Hue Bridge is connected, I am trying to interact with that bridge, however I can not read the IP-address nor the paired username for the bridge, which is visible.

For some reason Super LAN connects Hue bridge does not publish the information anymore for device.currentValue().

This is the reasoning for the idea if it possible to read the data section of the device from an 3rd party SmartApp such as @verbem’s Hue Sensor (connect), which has recently stopped working since the information can not be accessed.

Then your only option is to manually copy and paste it into another app.

Have tried https://docs.smartthings.com/en/latest/ref-docs/attribute-ref.html?

I kind of remember the data are accessible tricking this.

But the data is not an attribute. You can’t pull it out through an attribute unless it’s published as one by the DTH.

you sure?

def host = getDataValue("ip")

def port = getDataValue("port")
   
def path = getDataValue("query_path")

work fine in my case

From an app? From within the DTH of course it will work. But this is not from within an app, like the OP asked.

From Smartapp you indirect through the device like: device.value.mac or whatever value.

selectedDevices.each { dni ->
def selectedDevice = devices.find { it.value.mac == dni }
log.debug selectedDevice
def d
if (selectedDevice) {
d = getChildDevices()?.find {
it.deviceNetworkId == selectedDevice.value.mac

Device Network ID is not just a part of data…that’s a special case. If you read the whole post, the OP is trying to pull “username” which is stored in data into another app. And according to the Devcie API, there is no way to pull out device data that is not published as an attribute except for the DNID, the display name, the capabilities, the Hub, the Id the label, and the driver in use.

https://docs.smartthings.com/en/latest/ref-docs/device-ref.html#device-ref

I don’t see getData in there.

I was pointing out the “mac”, not the networkid.

OMG…the mac IS the DNID!!! The point is the OP wanted to pull out USERNAME. Do you see anything about being able to pull out USERNAME?

So in essence, what ever Super LAN Connect does with Philips Hue Bridge (LAN Hue Bridge) it does no more publish the required information to be used by SmartApps. Something has changed in it and the question is then, that if it should be fixed? I could not really find any practical information on the behaviour of SLC with Hue Bridges.

Why do you need the username from this device? Just connect to your hue bridge in your smart app. It’s not hard. There’s a public API.

As I said before, trying to use "Hue Sensor (connect) SmartApp to enable the use of Hue Sensors behind the LAN Hue Bridge. Since it is already connected and the code already exists, it would make sense to it. Sure I could build all new code.

The benefit of this SmartApp is, that it has support for Hue Motions sensors, Hue Tap and Hue Switches. So far I have not seen support for all of those devices in any other place.

Wait…I’m not understanding what your smartapp is trying to do. If this other app is already connecting and bringing over your hue devices, what is your app trying to do?

If it’s a third party app, you should have the code for it…which means you should be able to modify it however you want. Why do you have to pull the username out by an app call. Just pull it out by hand for goodness sake and enter it in your app in an input. This is ridiculous.

And if you’re saying this other app is no longer connecting to you bridge, then it just has to be re-authorized. All this bs about username is pointless because the hue bridge username is set up when you request access through the hue api.

Workaround:

In DTH:

    attribute "nameDevice","String"

In any method of the DTH that would run once:

sendEvent(name: "nameDevice", value: getDataValue("query_path"))

(query_path still being my data value, username in the above case)

In SmartApp:

log.debug theDevice.currentValue("nameDevice")

7:33:59 PM: debug /airmentorpro2.php?Action=get

The problem here is that I do not have access to LAN Hue Bridge (DTH from Super LAN Connect) source code. Seems that SmartThings developers have removed the access to the needed values (IP and username). At this time it is impossible to get even the IP of a Super LAN connect discovered Hue Bridge.

It would be easy to iterate all connected Hue Bridges with manual configurations. Thats what SLC is there for, right? It is true that the code for @verbem’s Hue Sensor (connect) could be written with static configurations, but would be need quite a bit of rework as currently it would be capable to connect to any LAN Hue Bridge.

I am not sure I understand how that is supposed to work but few things I am thinking.

  1. IP address, if you assign fixed IPs, you won’t need to query them all the time.
  2. port seems fixed.
  3. Model and username: if smartthings DTH “LAN Hue Bridge” is able to get it from the bridge, then there will be a way to query if once you know the IP.

Since username is not an attribute, it means it is not a setting of the DTH that is manually entered hence it’s collected from somewhere.

© 2019 SmartThings, Inc. All Rights Reserved. Terms of Use | Privacy Policy

SmartThings; SmartApps®; Physical Graph; Hello, Home; and Hello, Smart Home are all trademarks of the SmartThings, Inc.