The idea behind this binding is to support different types of pelletburners, but which all are connectible via LAN/wifi.
Currently it’s in early stages of development which means it only have an implementation of NBE v13.1005.9 some of the readable information available, and no possibility to change data/setup (see README.md in binding).
The design concept is that if a different version of the same software is to be supported, a new set of subclasses for Protocol class should be created.
If a different product/model is to be supported, a new ThingHandler should be created.
Any and all suggestions, feedback and questions are very welcome.
I just did a quick search, and it seems the protocol being used might not be that different than the current state of the binding, as per this discussion.
You could try to follow the advice in the second post in that discussion, and use nbetest to see if anything works by trying to read some values.
Just be aware that autodiscovery didn’t work at all for me, so you should probably always just specify the actual IP of the burner.
Also try doing a more thorough search than I just did, to see if anyone else already did implement the protocol, as that would be a great help instead of us having to start from scratch.
Also at some point we probably need to use Wireshark to check the communication between the burner and the controlunit (app/cloud etc) in order to reverse-engineer it.
I know that Nbetest isworking, because that is how I have made my current integration; I call it with the EXEC binding and a GET every minute and pick the relevant data using REGEX. Works OK but the processing seem a bit excessive. Similarly I use SET commands to set the target temp and turn on/off the stove. Works OK also.
I would prefer using a binding as I am hoping for a bit simpler integration and something others could also use (my impl. is a bit “custom”).
Where would I find the .jar file with the binding? And will it run under OH 3.x ?
I’ve now updated the binding to OH3 and it works on a new installation of OH3.
You can find it here.
I’ve added a ‘refreshData’ channel which can be used to manually fetching the data from the burner so that you don’t have to wait for the refresh job to execute.
It takes some time before the data is fetched (normally 10-30 seconds), so try to avoid pressing it multiple times in a row.
If you want to use that functionality, I recommend you disable the automatic refresh by setting refresh=“0” in the Thing configuration.
You can see in the README how to setup the item and sitemap for this channel.
Be aware that if you reload the binding or change the configuration for the binding when OH3 is running, it might give some errors in the logs.
I recommend you stop OH before doing such changes, and start it again afterwards.
In case of any issues, try setting logging level to debug (add this line to installdir/userdata/etc/log4j2.xml):