Like on SmartThings, devices cannot reference other devices directly (though there are some exceptions with parent/child relationships). To get a reference to a device, you'll need a SmartApp/app. So, what you want is something like this in an app:
and then you can call a command like this somewhere else in the app:
myDevice.deviceNotification("This is my notification text")
Also, it is indeed deviceNotification(), but I always forget, so apolgies for probably typing it both ways above depending on what I thought was correct at that time. The Capability List docs show the command names (and the capability names you can use to select for devices that implement them), if you haven't seen this already.
thanks.
but if I can't do it on a device (device can not reference another device), then how can I achieve this from my device ?
my final target is to make a virtual device which would represent a server at home.
I have that part of the code ready. The device actually uses the hub to ping a configured IP address and shows is status (up/down) with Presence capability.
Now I want to add a notification to the device, so that when the ping fails, it would send a notification to my phone.
From what I know, only apps can communicate with other devices/driver where a device/driver can only talk to its parent (device or app) or a child device.
In your app config section, you could use something like this to select a single or multiple notification devices:
input "notifyDevices", "capability.notification", multiple: true,
title: "Choose your notification devices"
Then you can use a function to send the text notifications in your app (the .each call is only needed if you select multiple devices... "multiple: true"... otherwise you can use the single device command like @bertabcd1234 posted above):
In my use case, I have a child device the app creates that does various stuff and allows me to put that info on a tile on a dashboard.. but when the device needs to send a notification, it will call its parent function:
Child devices can only be created by an app or another device (i.e., you can't take over an existing device as a child, nor can one device or app be a direct child of more than one app/device). However, I'm still not sure that's what you want. If your goal is to send the user (or yourself) a notification when your own device becomes a certain state, then I'd say you have two options:
Leave it to the user to configure an app that that does what they want since there is apparently already a device that can be monitored for this purpose--e.g. create a rule triggered by a state change for that switch, with actions that send a notification under your desired conditions. The disadvantage here is that it requires additional setup on the part of the user, but it's arbitrarily flexible. Since this is already possible at the platform level, your app/driver doesn't need to do anything here; or
Allow the user to select a notification device in your app, then use the user's selected device(s) to send the notification (see either of the snippets above). Your app would then have the logic to implement when this notification should happen (e.g., by subscribing to events from your switch device).
A child device must be created from the parent, otherwise it will not be associated as a parent/child relationship. If you make the child device "isComponent: true" the child device cannot be manually deleted, it can only be deleted using code in the parent device.
Here is a function I use to create children for one of my apps:
def createChildDevice(childName) {
log.debug "Running createChildDevice"
if(!getChildDevice(childName)) {
log.debug "In createChildDevice - Child device not found - Creating device: ${childName}"
def driverName = "Virtual Keypad"
def driverNameSpace = "mbarone" //only required if child device namespace is different from parent
try {
addChildDevice(driverNameSpace, driverName, childName, 1234, ["name": "${childName}", isComponent: false])
log.debug "In createChildDevice - Child device has been created! (${childName})"
} catch (e) {
log.debug "App unable to create child device - ${e}"
}
} else {
log.debug "Device (${childName}) already exists."
}
}
I would take a look at several apps that do similar things you want and take a look at their code to help you out... this is how I started with my Hubitat apps/drivers.
Alternatively, you could just create the driver, which performs as you need and use Rule Machine to monitor the value and send notifications for your specific scenarios. Really depends on your skills and how much time you want to spend developing this for your use case.
thanks.
I know I'm asking for too much but can you give me a simple app code which would just create a child device given a "ip address" and a "name" as parameter ?
I don't need the app to hold record of created child devices. just take 2 parameters from user and create a child device.
I don't understand the difference of these 2.
what happens when I allow the user to select a notification device in my app ?
who will tell the notification device what message to be sent ?
btw, since I am not interested in writing an app, this option is not an option for me. I am just writing a device. because I need it to be a "device"
Blockquote
I don't need the app to hold record of created child devices. just take 2 parameters from user and create a child device.
When you create a child device from an app or another device, the parent will technically hold the record for this child device making them connected/not able to separate. That is kind of the point of using the parent/child app or driver method that these are now tied together for additional/more complex functionality and organization.
I would create the child device (with the name given) from the parent app.. then inside the child device, you can set the ip. This is how i handle a few parent/child drivers i have written. You can also send specific/custom settings from the app to the child device, but this takes more steps and more code in the app and driver to make it work.
Blockquote
btw, since I am not interested in writing an app, this option is not an option for me. I am just writing a device. because I need it to be a "device"
If this is the direction you want (at least for now), I would just write the driver that you need to fulfill your "device" requirements (which seems like you are mostly there) and use Rule Machine to monitor your custom device attributes/states and manage your notifications based on logic in RM or using another notifications app.
take a look at this code. in order to get around that issue. i made a notification device HANDLER that you can parse strings and therefore pass it messages in various strings..
via notifications
I don'T want to use RM or other app for notification purpose. Because I will create several of these virtual devices and I don't want to create several RM rules for them. Besides, with 1 rule , I won't be able to handle all of my notification needs per device. I will need at least 3 rules per device.
Considering I will have around 7-8 of these virtual devices, it means creating over 20 rules.
Why not handle the notification within my device ?
I really don't understand why sending notification is a taboo for Hubitat users/developers.
why am I being pushed to use a separate rule machine or notification app where I could just handle it with a line in my device driver ?
I'm sorry if this sounds too harsh for you but that's what I felt.
for now I can see the most simple approach for my need is to create a simple app that would create child devices.
if you can supply me a very basic app code which would just create children when I enter name, that would be great.
you send it a notification (as it is a standard notification device handler). that is the crux of it.. the communiction method is notifications then you parse them and do whatever you like.
you put a selection for a notification device in your device.. as an input, pick the other notification handler and then pass it whatever you like in a message.
You don't need to use Rule Machine; I was just suggesting that as a built-in option you can use to send notifications based on a device it sounds like you already (nearly?) have a driver for.
If you want to send a notification to the Hubitat mobile app device, however, you will need to get an app involved. Rule Machine is just one option. If you're building a custom app, you can include this feature there instead. You need a device reference, as in the input example above, and can call the deviceNotify() command on it. You cannot send a notification to the Hubitat mobile app from your custom driver, at least not directly.
No worries.. this can be complicated, and some things should be easier to do then how we actually need to do them, but this is the case with many things we interact with daily.
The issue is that a driver (device) cannot send notifications to other devices. Your phone (if you have the hubitat app installed on it) that you get push notifications on, is another device in Hubitat. So your custom device driver, cannot send a notification to your phone device for it to get the push notification.
That is why we recommended looking at either using an existing app, or writing a custom app which creates child devices. You say 7-8 devices are needed, which could all be children of the single app. Then when any child device needs to send the notification, it will send the notification through the parent app (see example in my earlier post), which can communicate with any device on your system, provided you gave the app access to the notification device similar to my input example earlier in this thread.
I think you will still need an app of some kind (Rule Machine or HSM) to communicate with @kahn-hubitat driver above.
ok. I will do that. That's why I asked you if you could provide a very basic app code which would just get one or 2 parameters from user and create a child device based on these.
You already supplied me a code to create child devices. But I don't know how to write a very basic app to get 1-2 parameters and call your "createChildDevice" routine with these.
I'd appreciate if you could tell me that part as well.
I know I have to read more and learn before trying to write my device, but I'm just in a hurry to achieve this. That's why I didn't have time to read and learn.
I dont have any personal code that would easily translate to this, so while trying to keep this less complicated than it needs to be I wont directly link any of my projects. All of my projects started out similar to yours.. I wanted to do something and nothing available would fulfill that specific need. I loaded a bunch of other people's apps and drivers to see how they did things and just started adding to my basic code until it did what I wanted.
This thread is a good primer on the use of Parent/Child code and why/when it is good to use:
They link to the Hubitat github with some examples in the above link, but this app example below should give you the basic structure and allow you to get started:
This should give you a good start, basically start with the averageTemp.groovy and rename it to be your new custom app. Load it in hubitat and go to the app page. Now when you make changes to the code, refresh the app page to see what you did and how it functions. Start to integrate the example code posted above in this thread and post questions when you get stuck.
The notification part is easy once you start playing around with the app code and add the example above. The multiple child devices and settings will take a little bit of playing around to get working. Again, depends on how much programming experience you have along with how much time and motivation you have to work through problems as they arise.
thanks. I finally managed to write a simple app as parent of my devices.
and notification works.
I also made the app set IP and Mac address parameters of the child device.
Now everything is easy and smooth.
Besides, I am not running a separate notification app on the hub, which is good.
The Capability List docs show the command names (and the capability names you can use to select for devices that implement them), if you haven't seen this already.
