Help with Attributes vs Capabilities? (Grovestreams + Netatmo)

Developer Programs Writing SmartApps
1

Hi, I use the Grovestreams by @JasonBSteele and love it - I have a critical need to monitor my sump pump frequency. I recently purchased a NetAtmo system with Rain Gauge as I need to correlate rain vs sump pump frequency to try and determine the source of the water under my house. I use @Dianoga /SmartThings Labs’ NetAtmo (Connect) SmartApp to integrate to ST.

However, I really need to use the data from NetAtmo and post it up to Grovestreams so I can overlay the two. It’s fairly easy to add new data to the GroveStreams app based on Capabilities, but in the case of the NetAtmo (Connect), it gives the rain as an attribute.

GS Code example:input "temperatures", "capability.temperatureMeasurement", title: "Temperatures", required:false, multiple: true

Anyone know how to add this attribute into the GroveStreams code?

definition (name: "Netatmo Rain", namespace: "dianoga", author: "Brian Steere") { 
 	attribute "rain", "number" 
         attribute "rainSumHour", "number" 
         attribute "rainSumDay", "number" 
         attribute "units", "string"
2

I believe the syntax to refer to an ad hoc Attribute is “device.rain”.

3

[quote=“RobR, post:1, topic:39987”]
Anyone know how to add this attribute into the GroveStreams code?
[/quote]The link you provided above for the NetAtmo (Connect) Device Handler doesn’t include any of the rain related attributes shown in that code segment and it appears to only be a partial implementation so I can’t give you specifics.

You basically just have to choose a Capability that the NetAtmo Device Handler supports so you can select it in the GroveStream app and then get the rain attribute using either device.theRain or device.currentValue(“rain”).

1 Like
4

Sorry, the link was for the main code - the code for the rain add-on is here: https://github.com/fuzzysb/SmartThingsPublic/blob/master/devicetypes/dianoga/netatmo-rain.src/netatmo-rain.groovy

5

I’m unfamiliar with either of these devices so I’m basing this post off of a lot of assumptions. There may be a better way to handle this and I’m not sure if the code will even work, but it will hopefully point you towards a solution.

If you add capability “Polling” above attribute “rain”, “number” you’ll be able to use an input statement in the Grovestreams code similar to:

input "rains", "capability.polling", title: "Rain Sensors", required:false, multiple: true

If you’d rather not modify the rain device type, I think you can include it in the Grovestreams code by doing the following instead:

input "rains", "capability.sensor", title: "Rain Sensors", required:false, multiple: true

Edit: Using this method would still require you to edit the rain code, but you would add capability “Sensor” instead of capability “Polling”. I’m not sure which capability is better, but since you’re using it as a Sensor, that might be more appropriate.

Once you’ve added the input, you can add the following to the initialize() function:

subscribe(rains, "rain", handleRainEvent)

And add the rain event handler like:

def handleRainEvent(evt) {
	sendValue(evt) { it.toString() }
}
6

Thanks a ton for the response, Kevin. A couple clarifications/questions:

The Rain Sensor code from ST Labs includes command "poll" in it - is this sufficient in any way? If not, and I need to edit the rain device type, I assume that would mean forking the ST Labs code and adding a custom device type in the IDE?

metadata { 17 definition (name: "Netatmo Rain", namespace: "dianoga", author: "Brian Steere") { 18 attribute "rain", "number" 19 attribute "rainSumHour", "number" 20 attribute "rainSumDay", "number" 21 attribute "units", "string" 22 23 command "poll" 24 }

7

I find it really odd that the device handler wouldn’t already have a capability and since you mentioned that the rain piece is an add-on, I’m starting to think it might be inheriting capabilities from the parent.

In the Grovestream app, does the “rain” device show up in the list of devices you can choose from for any of the inputs? If so, which capability is that input using?

8

Rain doesn’t, unfortunately - temperature from the Netatmo unit does show up under “Temperatures” in the grovestreams app. That, however, is listed as a capability in the Netatmo Device code:

metadata { 
17 	definition (name: "Netatmo Basestation", namespace: "dianoga", author: "Brian Steere") { 
18 		capability "Relative Humidity Measurement" 
19 		capability "Temperature Measurement" 
20 
 
21 		attribute "carbonDioxide", "string" 
22 		attribute "noise", "string" 
23 		attribute "pressure", "string" 
24 	}

It’s also worth noting that I can see events from the Rain sensor coming through live logging (at least when it is raining)

Unfortunately, I don’t know enough about ST/Groovy to understand why all the other sensors are capabilities and why rain is attribute. Maybe @Dianoga or @bflorian are willing to chime in :slightly_smiling:

9

Thanks for the suggestion @tgauchat - unfortunately unless I did something else wrong, it didn’t help. It gives me a chooser in the UI, but no devices are listed:

input "rain", "device.rain", title: "Rain sensor", required: false, multiple: true

10

That’s what I initially thought so my original instructions were correct. You’re going to have to add a capability to the rain device handler in order to be able to use it in the grovestream smartapp.

Create the new device handler by copying the existing rain device handler, add the line capability “Sensor” above the first attribute line.

Then you’ll be able to add the following to the grovestream app which will allow you to select the rain device.

input "rains", "capability.sensor", title: "Rain Sensors", required:false, multiple: true

In order to capture the rain device value, you’re going to have to subscribe to that event in the initialize function using:

subscribe(rains, "rain", handleRainEvent)

And add the rain event handler like:

def handleRainEvent(evt) {
    log.debug "${evt.value}"
	sendValue(evt) { it.toString() }
}

Edit: I just added the debug line above the sendValue line because I’m not exactly sure what the sendValue line does. I only included it because that’s what all of the other event handlers in the Grovestream DH have.

11

A capability just defines the commands and attributes that a device has.

For example, if a device has the “Polling” capability, then you know that it has a poll command. If a device supports the “Switch” capability, then you know that it has a switch attribute that you can use to determine whether the device is on or off and it will also have an on command and off command…

13

[quote=“tgauchat, post:12, topic:39987”]
Attribute syntax is only for use inside a Device Type Handler to access ad hoc Attributes for Tiles.
[/quote]I’m fairly certain that device.rain won’t work anywhere and you have to use either device.currentValue(“rain”) or device.theRain.

15

I see your point with Tiles, but the original question is about getting the attribute from one device handler into a SmartApp so we already knew the context.

1 Like
16

[quote=“tgauchat, post:12, topic:39987”]
In the SmartApp input statement, it is “device.personaldevicetypename” and the Device must be in your namesspace. I think you just remove spaces and convert to lower case, but I’ll have to check.
[/quote]This might be possible, I’ve never tried it, but if you use capability.sensor instead of the device type name, you don’t have to worry about casing and it doesn’t have to be in the same namespace.

1 Like
17

Sorry… I forgot about the original question or it didn’t sink in.

A SmartApp has access to the Attributes of all of the selected Devices via the methods of the Device Object (note not the same methods as the Device Hanlder Object!).

Therefore, “<attributename>State” (i.e., <device>.rainState) should work if you’ve defined attribute rain in the DTH and have set it’s value inside the DTH using sendEvent(name: "rain", ...).

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

The above documentation also shows that supposedly <device>.currentRain should also work, and <device>.currentState("rain") and <device>.currentValue("rain").

18

That’s not what you were originally suggesting which is the only reason I said something.

19

I know…

But NB: in the SmartApp it isn’t device.rain, it is device.rainState (and the other alternative syntaxes I listed).

The device.rain syntax is usable only in the Tiles() methods of a Device Type Handler. It is entirely different from device.rainState. Confusing as heck! :confounded:

20

[quote=“tgauchat, post:19, topic:39987”]
The device.rain syntax is usable only in the Tiles() methods of a Device Type Handler.
[/quote]I’m not disagreeing with any of the information you’ve posted, all that I’m saying is that the original post provided context and had nothing to do with tiles so by recommending device.rain as a solution, you’ve made things a lot more complicated than they needed to be.

I’m sure a lot of people on here, including myself, at one time or another have misread a post and provided inaccurate information based on the context of the question, but IMO it’s a lot more productive to just say that’s what happened instead of providing additional somewhat unrelated information in order to justify the initial response.

21

OK, I’m up for trying that out. One more question: Since this is a multi-file device type, and I don’t see the equivalent of references or includes in the netatmo-rain.groovy, how do I add it in as a custom device type? And will it overwrite the smartlabs device type, or do I need to alter the namespace so that I will have a second “Netatmo (Connect)” available in the app to me?

And/or since this is in the SmartThingsPublic branch of GitHub can I modify the original and have ST bring it in?

metadata {
	definition (name: "Netatmo Rain", namespace: "dianoga", author: "Brian Steere") {
	capability "Sensor"
        attribute "rain", "number"
        attribute "rainSumHour", "number"
        attribute "rainSumDay", "number"
        attribute "units", "string"
        
        command "poll"
	}
22

Interestingly enough, I made the changes to the netatmo-rain.groovy and published it for me as a Device Handler, although I’m not sure that’s correct (see my previous post’s question), but I also made all the changes to the Grovestreams smartapp and under the “Rain sensors” choice in the app, I now get ALL my sensors but lo-and-behold the Rain sensor is there, so I’ve selected it.

Now I just need some rain to come to test it…