HABot Walkthrough (2/n): Semantic Tagging & Item Resolving

walkthrough
Tags: #<Tag:0x00007f1e6b9c2a58>
(Yannick Schaus) #21

Yes, player items in lists are not implemented.

My guess is, it’s probably a matter of training data to be refined. The machine learning doesn’t consider a single-digit as a value because it hasn’t been trained to recognize them.

0 Likes

(Curlyel) #22

Got it :wink:

Is there a way to teach it? Sometimes the answer is asking for feedback if this was it what I wanted to get.
But in case of the unrecognized values I don’t get prompted for that feedback…

0 Likes

(Yannick Schaus) #23

That’s because it recognized your intent as “set-value” but didn’t get your actual value.
The “is this what you wanted?” and co. are answers to the “get-status” intent :slight_smile:

Without changing the code, no. It involves adding more training in https://github.com/openhab/org.openhab.ui.habot/blob/master/src/main/resources/train/de/set-value.txt then creating some more tests in https://github.com/openhab/org.openhab.ui.habot/blob/master/src/test/java/org/openhab/ui/habot/test/TrainerDeTest.java#L189, until it works!

So either @stritti (the de facto maintainer for German :laughing:) or myself will have to have a look.

0 Likes

(Curlyel) #24

So should I file a issue for that?
Here:

0 Likes

(Curlyel) #25

Sorry for bothering :wink:

Probably something else to consider for the NLP (at least for the German):
(notice synonym “draußen” for "Garden)

Group   gGarten     	"Garten"                <garden>            (All)    	["Garden"]      {synonyms="draußen"}

Number    KombisensorAS315N_SonneOstWert     "Helligkeit Ost [%.0f kLx]"     (gGarten,gIlluminance) ["Light"]  {channel="knx:device:bridge:sensor-15:sonneOstWert"}
Number    KombisensorAS315N_SonneSuedWert    "Helligkeit Süd [%.0f kLx]"     (gGarten,gIlluminance) ["Light"]    {channel="knx:device:bridge:sensor-15:sonneSuedWert"}
Number    KombisensorAS315N_SonneWestWert    "Helligkeit West [%.0f kLx]"    (gGarten,gIlluminance) ["Light"]    {channel="knx:device:bridge:sensor-15:sonneWestWert"}
Number    KombisensorAS315N_WindWert         "Windgeschwindigkeit [%.0f m/s]" (gGarten,gWind) ["Wind"]  {channel="knx:device:bridge:sensor-15:windWert"}
Number    KombisensorAS315N_DaemmerungWert   "Dämmerungswert [%.0f Lx]"      (gGarten,gIlluminance) ["Light"]    {channel="knx:device:bridge:sensor-15:daemmerungWert"}
Number    KombisensorAS315N_TempWert         "Temperatur [%.2f °C]"          (gGarten,gTemp) ["Temperature"]   {channel="knx:device:bridge:sensor-15:tempWert"}
Switch    KombisensorAS315N_Regen            "Regenmeldung [%s]"             (gGarten) ["Status"]  {channel="knx:device:bridge:sensor-15:regen"}

Number    ZigbeePhilipsSML001TI03_Illuminance    "Helligkeit [%.0f Lm]"    (gBuero,gIlluminance) ["Light","Measurement"] {channel="zigbee:...."]

The synonym works, but if you ask as you would usually do in German, it catches one additional item which does not belong to location “Garden” a.k.a. “draußen”. If you ask for “Licht im draußen” (nobody would say this in German :wink: ), it brings the expected results:

I guess there are a lot of similar cases to get “teached” to achieve a good experience :wink:

Probably to be collected in the issue tracker for HABot - WDYT?
I’m happy to list some if I come across some oddities - let me know, where do you want this to get tracked :wink:

0 Likes

(Yannick Schaus) #26

Yes you can open a generic issue on the HABot repo with your findings to improve the German natural language understanding. Especially the set-value intent might be a little weak in terms of training (Heating and rollershutter via HABot).

0 Likes

(Curlyel) #27

FTR: I’ve raised three separate issues for “single digit”, “location without preposition”, “rollershutter percentage”:



2 Likes

(Stritti) #28

I will have a look on these issues in the next days.

2 Likes

(David Masshardt) #29

On the Github page of HABot I’ve just read that the attributes should also have prefixes. (like “location:”) I did try this on OH 2.4 but then the attributes were not recognized in HABot anymore. Is that something that will work in future versions of HABot?

0 Likes

(Yannick Schaus) #30

No, this was the former way of tagging your items, it’s been since then replaced with what’s described in the OP.

Is that so? That’s a mistake then, can you please point out where?

0 Likes

(David Masshardt) #31

It is described that way in the HABot GitHub readme: https://github.com/ghys/habot.

See chapter “How to add named attributes”.

Edit: Sorry I just saw that I was looking at a forked repository that hasn’t been updated yet.

0 Likes

(Yannick Schaus) #32

Oh right, that was my personal fork, it was several commits behind. I have now updated it. Sorry for the confusion.

0 Likes

(David Graeff) #33

Developer question: @ysc

Where do you get the valid Location , Property , Point and Equipment tags from? Are they fixed strings in habot, provided by a habot specific REST api or provided by OH core REST?

I’m asking, because a unified UI should be able to semantically tag items and predefined tags should be made available via OH core, I think.

Cheers, David

0 Likes

(Yannick Schaus) #34

Unfortunately, currently there’s no API to list them, you have to “know” them… There’s a csv file and a groovy script to generate their code as subclasses of the Tag interface (here).

0 Likes

(Rich Koshak) #35

Does it make sense to build an API to list them? I agree with David that the UI support should give us a list to select from (though just a list might be a bit overwhelming given the number of tags).

Is this list expected to change? Perhaps a short term solution would be to just hard code the list until an API can be built.

0 Likes

(Yannick Schaus) #36

Yes, I agree too. I also wanted something like that for HABot itself but it was never done. :slight_smile:

Admittedly it’s a little difficult to change this list without being a developer but of course, it’s not set in stone - he goal was to collect some feedback and try to refine it.

1 Like

(David Graeff) #37

Ok understood. I would rework that bundle in the following way if no objections arise:

  • Make the CVS a bundle resource.
  • Remove the generated Tag classes
  • Read in the CVS on bundle start in a Tag factory class (or in SemanticTags) and dynamically generate Tag classes (although, I don’t need real classes, do I).
  • Add i18n support
  • Add REST interface to retrieve semantic tag types by category or just all.

Cheers, David

0 Likes