Presumably most of the Insteon stuff will just need to be copied and refactored from the existing 1.x binding. You are not starting from scratch in that regard.
As for learning to write a binding, start here but realize there are a lot of edits and improvements being made to these even as I type this.
Cool. I was just curious if the decision was caused by OH policy or Eclipse was insisting on a new major version to complete the break.
Does the removal of “eclipse” from the name spaces have to be a full version update?
If you go with semantic tagging (API breakage -> new major version) then yes.
I agree. yet that does not mean it has to include all the other changes.
You could have this eclips change in OH3
and other changes in 3.5
yet I assume that will be breaking changes too, so that would make it OH4.
it seems the only feature with a deadline is the eclipse one.
y
But to be honest I’m that close to just remove all the textual examples from the mqtt binding. That’s more than half of the documentation now and with every PR that section is growing. (Alternatively I add pictured Paper UI explanations on top of that. But I wonder who is reading the resulting 30 pages doc then!)
That would move even more people to the forums.
At this moment I don’t have time to swap to MQTT2, yet without proper documentation I would not even consider starting.
The idea is to auto-generate all the config fields. They are already defined in the binding (two times actually) and are perfectly machine readable and can be written in a standard format.
The examples and migration sections stay of course.
@crxporter I am using Insteon with the ISY99. I like this route as it makes managing the Insteon network much easier -> link management, device replacement etc. The binding for the ISY is not perfect but at least it is a 2.0 binding.
The idea is to auto-generate all the config fields. They are already defined in the binding (two times actually) and are perfectly machine readable and can be written in a standard format.
My MQTT server is on another machine, I’m not sure how you will auto configure that
This topic is about the MQTT documentation page. I’m talking about auto-generation of the config fields that are currently manually documented.
This topic is about the MQTT documentation page. I’m talking about auto-generation of the config fields that are currently manually documented.
The idea is to auto-generate all the config fields
ah what you meant to say was:
I’m talking about auto-generation of the documentation of the config fields that are currently manually documented.
It would also help to have a short documentation with some easy to understand examples on how to correctly name a Tasmota switch. The current homie docs are quite hard to read and lack examples.
Tasmota supports the Home Assistant method of discovery- it’s an option that can be turned on in the console on your tasmota switch/sonoff/whichever. Check the tasmota docs but it’s something like:
setoption19 1
Thanks. I saw that and tried, but I can’t get the whole MQTT thing to work so far.
Although the broker shows as being connected in OpenHab, I do see strange error messages, and checking on the mosquitto log I see it’s actually not subscribed.
I find this quite hard to debug as the documentation is, well, a bit dispersed.
2019-02-05 18:44:01.251 [INFO ] [.transport.mqtt.MqttBrokerConnection] - Starting MQTT broker connection to '192.168.1.111' with clientid paho269378389658284 and file store '/openhab/userdata/mqtt/192.168.1.111'
2019-02-05 18:44:01.406 [ERROR] [g.discovery.AbstractDiscoveryService] - An error occurred while calling the discovery listener org.eclipse.smarthome.config.discovery.internal.DiscoveryServiceRegistryImpl.
java.lang.NullPointerException: null
at org.eclipse.smarthome.config.discovery.internal.DiscoveryServiceRegistryImpl.thingRemoved(DiscoveryServiceRegistryImpl.java:278) ~[?:?]
at org.eclipse.smarthome.config.discovery.AbstractDiscoveryService.thingRemoved(AbstractDiscoveryService.java:300) ~[?:?]
at org.eclipse.smarthome.binding.mqtt.generic.internal.discovery.HomeAssistantDiscovery.receivedMessage(HomeAssistantDiscovery.java:164) ~[?:?]The naming is up to you!
On the error posted:
What kind of broker do you have running? (embedded, Mosquitto or …).
How did you configure the binding (files or PaperUI)? If with files, please post.
FYI: HomeAssistant discovery is not correctly working in OH2.4.
For OH2.5 discovered bugs: MQTT development is on hold at the moment, because openHAB is still in the process of reintegrating Eclipse Smarthome.
Why is it that if you click on the Add-Ons menu item at the top of the forum page and scroll to the MQTT binding information you still see v1 information even if you have selected latest?
I’m trying to help a friend with the migration and he wants to review all of the docs beforehand.
Is the documentation maintained somewhere else?
Squid
Documentation is available for all of the old stuff, which is important because not everyone has updated yet.
Version 2.4 mqtt docs are here:
Broker connection
Generic thing configuration
And if you’re going to use it, the embedded broker
I thought the whole purpose of the version switch was to support documentation of various versions.
It’s just confusing to new users.
Look here, no look here, no look there.
You see v1 AND v2 bindings. The MQTT bindings might just not be visible at the moment. We are migrating bindings to a new buildsystem and their location within the repository changes. The webscript will run every few days only though and will then pick those new locations up.