-
-
Notifications
You must be signed in to change notification settings - Fork 3.6k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[mqtt][WIP] Make Homeassistant discovery work for Tasmota #4927
Conversation
Thanks a lot. I had a brief look and I suggest to split your PR for effectively a faster merge.
Therefore I suggest that you:
That way we can get your 3k lines PR merged within a few days. Cheers |
Now you can flood me with small to medium changes to the MQTT HA subsystem, preferably first structural changes that you require, then changes to each HA MQTT component as single PRs. Thanks again for the effort and hopefully OH 2.5 will have a tremendous MQTT HA discovery support. |
@davidgraeff
Both have their pros and cons.
Which one to preceed? |
I tend to option 2, but I'll make up my mind tomorrow. |
I'm pretty sure now that I prefer option 2. Abbreviations are one feature, that IMO should be kept in one place (separation of concerns). |
I have been looking at the homae assistant implementation to cross check, what we are doing. But we should talk about the If we want to keep the In general, what is the mapping: I would like to see an openhab 'thing' that corresponds to a home assistant 'device'. That is probably a new openab mqtt thing type to keep the compability. That thing would need to be configured with a list of mqtt topics (basically base topic, node_id and object_id). Each of which will create a channelGroup. Does that make any sense? Is there a way to enter a multiple strings value in the configuration parameters? |
Please don't care about compatibility. The HomeAssistant support was implemented by someone (me) who has never used HA and tried to map HA specific entities like components, objects and nodes to openHAB jargon. If you think, that a different design makes more sense, I will support that.
That is supported via "multiple". If multiple is set on a configuration description parameter, it will be represented as a
node_id seem to be rarely used. I thought it is a good idea to just use it as a suffix to object_id. As far as I understood, it is like an instance of an object, so yes, multiple same object ids with different node ids.
Nothing wrong with that.
That sentence and paragraph puzzled me. HA does not have the notion of a "device" afaik. They have objects, nodes, components. I think you are overestimating node_ids importance. We can as well just disallow all node_ids that contain an underbar, if you are worried of escaping. External projects will soon stop to use those characters if a major implementation like OH is not supporting them, I guess. |
I was looking into this: https://developers.home-assistant.io/docs/en/device_registry_index.html From that it feel natural to me, that a OH thing is such device. So my Sonoff TH (with tasmota) with a switch and 2 sensors (temperature and humidity) would be respresented as one thing. So a thing would represent multiple <node_id>/<object_id> instances. BTW: compability was an issue you brought up in https://github.com/openhab/openhab2-addons/pull/4927#issuecomment-464905084 I think I will go forward to remove the explicit node_id and implicitly allow object_id to be <node_id>/<object_id>. And remove any explicit values from the groupId and put those values into the group configuration. |
Sounds right.
I agree. |
@jochen314 Could you describe what is still left to do from this PR after the merge of #4990? Thanks |
There are several things:
- default state topic.
- expand functionality for each component to support the full spec and add vaccum support.
- organize components into things by device.
If you want to migrate to the new build system first, i have no problem to pause after the default state topic.
Would the migration give me osgi junit tests again? Currently i have the problem, that org.openhab.core.test has an unsatisfied import to org.hamcrest....
Am 18. März 2019 08:07:03 MEZ schrieb "David Gräff" <notifications@github.com>:
…
@jochen314 Could you describe what is still left to do from this PR
after the merge of #4990? Thanks
--
You are receiving this because you were mentioned.
Reply to this email directly or view it on GitHub:
https://github.com/openhab/openhab2-addons/pull/4927#issuecomment-473793705
--
Diese Nachricht wurde von meinem Android-Gerät mit K-9 Mail gesendet.
|
The new build system will take some time to get used to, so I like to avoid the migration until you have finished your PR. There are some caveats like a broken auto re-build in Eclipse. Unit tests would work though. I have written a small howto in the migration issue: https://github.com/openhab/openhab2-addons/issues/5005. If you think that this will also work for you, then I'll do the migration, otherwise I'll just wait, that's fine as well. |
I do not plan to stop contributing after these topics.
I think, after #5156 we have a good point to think about the migration. |
Alright I merge the other PR as soon as travis is satisfied and do the migration |
I have created #5240. |
@jochen314 What is the state of this PR? I see a lot of merge |
I think, the most important parts of this have gone to other PRs by now (the last one #5978 ). |
Impovement of Homeassistent discovery.
I have a couple of tasmota devices and I wanted to have the homeassistant discovery work for them.
I found several problems.
Tasmota is using
All these issues are adressed by this PR.
There were several external libraries needed for the jinja templates. To my knowledge, their licences are OK to be used.
There were also several features added to the different HA component types. They should be feature complete, but
The PR groups HA components by the device (substructure in the config), they are in.
Therefore there is a thing for each device.
Each HA component is a group having one or more channels,
For this a dynamic thing type provider is implemented.