Can you consider adding support for stringify. Its basically IFTT but a lot more advanced.
Good to keep asking. You will find though that you can essentially do similar tasks with Rule Machine, it just takes some time to get your head around the workflow, same as Stringify. If you're trying to reach an incompatible device through Stringify, you can go in and out of Stringify with IFTTT. So in a roundabout way, it makes Hubitat compatible with Stringify.
I'm less enthused with Stringify since the Comcast purchase. They used to be really fast, but I've noticed the service has slowed significantly now. Plus the integrations I'd hoped for may never come now that they're part of a large company that isn't agile. Some of the innovations and feature requests I made in the past used to be answered in mere minutes and fulfilled in less than an hour. Now the contact I had doesn't even return my email at all.
What kind of integrations were you hoping for?
The integrations that IFTTT supports, without having to pass from Stringify to IFTTT. I have iSmart Alarm, and at the time, I would have loved to be able to control my alarm system with Stringify instead of IFTTT, since many of the triggers and actions for iSmart Alarm in particular are so slow as to be unusable.
Again, this was before Hubitat. I've figured out or just been able to access different ways of getting what I need with Hubitat for most things, so the desire is much less. However, RM and webCoRE are intimidating to some people, but Stringify is not. So it could help grow the user base if the word spreads that Stringify is another option for automation. It seems backwards I know. Buying a hub that focuses on local and then running automations in the cloud, but that's what thousands of ST users are still doing to this day.
When I was using Stringify regularly, I found their service to be very fast and extremely reliable. I have no idea if it's still any good. Last time I tried something I was shocked at how slow it was compared with their pre-Comcast days.
I was super excited about Stringify when they started and I built some cool stuff with it. My interest has faded because most of what I want to do can be done in a more efficient way with either Rule Machine or WebCore. With that said, I still think Hubitat should work with them to enable support just because there is SmartThings support. If users are mostly coming from prior ST users then it would be wise to not force them to take a step backwards.
1 Like
Very much agree. Their ST support is very good and you can really build some complex flows. That would be a nice transition for new users, but I also agree that RM is a better way to go for supported devices. Still having RM for supported devices and Stringify for unsupported would be and incredible combination.
Agree. I was using Stringify for ST and Wink 2 and it was very reliable and fast. I still have tons of Zigbee devices on Wink and don't really know what to do yet. Unfortunately they are Quirky product lines and they don't stay connected with ST or Hubitat.
I just started a collaboration with a friend who is a long time Wink user to create a Wink binding for HousePanel so with luck that will be available someday.
2 Likes
I just figured out how to trigger a Stringify flow from HousePanel linked to either Hubitat or ST. To do this first create a flow with the Maker tile. Something like this:
Copy the REST endpoint the maker tile creates. Next use the new custom tile and place it on a page. Add a line in your hmoptions.cfg file that references your new endpoint to define what happens when you press the custom tile. It should look like:
“post_custom_1”:[[”POST”,”url”,””]],
The url is the post string from maker. Notice the need for two square brackets. This is because each custom tile can have multiple arrays. So if you want to trigger two makers you would do:
“post_custom_1”:[[”POST”,”url”,””],
[“POST”,”url2”,””]],
There are 8 custom tiles. So use post_custom_x for custome tile x where x is 1 through 8.
1 Like
Very cool. Just as a side note about Stringify. Although your flow obviously works and doesn't give an error when you try to save it, best practice is to minimize the complexity of the flows by dragging both the action "Things" to the quicklink of the "When" Thing.
This becomes important when you have both "When" and "Only IF" things, and you want the relationship between them to deliver an action. In that case, trying to create a second "relationship" will result in error as explained here.
@SmartHomePrimer you can achieve similar flows with the SharpTools.io Rule Engine as well.
I'm working on building a 'Rule Tile' which should be included in an upcoming release and would let you trigger rules from the dashboard as well (assuming this is why the HTTP triggers were involved in @kewashi's post)
That being said, Stringify has a number of solid platform connections. I don't recall seeing iSmartAlarm on their Things list, but recall you mentioning them in an earlier post.
Just played with SharpTools Rule Engine to a very limited extent so far. For sure I see the power in it. Does seem more like building a flow in RM, than Stringify though.
@kawashi was posting about a method to trigger a Stringify flow via http Post (by way of HousePanel). Previously the only fully integrated method to trigger a Stringify flow from Hubitat would have been via IFTTT to Stringify.
For SharpTools, the direct integration with Hubitat of course enables SharpTools Rule Engine to be triggered, so such a method via HTTP post is unnecessary. However, to my understanding, SharpTools can only act upon devices that are available to Hubitat, therefor it is more like RM than Stringify, which supports many devices that are not supported by Hubitat at this stage. Several of the devices that are supported by Stringify are indeed also supported by IFTTT which of course has its Hubitat integration, but building complex flows with IFTTT is very difficult in comparison.
iSmartAlarm was mentioned merely as a reference to the faster speed of Stringify vs IFTTT, but no, Stringify never did add that capability as I had requested, so IFTTT is still the only method I have to control it, except for voice control via an Alexa skill (which is very fast vs IFTTT as a side note). However, now that IFTTT directly integrates with Hubitat, and thanks to the speed of local processing, the response time between IFTTT and iSmartAlarm is usually much faster than when I was trying to control if via ST or Wink.
Thanks for taking the time to try it out and provide some feedback!
Can you clarify what you mean here? Our goal is to refine the SharpTools Rule Engine to be an easy to use visual rule builder that provides the option of powerful features for advanced usage.
For example, in Device Actions, you can use basic commands like on and off... but you can also access every command the device exposes. For example, my Kodi media player driver allows pushing notifications to the TV, starting activities, and opening add-ons.
Yes, it can act on any SharpTools.io connected platform. We have SmartThings, Hubitat, Pushbullet, SMS, and Email... and the goal is to continue to expand support for more connected platforms (eg. Wink, Hue, etc).
Stringify definitely has a decent number of connected platforms and is a great platform. Much respect to those guys. And IFTTT has a ton of connected platforms, but I couldn't recommend it for most home automation considering how delayed/slow it can be as you have very well noted.
@josh does this mean that we can access custom commands for devices? If so, I might bump up my SharpTools playtime to a higher priority.
1 Like
Yes. As long as the custom command is properly defined in the metadata section of the driver, you can access it with SharpTools.
metadata {
definition(name: "My Awesome Device", namespace: "joshualyon", author: "Josh Lyon"){
capability "Switch"
command "myAwesomeCommand", [ "string" ] //accepts a string input
attribute "myCustomAttribute", "string" //reports itself as a string attribute
attribute "myCustomEnum", "enum", ["red", "green", "blue"] //reports itself as a enum set with a predefined list of options
}
}
2 Likes
Awesome news..I'm not a fan of how custom commands are used in Rule Machine...a bit clunky. I will give SharpTools a spin sometime soon.
Heck, even if the device doesn't properly define the command with the proper format (which includes the array of parameter types as shown above), you can use the 'Advanced' toggle to override the number and type of parameters.
3 Likes
So in terms of advanced features, this is really cool. When I made the comparison to Rule Machine, what I'm really referring to is the usability for basic tasks. I'm new to Rule Engine, so maybe I'm not using it correctly.
As an example, this is how I configured my first test rule. Very simple, switch turns on, a light goes on. Same switch turns off, the light goes off. This required 39 clicks to create this rule, not including the steps to add the device to SharpTools.io so it could use them.
The same rule in RM, required 24 clicks and of course executed much faster because there's no cloud connection.
Not criticizing, just trying to suggest that perhaps it could be made easier.
1 Like
Excellent feedback and I totally agree. And I'm sure @JamesLiu is chuckling as he's heard this a lot from me lately.
My vision is to default to a simpler interface and then allow power users to change to the current interface if they need more advanced features. So for a trigger, if you chose 'Device' it would present you with a list of devices on the left and as soon as you picked one, you would get a simpler list of conditions on the right.
For example:
+--------------------------------------+
| >Lamp | ...turns on |
| TV | ...turns off |
| Bulb | |
| Outlet | |
| | [Advanced] |
+--------------------------------------+
This would drop most users down from 7-8 clicks down to 2 to setup a device trigger!
That being said, some users may prefer the power and flexibility of being able to choose any attribute and any comparison, so I would want to keep that advanced functionality there, but perhaps hidden behind an advanced toggle or link.
Funny you mention that. Since the SharpTools Rule Engine is written as a single-page app, you may have noticed that there were no page reloads, no post-backs, etc. So each time you change a selection, it's all being done in your browser without any need to talk to the cloud at all. So changing selections should actually be much faster except for the fact that you had to click so many times!
Perhaps put a different way, once the Rule Editor page is loaded, all of the data is already loaded for all the devices, modes, HSM, etc. (One exception to this is the Pushbullet action which queries for your list of devices when you create/edit a Pushbullet notification action)
1 Like
My apologies. I was referring to the actual execution of the rule. SharpTools Rule Engine requires between 3 to 4.5 seconds longer than RM to turn on the same light. Not laying blame, it's cloud and delays are to be expected, but perhaps there is some backend optimization that could help shorten this time.
1 Like
