Todd, what are your thoughts on making your lantrigger device a device with 50 momentary switches akin to your web requester device? Instead of spawning 50 devices you could have a single device that listens for 50 unique triggers coming from a single source and the post request instead of being …/trigger would be …/triggerN.
Also, you haven’t really publicized your rpi-st-device on here. Does that device allow you to read the state of devices from the RPi? I’m trying to detect the humidity in my bathroom for a routine that can’t be encoded in SmartThings. Right now I can imagine passing this information to my RPi with a series of routines that send the humidity via your web requester device; unfortunately I can’t pass dynamic variables with SmartThings routines, so I’ll have to have one routine for 52% humidity, one for 53%, etc.
It is definitely possible to do. But one thing to consider: just like there are SmartThings limits to the number of drivers and devices, there are also limits to the number of routines. In fact, it’s funny you bring this up because I’ve already had requests regarding webrequestor to have dedicated devices due to hitting the automation routine limit. So it’s kind of like you can’t win either way . I’ll consider creating a ‘LAN Trigger Multi’ driver to do this, but it may be a couple weeks before I can get to it.
This package allows you to create device applications on your Pi that interface with SmartThings in a very different way - directly through their cloud server, instead of locally to an Edge driver. See the SmartThings description for this schema here.
Regarding your bathroom humidity project, so I am clear, do you already have a SmartThings-integrated device that is getting your humidity levels? And you want to pass them over to an app running on your Pi and do something with them? Then what does the Pi do with that data? Does it have to send something BACK to SmartThings or is it only a consumer of the data?
I have gotten a request to create a series of ‘virtual’ devices that can be configured to send http requests (similar to what I’ve done for MQTT). It sounds like you might find value in that, if it included a humidity device. An alternative is MQTT, which it really sounds like you should consider if you have various projects where you want to be sending data back and forth between an app on your Pi and SmartThings. I have a couple different MQTT solutions that could help you do this. It’s very simple to have a MQTT broker like Mosquitto running on your Pi that can provide this capability.
Otherwise, I think the problem you are pointing out with having to create separate routines for specific values, in conjunction with webrequestor, is a messy one indeed.
Todd, thanks as always for your amazing work and continued support. I think MQTT will indeed be the way I go.
I currently have a combo temperature and humidity sensor in my bathroom near my shower head. I’m trying to detect when the shower turns on by detecting a rate of humidity increase, and not rely on absolute numbers as the baseline humidity fluctuates throughout the year. I envision a rule that detects when the humidity has risen by greater than or equal to 5% relative humidity in the span on 10 minutes or less.
I guess a custom SmartApp could take care of this, but I’m not familiar with programming those and would much rather write something in Python running on my RPi4.
I envision utilizing your Web Req Multi Master device to trigger (every time the humidity changes) a script running on the Pi that grabs the humidity from the appropriate sensor and time stamps it. Then it looks back and identifies what the humidity was 10 minutes ago, and if it’s increased enough would then trigger the appropriate bathroom fan on, which I can do with your LAN Device Trigger, although I could probably also do it via MQTT.
Todd, are your vEdge and webrequestor drivers open source? I’m trying to write a driver for the Hunter Douglas PowerView generation 1 & 2 shades, and it’d be much easier to write it if I could borrow chunks of code rather than learn Lua from scratch. Thanks!
@TAustin I’m successfully using the Edgebridge, with LanMotion and wondered if you would consider creating a ‘LanContactSensor’ driver. I read you implemented the contact sensor capability in Shelly Motion but it was removed… I have tried myself by taking LanMotion and converting it to a contact sensor and everything works but I cannot get ‘open’/‘close’ to present in the dashboard, it just states ‘Connected’, I think its something to do with the metadata (vid) being the same as LanMotion, I’m happy to learn but I’m not a developer and think I’m not far off my technical limit. I see (and appreciate) you’ve got lots going on and I only ask as I think this would be a fairly quick thing (for you) to do.
It works just like the others: once you’ve enrolled in my channel, you choose to install LAN Contact Device Driver V1 from the list of available drivers. Once it is installed on your hub, the next time you do an Add device / Scan for nearby devices, you will get a new device created in your No room assigned room called LAN Contact Device.
This driver requires that you have edgebridge installed and running on a computer on your LAN.
Go into device Settings and configure the unique name, device/app address (IP:port), and edgebridge address (IP:port). It will register with your edgebridge server and then you can start sending it http requests from any device or app:
POST http://<edgebridge IP:port>/<unique name>/contact/[open | closed]
Hi there. I’ve got a lantrigger driver that supports multiple triggers - up to 19, which is the maximum number of components I can define within a device (+1 for main). So now you can have a single device to handle multiple LAN triggers through edgebridge. You can also create additional devices, each with another 19 triggers.
I’ll put the driver on my test channel for now until you can try it out and make sure it meets your needs. Look for the driver named LAN Trigger Multi V1.0. Once installed on your hub, do an Add device / Scan for nearby devices and you’ll get your first device created which you can configure in device Settings for each trigger name/address combination, plus the edgebridge address (at the end). On the device Controls screen, you’ll see a list of all name/address combos that have been registered with edgebridge.