Homeassistant skill misinterprets request

Mycroft Project Skills
#26

Hey @Robert_Dyck,

Apologies for the delay. I’ve created a new branch called feature/commonIoT-rdyck that has some additional logging. If you run get checkout feature/commonIoT-rdyck to switch to that branch, that should hopefully give us some more information about where this is failing during startup.

If you’re around tonight or tomorrow, I’m also happy to jump on Google Hangouts or Skype, if we can find a time that works for both of us. If you’re on Mattermost for mycroft, feel free to message me there and we can work out the details for that (or even just to iterate there, which should be faster than working this out here in the forum).

-Chris

#27

I will give it try and also figure the most convenient way to communicate.

In the meantime I did a clean install on the machine that I had used first. I had switched to a second machine because precise failed ( tensorflow bad op ) on the first. I compiled tensorflow for my architecture. I switched to the feature branch and it was working. Encouraged, I did a clean install on machine two but it still failed the same way when I was on the feature branch. Well almost the same. When loading the HA skill there are two exceptions raised as before but I noticed that the second exception identified an address which I didn’t see in the trace I sent you.

Connection Error: HTTPConnectionPool(host=‘localhost’, port=8123
The URL is wrong because port 8123 being HA, and HA is on machine one, the one apparently working.

I don’t know if it related to the exceptions but is there a way to purge some of the skills that home.mycroft.ai thinks are installed. I see four instances of homeassistant. They each should have a configuration dialog where the host and token should be entered. Two of them have an empty dialog. My guess is that this is related to switching branches after the skill was installed.

What is the purpose of settingsmeta.yaml in the skill’s directory? When filled it with the host and token it didn’t improve anything, rather it caused starting mycroft to take about five minutes.

#28

The settingsmeta file is what defines the config card on https://home.mycroft.ai (you can read more about that file here). In general, you should not edit that file (unless you are intending to change the functionality of the skill itself).

The new branch does indeed have a few extra settings that could be generating a new configuration card for you in the UI, in particular if you have the homeassistant skill installed on multiple devices, running different branches. If you see one with “brightness step” and “temperature step” that should be the right one (assuming there’s only one with those fields).

If you are having issues with that, however, you can force the settings in by editing the settings.json file in the skill’s directory. It should already exist, and be populated with values, but in case it is not, it should look like this

{  
    "__mycroft_skill_firstrun": false,
    "brightness_step": "20",
    "enable_fallback": true,
    "host": "localhost",
    "portnum": "8123",
    "ssl": false,
    "temperature_step": "2",
    "token": "eyJ0eX...",
    "verify": false
}
#29

I just pushed up one small change to the settingsmeta.yml file on the feature/commonIoT-rdyck branch (as well as feature/commonIoT). I had used Number rather than number, which was preventing a couple fields from rendering properly in the config card. If you run git pull from the homeassistant skill directory, it should pull that change in.

#30

Time to get some yard work done but I a random and somewhat off topic thought. Most home automation controllers already have a common interface called MQTT. Could that leveraged as well?

#31

There’s an existing MQTT skill, but other than that it exists, I know nothing about it. You can find it here: https://github.com/jamiehoward430/mycroft-mymqtt

#32

Homeassistant has built-in MQTT support - should be easier and the MQTT-skill mentioned by Christopher does not support Common-IOT yet…

#33

Right, I am currently using MQTT for my sensors and actuators on Homeassistnat. MQTT is a “many to many” protocol. You could in theory operate an actuator directly with Mycroft and use Homeassistant as a dashboard or trigger an automation.

#34

Both instances of Mycroft display the same connection configuration.

08:30:13.057 - homeassistant_mycroftai - INFO - Setting up HA client with settings:
port: 8123,
host: localhost,
token (truncated): eyJ0eXAiOi…,
ssl: False,
verify: True
The working instance also loaded the HA’s known entities.

08:30:13.059 - homeassistant_mycroftai - INFO - Client setup
08:30:13.069 - homeassistant_mycroftai - INFO - Entities: defaultdict(<class ‘list’>, {‘automation 0’: [‘automation.automation_0’], ‘mary’: [‘switch.movable_socket_2’], ‘sue’: [‘switch.movable_socket_1’], ‘olga’: [‘switch.movable_socket_3’], ‘july’: [‘switch.movable_socket_4’], ‘sonoff’: [‘switch.sonoff_2’, ‘switch.sonoff_3’], ‘george’: [‘switch.mysensors_gateway_1_0_4’]})

The non-working instance, of course, raised an exception.

The odd thing is the skill cards on home.mycroft.ai are both filled in with the explicite IP address of HA not localhost.

#35

@Robert_Dyck,

host: localhost

It looks like it’s trying to connect to home assistant on localhost. This would explain why one mycroft instance connects, and the other does not (assuming the functional instance is running on the same machine on which you are running home assistant).

If you have set the IP in the UI, and they are still not picking up the settings properly, it’s probably worth setting it manually in that settings.json file.

If we can confirm that it does connect and function with the correct settings, we can then address why you are not getting the correct settings from home.mycroft.ai.

-Chris

#36

I found settings.json filled already.

{“host”: “192.168.1.3”, “token”: “eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9.eyJpc3MiOiI3YjAzNzVmNmQ4ZGM0MTk5YWNhNjdkMjE2ZTIxZWIzNiIsImlhdCI6MTU1OTA5MDIyOSwiZXhwIjoxODc0NDUwMjI5fQ.gwLYyv6v_TOxiUVZo2V-0zxFuMCfnGK4zLet65hFilg”, “portnum”: 8123, “ssl”: false, “verify”: true, “enable_fallback”: true, “brightness_step”: 20, “temperature_step”: 2}

It is still trying to connect to localhost. Altering settingsmeta.yaml didn’t help either.

#37

Ah! I think I got it. In my rewrite of the skill, I’ve been using hostname, but I tried to leave the settingsmeta (mostly) untouched for a smoother transition for existing users, and the original version of the skill called that setting host (you can see it in that settings.json file). I’ve pushed up a change to the feature/commonIoT branch that should correct it. Can you checkout that branch, pull the latest change, and try again? (Should be able to do it all with git checkout feature/commonIoT && git pull from within the home assistant skill directory.)

If I’m right, that should fix it.

#38

Much better. I can turn an actuator on and off. Well done.

The following error does not seem to affect the operation.

21:08:55.465 - mycroft.skills.settings:_poll_skill_settings:410 - ERROR - Failed to fetch skill settings: TypeError(
“argument of type ‘NoneType’ is not iterable”)
Traceback (most recent call last):
 File “/home/rdyck/mycroft-core/mycroft/skills/settings.py”, line 403, in _poll_skill_settings
   self.initialize_remote_settings()
 File “/home/rdyck/mycroft-core/mycroft/skills/settings.py”, line 227, in initialize_remote_settings
   settings = (self._request_my_settings(self.skill_gid) or
 File “/home/rdyck/mycroft-core/mycroft/skills/settings.py”, line 512, in _request_my_settings
   self._type_cast(skill_settings, to_platform=‘core’)
 File “/home/rdyck/mycroft-core/mycroft/skills/settings.py”, line 486, in _type_cast
   if “.” in value:
TypeError: argument of type ‘NoneType’ is not iterable

It’s probably a slam dunk for you.

I’ll change the friendly names of my entities and test numbered entities again. Not tonight.

#39

In my testing of the new commonIoT I can confirm that Mycroft now manipulates the correct entity where multiple entities share a common base name but followed by a unique number.
The previous behaviour was to become fixated on the first numbered entity it downloaded and there after numbers were simply ignored and it would only act one one entity.

Some more work is necessary however. Mycroft seems to be unaware of an entity’s present status. If it is already on, asking to turn it on causes Mycroft to again go through the motions without any error message.

Some of my switches are devices that are plugged into a wall outlet. When plugged in they register with HA. When not plugged in their HA status is ‘unavailable’. Mycroft ignores the unavailable status when you ask it to turn on/off. It gives a little chirp to say that it has complied.

#40

Thanks for the feedback @Robert_Dyck. Glad to hear that you’re at least able to work with your numbered entities.

This is what I would personally expect. Setting the lights to a state they are already in does not seem like it warrants an error to me, though if you have a strong argument for why this should be treated differently, please share it.

This is definitely more interesting. The home assistant API generally does not provide any feedback for things like this - a request is made to the API and it issues a successful response back to us, regardless of whether it actually did what we wanted. We could potentially check the status of the device before issuing the command, and then check the status of the device after issuing the command, but there are some potential pit falls there (classic race conditions - the device being online when we check doesn’t mean it’ll be online when we issue the command, and it’s possible that after we issue a command, some other app or service submits a different command, leaving the device in a state other than what we expect).

I think this (devices not being online) is an edge case we’ll want to address at some point, but I think it makes sense to hold off until the rest of the CommonIoT work is done (currently working on supporting queries, e.g. “what is the temperature in the living room?” and “is the bedside switch on?”). I’ve opened https://github.com/MycroftAI/mycroft-homeassistant/issues/11 to track the issue though, so it doesn’t get lost here on the forum.

Please let me know if you have any other feedback. Very much appreciate you being a beta tester.

-Christopher

#41

I appreciate the difficulty. Mycroft is more one-way oriented than Homeassistant and its ilk. HA is all about knowing the status of the devices it is responsible for. With Mycroft the onus is on the human to be aware of the status of the entities. It wouldn’t make sense to ask Mycroft to turn on the office light when you know it is already on. However it not difficult to dream up situations where the human didn’t know the current status. The ability to query an entitie’s status whether it is a sensor or a switch would be useul.

The beauty of MQTT ( here I go again ), is that one simply subscribes to a “TOPIC”, that is to say the entity plus its status. The subscribers could be a full on home automation system, a remote dashboard, or a generic app on your phone.

This has been interesting and I’ll try to keep up with the development of Mycroft, especially as it relates to IOT.

#42

is .yaml going to be the new standard? Is .json defunct?

#43

JSON is dead, long live JSON

JSON isn’t going anywhere and that includes in Mycroft. settingsmeta.json files etc will continue to be supported, we are just supporting yaml as well.

1 Like
#44

sorry to jump in on this thread, I am attempting to get the Home Assistant skill up and running too. I had issues with devices with similar names being confused with each other.

“Turn on the lounge lights” would get picked up as “turn on the lounge lamp” for example. Similar to what is described in the opening comment.

I decided to switch to the CommonIOT branch and install the common IOT platform. Both unfortunately throw errors:

14:29:01.522 - mycroft.skills.core:load_skill:169 - ERROR - Failed to load skill: homeassistant.mycroftai

Traceback (most recent call last):

File "/opt/mycroft/mycroft/skills/core.py", line 131, in load_skill

imp.PY_SOURCE))

