Single quotes are not valid JSON, thus I can't use them. If I used them, the API endpoint wouldn't be able to decode the JSON payload,
Also, on the Hubitat side it doesn't change anything. The characters are still vanishing.
Ok my memory was a bit vague. It may have been C, or was that for single characters? Lol I am a JSON ignoramus.
The built-in %device% variable evaluates to the device that Triggered the rule, if one exists. Thus, if a rule was triggered by date/time, or by another rule, then %device% would be Null.
2 Likes
The device triggers the rule. It's a contact sensor and triggers when Contact reports *changed*
I've run a few more tests, unfortunately to no avail:
The UI interface accepts "from": "Hubitat < notifications@hubitat.local >" (see the space between the < and the text). However, it still mangles it up, especially because it's mangled inconsistently. It seems that the < is html encoded, but the > is not. This is what Hubitat sends:
Hubitat < notifications@hubitat.local >
So we have 2 bugs here:
- Hubitat filters everything that might look like a HTML tag. e.g.:
<my@email.com> - Hubitat encodes RAW data (and inconsistently at that). A POST payload must never be encoded.
For the %device% substitution issue I still do not have an explanation. Is there a way to open a bug report or are developers reading the forum?
Update: I want to clarify my statement that a POST payload must never be encoded. I was referring to RAW data (custom) and content type application/json.
For the type of issues you’ve mentioned, I believe @bravenel from Hubitat would be the correct resource to assist.
In general, Bruce is going to want you to post screenshots of your Rule, along with screenshots of the Live Logs (make sure you enable logging in your rule, trigger the rule, and then capture the logs to post here.)
2 Likes
I tried entering "a@b.com" as a variable's initial value, no go, the data gets blanked out. Now if I create the variable with "x" as the initial value and then set the value to "a@b.com" in a rule action the input is accepted unaltered. I didn't try making an HTTP POST with it, but maybe give that a shot as possible workaround.
No idea if this is a bug or intended behavior.
ETA the emails have the < (and ending) but the forum software stripped them.
The hub UI for text input removes anything resembling html, and evidently the text you are entering for the post body has these characteristics. This is done for security reasons, to prevent certain types of attacks enabled by embedded scripts in inputs.
2 Likes
Thanks for your reply. But unfortunately this also means, one cannot send RAW or JSON data to a webhook. This is something that should be mentioned in the UI.
Btw, another field is missing. Usually one has to send an API token via a header to use an API endpoint or webhook. Currently this is not possible either.
I think a checkbox (in the HTTP Post page) with a warning to turn off that security "feature" would make sense. Also, you can filter <script> tags, but filtering random text between < and > seems excessive, which leads to exactly the problem I am experiencing.
I will prepare screenshots and the log output for the %device% issue. But I am not sure when I'll get to it.
It's the hub that is being protected from the user. We don't want the OS and hub platform put under attack. No user would ever do anything hostile like that, right?
Could well be. The alternative is a much more sophisticated filter method, something that we wouldn't put much priority on. You're reaching the limit of what RM can be used for.
You might be able to do it with an intermediary that takes a hubitat friendly string and changes it into your final JSON string. I have to use an intermediary linux box to take email attempts from my reolink cameras and change them into hubitat endpoints 
I only want to send an email notification. This is not a crazy feature for an automation system. But there's nothing in Hubitat that lets me send emails, except a user app that uses telnet and no secuity at all (which means I can't use a proper mail server with TLS on port 465).
But why are the angle brackets encoded inconsistently? Either way, my point was that you can't say you allow a json POST body, when you take the input and generate garbage. I mean garbage, because it's not what the receiving end would expect. This means that people have to debug what Hubitat sends and have to code API endpoints specifically for Hubitat. (Which I have done now, btw.)
Yep, there are a bunch of possibilities to fix this. One of them is to write specific endpoints just for Hubitat that won't work anywhere else. The maintenance overhead for this is siginificant.
While I seem to be critizing a lot, I love Hubitat and I am glad that it exists.
1 Like
I understand your frustration. But, there are three separate topics embedded in the points you are making.
- Hubitat Elevation lacks a means to send email.
- Rule Machine's POST functionality leaves things to be desired.
- The hub's UI trashes certain input text values.
Yes, we know that some users want a native email capability in the hub. This hasn't risen high enough in our priorities to get attention from our development team yet. I can't say when that might happen, but we are very aware of it.
There are limits to what RM can do with POST. Extending this functionality has also been low priority for us. For someone like you, with high expectations, it falls short. Again, I can't say when this might get some attention. For what it's worth, we have an expectation that someone with your sophistication can/will use Groovy to write custom solutions where RM falls short. Clearly, this isn't for everyone, but most people with coding experience can use Groovy to do things like this.
The only people impacted by our UI filtering of text input are people like you who fall into the same set of technically sophisticated users just described, and who aren't interested in using Groovy. We have to prioritize what we work on, and this is a very small set of customers.
I don't expect you to like these answers, but this is where things stand.
1 Like
I am not really frustrated, because I found a workaround that works. It involves more maintenance than I had anticipated, but that's ok.
I would love to write a plugin for RM (a POST handler) or an app (sending emails) , but there are 2 things I despise with a passion: XML and Java.
Well, and non-ISO 8601 date/time formats, so make that three. 
If it had been any other language (e.g. C, python, Go, or php), I'd have already started coding.
Have you seen this integration?
1 Like
I hadn't been employed as a software person for over 25 years when I first encountered Groovy in SmartThings. Groovy is not hard to learn, and quite flexible. ALL of the built-in apps and drivers are implemented in Groovy, including RM. As for its resemblance to Java, meh. It's a tool... it works. You're just depriving yourself.
3 Likes
I was pondering the idea of adding email capabilities. And I imagined a deluge of email spam as I made a mistake in my rule and it was firing once a second
Nope, but how do I know that the payload is not mangled either? I have a workaround now and my endpoint works, even with the garbage (Hubitat < notifications@hubitat.local >) that is sent by Hubitat.
Hasn't mangled any of my payloads. YMMV.
2 Likes
See this [RELEASE] HTTP Notifications Driver for groovy HTTP code, might be easily enough modified for your purposes.
