The few skills I tested except for HA were OK. If I switch back and forth between branches 19.02 works and feature/commonIoT does not.
One of the things I tried was stopping Mycroft, deleting the device from home.mycroft.ai, start Mycroft, record the key I get from Mycroft and enter it in home.mycroft.ai to create a new device.
It didn’t help.
From the working branch I see Mycroft contacting HA via http after I say or type in a request but not during initialization. In addition the working branch has a web socket connection to the host where HA is running.
So is there some hierarchy that needs to be traversed to arrive at a specific skill and failing that ultimately we go to a fall back. The HA skill would have to inserted before the fallback. Isn’t that where it fails?
On the working branch if I don’t fill the HA contact information at home.mycroft.ai, it will tell that I need to go to home.mycroft.ai and fill it in.
What version of mycroft-core are you running? Also, just to confirm, you have the iot-control-skill installed as well, correct?
If you comment out or delete this line, does the skill load successfully? (You should be able to run very basic commands, e.g. “turn on the lights,” without that line, but you won’t be able to specify specific devices, e,g, “turn on the kitchen lights”).
Note that if you change the file and want to get back to the original, just run git checkout <filename>, e.g. git checkout __init__, to reset it - if you give a directory, you can reset all the files in that directory, e.g. git checkout . (the dot does the current directory, so at the top level of the repo, it resets everything).
skill-iot-control.mycroftai is in /opt/mycroft/skills.
I’ll have a look at the line you mentioned.
Edit:
Skill-iot-control shows up in the skills listing at home.mycroft.ai as does the homeassistant skill
Thanks. One other note - Mycroft should automatically reload the skill if you change that file, so you can just edit it and save it and then check if it was loaded. No need to completely restart.
Apologies for pushing this debugging on you - without a trace giving the line though, I’m a little blind. Appreciate your patience here.
I already did the stop and start. Loading the HA skill fails the same way.
I assume commenting the line is acceptable.
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
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.
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
}
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.
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?
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
Homeassistant has built-in MQTT support - should be easier and the MQTT-skill mentioned by Christopher does not support Common-IOT yet…
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.
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.
@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
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.
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.
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.
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.
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 Check device status before/after issuing commands · Issue #11 · MycroftAI/skill-homeassistant · GitHub 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