File "/usr/lib/python3.5/imp.py", line 234, in load_module

return load_source(name, filename, file)

File "/usr/lib/python3.5/imp.py", line 172, in load_source

module = _load(spec)

File "&lt;frozen importlib._bootstrap&gt;", line 693, in _load

File "&lt;frozen importlib._bootstrap&gt;", line 673, in _load_unlocked

File "&lt;frozen importlib._bootstrap_external&gt;", line 661, in exec_module

File "&lt;frozen importlib._bootstrap_external&gt;", line 767, in get_code

File "&lt;frozen importlib._bootstrap_external&gt;", line 727, in source_to_code

File "&lt;frozen importlib._bootstrap&gt;", line 222, in _call_with_frames_removed

File "/opt/mycroft/skills/homeassistant.mycroftai/__init__.py", line 149

self._client: HomeAssistantClient = None

and

14:29:10.583 - mycroft.skills.core:load_skill:169 - ERROR - Failed to load skill: skill-iot-control.mycroftai
Traceback (most recent call last):
  File "/opt/mycroft/mycroft/skills/core.py", line 131, in load_skill
    imp.PY_SOURCE))
  File "/usr/lib/python3.5/imp.py", line 234, in load_module
    return load_source(name, filename, file)
  File "/usr/lib/python3.5/imp.py", line 172, in load_source
    module = _load(spec)
  File "<frozen importlib._bootstrap>", line 693, in _load
  File "<frozen importlib._bootstrap>", line 673, in _load_unlocked
  File "<frozen importlib._bootstrap_external>", line 661, in exec_module
  File "<frozen importlib._bootstrap_external>", line 767, in get_code
  File "<frozen importlib._bootstrap_external>", line 727, in source_to_code
  File "<frozen importlib._bootstrap>", line 222, in _call_with_frames_removed
  File "/opt/mycroft/skills/skill-iot-control.mycroftai/__init__.py", line 63
    self.speech_requests: DefaultDict[str, List[SpeechRequest]] = defaultdict(list)
                        ^

Any tips on how I might navigate this would be greatly appreciated.

#45

Hey Scott,

It appears to be a problem with the type hinting syntax that hasn’t been used in Mycroft before. We’ve run into some trouble with it on systems still running Python 3.4 but from your output it looks like it’s using 3.5.

If you’re still getting the same error it would be useful to get a broader snippet of your skills.log

If you’re happy to share it you can run:
cat /var/log/mycroft/skills.log | nc termbin.com 9999
This will upload the log file to termbin and return a url for it.