Why can't Rules be saved copied and shared like cooking recipes

4 Likes

And, no drivers!!

7 Likes

My brain short circuit

1 Like

I just discovered that I can export rules but there seems to be a problem with the JSON (according to Visual Studio Code

Manually corrected to

There should only be a single \ in the JSON. As it is written the inner quotes are not escaped. As an aside, it is supposed to be an array why make it a string. As in

image

More as I learn. My goal is to be able to create and edit rules use external tool and import them. Even better if I can use the MakerAPI to import them. At this point I'm just begging to understand how it works.

It's not our intent that these be editable, nor to provide a means to create rules through creating a JSON file. Your editor is misleading you. So the comments about the JSON formatting are not really right. If you want whatever rule that came from to work, it would of necessity be formatted that way.

I'm afraid that it would take a great deal of effort to reverse engineer RM this way, and there would be no reason to think that its internals might not change at any time.

Looking at the title of this topic, we undertook to provide a means to save, clone and restore rules, but not the 'cooking recipe' part.

3 Likes

I can accept the no-manipulating, but it's still useful to be able to look at it. I appreciate the use of JSON and would like to see it for all backups. I'm not sure what you mean by "editor is misleading you" since JSON is well-defined (even if overly strict).

That said, I would like to be able to edit and load a text version of the rules since having to enter and update the rules manually doesn't scale.

I'm guessing the JSON goes through a previous interpretation step prior to loading it as JSON, which would require the backslashes to be backslashed, otherwise they would get removed. As such, the JSON output is not true JSON, it's an escaped version that will result in a JSON once processed.

In other words, you would have to figure out/reverse engineer how that all works to create a proper file, usable by HE. As @bravenel said, probably not a good use of time, especially considering they may change it anyway.

I understand how it happens. I can work around it but if I simply want to look at it in, say, VSC, then the lack of escaping is one more annoyance.

(Speaking of which, where do I find documentation on what the URL encode setting does?)

My larger issue is that if I have 10 Hue switches with 4 buttons and each with 4 states I get into a challenge in making the settings. This is why I want to be able to build tools to edit the scripts rather than going through the menus again and again, and then repeating it for a change.

If there is a way, please tell me.

It seems you’re going pretty far down a rabbit hole in an effort to do something that may not even work?

2 Likes

There is not, other than just writing your own groovy app - which seems like it would fit your needs much better actually.

If your comfortable enough to use VSC/code then just make your own apps...

3 Likes

If there were better debugging tools and documentation for Groovy I would do it. But the more I can leverage what there is the better.

This is why I really want JavaScript/TypeScript support but I don't see that happening.

Another possibility is using the Maker API but, again, more moving parts.

There are perfectly adequate debugging tools and documentation for Groovy. All of the built-in apps and drivers, and all of the community apps and drivers have been implemented on hubs. Debugging is done with log.debug in the code as needed, to come out later...

For documentation on Groovy, Google is an excellent resource -- I use it all the time if I need to know/remember something I don't know. Online documentation for Groovy is extensive and on point.

It's not hard to write a special purpose app that implements some chosen subset of RM. It's also possible to use RM for actions, with custom app to cause them to happen through the documented RM API.

There are example apps in our public GitHub repo, that show the basic framework for an app on the hub.

1 Like

Maker api doesn't help you with what you are trying to do with either though.

1 Like

Unless he wants to go down the Node Red rabbit hole. :grin:

1 Like

No worries, just trying to present another option that may \give you what you want now.

I guess my point is that if you can do js, you can do groovy. :man_shrugging: The debugging tools if there were js on the hub wouldn't be any different/better than the groovy debugging tools on the hub. And if you do the coding externally, there are groovy add-ins for VSC among other editors for syntax checking anyway.

Regardless, I hope you find a solution that works for you!

I recognize that I need to work with Hubitat as is and am trying to find the highest leverage path.

I understand debugging with print statements. I did that a lot when I wrote my equivalent to the Maker API for SmartThings. Having Maker was key to my switching to Hubitat.

But .. hmm ... ah-ha .. pressing a button does generate a device event to the Maker API. At least a push does -- I don't seem to get a long hold message. But now I can indeed program my own responder.

Thanks for encouraging me to think more about this.

I still think better rule utilities would be useful but the path of least resistance is to listen for such messages.

I looked at Node Red and others and learning their worlds is much harder than writing my code from scratch using base APIs. I just need to revisit some design decisions I made 25 years ago.

Node-red is going to be 50x faster than what I read into your plans.

You can copy and share like cooking recipes. The export is JSON.

As long as you have an always on computer that can run NodeJS, you can have Node-Red turning on lights for you in under an hour. If you have an available Raspberry PI, there's an image built specifically for "us" to speed you to success very quickly.

If you want to pursue it, there's lots of help here.

3 Likes

Ah, I see what you mean now. Sure, every event in hubitat is exposed by maker api. If you want to write something external to interface with those events from maker api, and do stuff - of course you can. If it makes an event in the device details page of the device, it will get sent out via Maker API. If it logs something, but does not make an event (deduplication reasons, or other) it will not get sent out via maker api.

That's how the Home Assistant, Node-RED, and many other external integrations work.

1 Like