Should this be a driver or an app?

Developers
#1

I was going to put this in Code Share, but that didn’t seem appropriate as it’s more of a help question.

Not sure if this should be a driver or app… guidance welcome. This has spawned from my playing with the tp-link ST stuff. I looked through the node.js backend and played with trying to get the DH to work as a driver and I had a thought, but I need some help.

Can someone help/provide this.

Should this be an app or a driver? I think driver but not sure.

Generic driver that can take configuration elements. Options such as on/off/poll/refresh actually fire a HTTP request to a defined URL in the driver or app.

I just want very basic on/off, input field, execute -> how to execute the command. I was advised that the send command to hub wasn’t performed in a driver. Since I don’t know how that should be done, I need some help.

#2

Feel free to take a look at my Wink Relay code. It uses an App for discovering the devices via SSDP and the real work is done in the Device Driver which interacts with the Wink Relay over HTTP.

https://community.hubitat.com/t/beta-wink-relay-lan-integration/272?source_topic_id=289

Patrick may have already mentioned in another thread, but in order to receive updates from LAN devices, you’ll need to make sure the DNI of the device is set properly (typically the MAC address in hex, no : separator).

You’ll see that my device driver uses the parse() method to receive events from the Wink Relay over HTTP (JSON) and then uses a separate httpGET() helper method I created for sending all of the commands.

Note that I really should have all the actions in PUT calls to better fit web standards, but I haven’t gone back in to update the embedded micro-webserver I developed on the Wink Relay to support that yet.

1 Like
#3

Thanks for the info. I see one limiting factor here, unless someone knows a work around. If the NID is the mac address and as such must be unique, then it’s not possible to have a middle man (raspberry pi) performing more than 1 function. That to me is a waste. Is there something else that can be used as the NID to get around this? As it won’t allow two devices with the same NID. (tried it) :slight_smile:

#4

Are you saying you want to have the Raspberry Pi as a middle man for multiple TP Links?

If so, set that up in the parent SmartApp and divvy out any work to the RPi as necessary and forward responses on to child devices as necessary (from the SmartApp)

#5

@josh, yes I want to do that, and I want to use the same raspberry pi for other things as well. Kinda a generic man-in-the-middle purpose instead of a pi for each app or driver. There’s a lot of things in ST that are all needing a remote host, thinking of a way to bring them together into a single remote host type solution. I may be over thinking this too as I’m still learning the whole app/driver relationships and capabilities.

#6

Right now Hubitat supports mac address, ip:port (as hex) or just ip (also as hex) as possible Device Network Ids.

We are working on a concept called third party hub that will allow you to send messages to the hub from any third party hub (ie your raspberry pi) and you can specify the device network id of the device you want the message to go to in the headers of the lan message you are sending. This would allow you to split out messages to any device you want. We have this functionality in the hub currently and are developing the ui configuration to be able to use it.

2 Likes
#7

The 3rd party hub is the idea I was working on as well.

Concepts

  • Network communication to control… well anything on the network
  • Off-load of work from primary hub
  • Extendable and can use more languages than just groovy
#8

You don’t find Groovy, to be well… groovy?

#9

Groovy is ok. Long time since I’ve done java stuff so I’m having to get used to it again. I just have some existing stuff in Python that I would like to run and other things like shell scripts that interface with things as well. Just having more options seems good.

#10

Are there any other restrictions on receiving notifications from LAN devices? For example, I’ve been working on a WeMo switch driver. The hub can see the switch, and I can turn it on and off using my driver. The switch supports a SUBSCRIBE command for subscribing to updates. I can issue that command, and I receive an success acknowledgement with a subscription ID. However, my device’s parse method is never receiving notifications from the switch.

def subscribe() {
	log.trace "Subscribing to address ${getHostAddress()}"
	log.trace "Callback to ${getCallBackAddress()}"

	new hubitat.device.HubAction("""SUBSCRIBE /upnp/event/basicevent1 HTTP/1.1
HOST: ${getHostAddress()}
CALLBACK: <http://${getCallBackAddress()}>
NT: upnp:event
TIMEOUT: Second-${60 * (parent.interval?:5)}


""", hubitat.device.Protocol.LAN)
}

I know the basic subscription process works because I setup a simple express server on my laptop and used that as the subscription callback address, and it received notifications from the WeMo switch.

My device’s deviceNetworkId is the MAC of the WeMo switch (all uppercase, no colons).

The switch is using the NOTIFY method (rather than PUT or POST), if that’s relevant.