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.
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 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
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.
is .yaml going to be the new standard? Is .json defunct?
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
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 "<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/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.
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.
Thanks for the reply @gez-mycroft. Logs have been uploaded here: https://termbin.com/znbf
There looks to be quite a few errors in the older logs. The merge conflict started when I switched branches on the Home Assistant skill.
Let me know if I can provide any other information to help.
Ah my bad, I think it’s actually a variable annotation rather than a standard type hint.
These were defined in PEP 526 and were introduced in Python 3.6. So you will get a syntax error on anything < Python 3.6.
We will need to decide how we handle this before it gets merged into the Marketplace…
Christopher
I have been away from Mycroft for months and am wanting resume. By coincidence 19-08 is out. So far it’s not working out so well. The device was set to check for updates so of course it did that.
As before I installed skill-iot-control and homeassistant. Upon starting mycroft, homeassistant complains it can’t send the metasettings for 19-08. I don’t see 19-08 in the HA branches on github.
When I checkout feature/commonIoT as you instructed previously then HA doesn’t even load.
There doesn’t seem to have been any activity on HA since June.
Hey @Robert_Dyck,
Several months go, Mycroft (the company) made the decision to focus on a set of core skills, to try to get them in tip-top shape for the Mark II (@gez-mycroft may be able to provide more context - I believe there was a blog post with some details). As part of this shift in focus, the CommonIoT work, including porting the Home Assistant skill, was put on hold. I know there were some API breaks a short while back, which is probably why the skill no longer loads, in particular on the CommonIot branch which, as you noted, has not been updated in quite a while. I am no longer working on the skill, but it is possible someone else has picked it up and is working on it - it may be worth checking on Mattermost.
-Chris
1 Like