Spice up 🔥 your sitemap with unicode symbols 💪🐱

okay buddy

Hello!

Could you please tell me how you’ve integrated weather forecast in api.ai? I was using their Weather Domain, but it stopped working (it was working in the chat bot, but it also worked using their Python API call). All other domains (both free and paid) are still working using Python API. Is there an easy way to query Weather info, or I should create Regular Intents?

Best regards,
Davor

Hi Davor, no Problem i can help you!

  1. Go to this Site an klick @deploy to heroku, then give a app name an klick an "deploy"
    https://github.com/api-ai/apiai-weather-webhook-sample

  2. “Your app was successfully deployed.” klick on “Manage App”, than scroll down to “
    Domain”, copy the domain Link!

  3. Go to your api.ai Plattform, go to “Fulfillment” an enable the “webhook”. Now insert the heroku Domain Linkinto the URL and klick on save!

  4. Go now to your Weather “Intents” an insert under Action: yahooWeatherForecast

  5. Active the webhook under Fulfillment in this Intent!

now it should work :smiley:
sry, my english is not so good ^^
maverick

Hello!

Thank you for the explanation.

Best regards,
Davor

@Oli
can you help me`?

habe gerade deine Übersetzung gefunden, finde ich super! :blush:

Ich spiele gerade mit api.ai Plattform und yahooWeatherForecast herum.
Habe dazu wie in einem Tutorial beschrieben ein webhook über heroku erstellt.
Die Antworten funktionieren, nur sind die eben alle auf English, deine Übersetzung wäre die Lösung!
Wie binde ich das ganze ein, kannst du mir helfen?

Dankeschön!
maverick

Hallo @maverick,

you’ll need to copy the text over into a map file and use the map transformation while defining your sitemap. Please have a look at the very similar Astro example here:

@ThomDietrich

I think you misunderstood me, I wanted to know how I did the api yahooWeatherForecast(from github) to adjust with the german translation.
Or am just wrong here ;D

Looks like others have already chipped in :slight_smile:
Uh…webhook? heroku? I only know Captain Hook and maybe i can write a haiku :wink:
Sorry, clueless…but of course feel free to use the data as is if it helps.
HTH,
Peace out,
-OLI

1 Like

Sorry to revive this old thread but i think there is something wrong with the moon symbols and how they eventually get transferred to the generated web page with for example basicui

i followed the astro example and most of the unicode symbols works just fine except the moon symbols (i use chrome on windows)
each moon symbol just ends up as two diamond shaped symbols just like the picture in this thread: Astro Items+Sitemap+Map+♈ Binding Example

but i did an experiment, in chrome i did an inspect and edited the html and replaced the bad moon symbols with the symbols i copied from the astro.map file.
result was working moon symbols in page.

obviously this wont stick and was just a test if browser can display them or not and it can.
so i suspect that some of the unicode symbols gets mangled when page is generated.
maybe a bug in openhab 2.2?

there is definitely something odd going on with the moon symbols.
leaving page (basic ui) as is until it updates makes the unicode symbols work but reloading page breaks it.

is there any browser specific checks that makes unicode symbols handled differently depending on browser?

1 Like

can someone point me in the right direction where to report this as a bug?

i have again confirmed that unicode symbols that get auto updated AFTER apage loads, for example due to changes works but not initial symbols on page refresh.

so there must be a bug.

I noticed the same behavior, but not only for the moon symbols. It seems to apply to several unicode symbols, and also I noticed the behavior for both Chrome (Win64 and Android) and Edge (Win64). Interestingly, in the OpenHAB app the unicode symbols are correctly displayed right away, also if I copy-paste the symbols the pasted symbols are initially displayed using the &#…; notation and, after initiating a search on this string, as correct unicode symbols (tested in Chrome (Win64).

When I inspect the OpenHAB basicui page then I find that initially the symbols are only displayed as diamonds with question marks, yet after a data update they are replaced by, for example,

<span class="emojione-emoji" style="display: inline-block; line-height: normal; font-size: inherit; vertical-align: middle; position: relative; width: 1.1em; height: 1.1em; z-index: 100;"><svg style="padding: 0; margin: 0; width:100%; height:100%;" viewBox="0 0 64 64"><use xlink:href="#e1-1f3e0"></use></svg></span>︎

Here I note that I used the instructions here to complete the unicode character set in Chrome (yet this did not have an effect on the initial display of the symbols, I still have the same behavior of unicode symbols only being shown after a data update).

So it indeed seems that browsers do only interpret the unicode symbols after a data update took place. Any suggestions on how this could be fixed would be much appreciated.

i would not be surprised if there is some clever code in the web server trying to figure out what browser it is and then adjust unicode characters accordingly or something similar.
probably based on the user-agent string.

would be interesting to see if behavior changes if you fake the user agent with something else.
since browser clearly can display the unicode symbols propperly the fault must lie with openhab and its web server.

Ok, for seeing how different browsers behave I now also tested under Edge (Win64). Same as with Chrome, the Unicode symbols are first not shown (double diamond with question mark per symbol). Yet after an update of one of the items in a particular view, all of the Unicode symbols are shown in Edge. Interestingly, this does not happen with Chrome, here only the item that was updated shows the correct Unicode symbols.

Any specific suggestions for user-agent strings to test with Chrome and/or Edge to see if the behavior changes?

1 Like

Has anyone managed to solve the moon symbol issue in Basic UI. I still only see diamonds and questionmarks

Any update on a fix for this issue? It seems that in OH2.5 M1 the issue is still not fixed.

It would really be great if this could be fixed. Any news?

This problem really bugs me and I investigated further, and here are some more insights on the issue. Unicode characters work, theoretically. Any unicode character below U+FFFF will work out of the box such as :watch: which is U+231A. However, anything beyond U+FFFF is not supported out of the box since Java can only encode things up to “\uffff”. For example, :new_moon: which is U+1F311 does not work. This means that characters beyond U+FFFF are encoded as UTF-16 using two characters, called surrogate pairs. So :new_moon: would be split into the two characters U+D83C and U+DF11. You can see this if you open the “source” version of a page which contains the correct UTF-16 characters. And while browsers normally can deal with this issue just fine (you can copy the surrogate pair characters and search for them), something prevents (some script?) at least current versions of Chrome and Edge from correctly parsing the UTF-16 surrogate pair. Upon the update of a field a different mechanism seems to kick in such that either the characters are somehow sent as UTF-8 or whatever prevented the surrogate pairs to be interpreted correctly is now no longer active. Does anyone have an idea of how to address this issue? Maybe @ThomDietrich?

1 Like

Does it matter in which encoding the files are saved, when I want to use unicode characters for my sitemaps and items?

Yes, they must be utf, I assume utf-8, but might be utf-16

1 Like