App input text field loses control data

Attempting to create a TTS countdown using SSML, but when the text is saved from the Nyckelharpa Talker app's input field, all control data is stripped out and TTS speaks without breaks. Works as expected when entering the SSML text into the Fully Kiosk Brower Controller device's speak command data field.

  • Entered Text
    Alarm system is arming in 30 seconds, please exit the facility<break time="1s"/>25 seconds<break time="3200ms"/>20 seconds<break time="3200ms"/>15 seconds<break time="3200ms"/>10 seconds<break time="3200ms"/>5<break time="750ms"/>4<break time="750ms"/>3<break time="750ms"/>2<break time="750ms"/>1

  • Result
    Alarm system is arming in 30 seconds, please exit the facility25 seconds20 seconds15 seconds10 seconds54321

Hubitat strips any formatting out of input fields.

To get around this, with my SuperTile app, I used non html characters (similar to bbs code) in the input and ‘replaced’ it with the correct formatting code before sending it on.

E.g. {href} in place of < href>

Andy

2 Likes

Thank you Andy!

You are welcome! :slight_smile:

PHP is my primary language, and I'm unable to find any Groovy equivalent to PHP's
htmlentitiies and html_entity_decode

I suppose I could do java.net.URLEncoder.encode(text, "UTF-8") prior to saving the data

Any thoughts on this?

Example..

Input text you want is: /<25

But it won't work so you can input it as {25

This is inputted to a variable ‘textInput’

In a method you could use...

If(textInput.contains(“{“){ textInput = textInput.replace(“{“, “/<“)}

Don't want to create my own pseudo language, but may have to do that. It appears that HE converts unclosed < characters to &lt but not / or >

I'm aware it's the Html encoding </> characters that are creating the issue, and from my recollection working with Groovy in ST and HE I can't manipulate a setting's text data prior it to being saved.

I will likely go with your {data} solution.

It is "possible", just not very convenient or straight forward, it would require you to inject Javascript to intercept and encode before submitting. Not the prettiest of solutions.

Probably much better than Javascript!

That was the solution that worked {command/}. However, it was a bit convoluted. At first I put the code into my Nyckelharpa Talker module that was outputting to the Fully Kiosk Browser Controller, FKBC. For unknown reasons it spoke all the control commands. When I moved the code into my local version of FKBC, it worked.

The code used in FKBC speak
def wktext=text.replaceAll('[{]','<')
wktext=wktext.replaceAll('[}]','>')

The revised exit message in Nyckelharpa Talker
Alarm system is arming in 30 seconds, please exit the facility. {break time="1s"/} 25 seconds{break time="3200ms"/}20 seconds{break time="3200ms"/}15 seconds{break time="3200ms"/}10 seconds{break time="3200ms"/}5{break time="750ms"/}4{break time="750ms"/}3{break time="750ms"/}2{break time="750ms"/}1

On some devices the message may need to be enclosed in {speak}...{/speak} tags

1 Like

As long as it works, it is unfortunate the way they implemented the filter in input, I would much rather have received escaped characters I could choose to unescape. Hitting this issue at times as well, using a workaround similar to yours. Still not using Javascript, I did write a way to inject it conveniently, but it's too much of a "hack"... Best to do as you did and adapt to what can be done.

My preference would be to convert < and > to HTML entities &lt; and &gt; which would be simple to convert back and would generally appear normal.

I agree that is a major hack, but if you want to share how you did it, I would be interested in looking at the code.

Yes, same here, that would be a more standard way of doing it.

I don't have the Javascript injection for driver pages in a public repo yet, but it is the same as the CSS injection on line 1906 here (method getDriverCSSWrapper()). Which is referenced inside the metadata on line 107. So basically the same thing. It also work with the JS injection I use for Dashboards.

Line numbers may change since this is the development branch.

Not the most elegant solution but it works :slight_smile:

True enough, but long running exit delay messages have an unintended consequence :scream:

When the system is arming in exit delay status with a long running TTS, and is disarmed prior to completing the arming status, the exit delay TTS message continued playing after the system was disarmed.

The FKB does not have a command to stopTTS. It does have a stopSound, but stopSound does not terminate an active TTS. I informed FKB's Alexey and he quickly sent a FKB beta with a stopTextToSpeech command, that I successfully tested from Hubitat and SmartThings.

So, now on my system when a ! (exclamation point) is added at the beginning of a TTS message, the code in my test version of @gavincampbell 's FKBC issues stopSound and StopTextToSpeech commands prior to speaking the message allowing the "!System Disarmed" to immediately speak.

When the updated version of FKB is released, I will document all of this in the ST version of FKBC. A while back and with Gavin's permission, I ported FKBC to ST. I also run and test the ST version in HE, but it is a bit behind Gavin's HE version. For the record my HA system is now 100% on Hubitat.

Your JS injection code is way beyond my skill levels. Wow, amazing work!

Thank you, I wrote it in the hope someone can do something cool with it! On it's own it doesn't do anything which will excite anyone except a fellow developer :wink:

1 Like