I would love to start development on an Ecovacs Binding.
There are some libraries in the wild for python and JS, that I would like to use as a basis and port huge chunks of their code to Java:
I will start trying to convert the python implementation to java as a first step.
Still happy to hear opinions on how to handle listening to xmpp events in a way that works fine with the runtime behavior requirements for openhab. Maybe there is some kind of solution.
That sounds linke a meaningful plan. First do Java HTTP API PoC, then add XMPP listening to it, then move to OH binding.
What specifically is unclear there? At its core XMPP is also just a socket, and we open listen sockets in a lot of bindings (avmfritz, squeezebox come to my mind immediately, but there’s surely a lot more of them).
As for choosing an XMPP library, there already is an XMPP client binding, might want to look up what that one is using.
BTW, I may join forces in Ecovacs binding development…just need to find some free time.
As far as I understood from reading the docs, we should not start any kind of threads in favor of scheduling, but maybe I also missunderstood something here.
As I alrady stated: I will probably start this evening with migration of the python library and see if there are any major pitfalls.
Will link to the repository as soon as I got the first working version of the java implementation.
First step here will be just the http connection and secondly the most basic commands for start/stop cleaning with XMPP.
Would be really happy to get some support for the binding creation afterwards, since I never contributed to a binding before.
I think one should avoid creating short-lived threads that execute a single task only. Creating (few) long-lived threads should be fine, especially as there’s no other way of implementing this particular task without a new thread.
On thing that is currently unclear to me:
The libraries in the wild are using some sort of client ID. I am not sure how they get it and what we should put there. Will start with one of the library IDs, but we should find out how they acquire those IDs.
Added signing and got a successful ressponse from the ecovacs servers now.
Some additional thoughts
The libraries in the wild are all using some client keys and secrets, where I dunnot know where they got them from
For maintainability we should write docs on how to find those (probably by decompiling the android app)
If we add a binding in the future we should make sure to put all those things in a place, where openhab users can easily replace those, if they become invalid at some point
Looking through the sources (and PRs) in the sucks project, it seems that one must implement both XMPP and MQTT communication to their servers, depending on the device model?
What model do you have? I have an Deebot 950, which seems to talk MQTT.
Yes I also noticed that there is some variation in the libs, but I did not look further into it.
I got a Deebot 901 (Non-OZMO) and a N8 Pro with station
Where did you find out if your robot uses mqtt?
EDIT: Found it “static isDeviceClass950type(deviceClass, isMQTTProtocolUsed = true)”
Finished the login process for now. Also did some small cleanup, but still far from finished. Hopefully I will be able to make the first request for an action for one of my devices tomorrow.
Otherwise I will only have time next weekend.
Next step will be some cleanup + requesting devices. After that we should be able to start implementing basic commands already.
Once thats done in my POC we can think about porting everything + cleanup/code structure changes for the binding.
Just a small update for everyone interested: @maniac103 already added basic mqtt connection for devices 950 and newer. Also a basic binding was started.
What device do you own, Stefan? I think i have the binding in decent shape for Deebot 950 (and similar) already. Newer devices should mostly work as well, but everything older than that is not supported for the moment. Supporting the D901 is still on the to do list (since @jptaszyk owns that one meaningful testing is possible), but older devices use completely different communication (XMPP instead of MQTT), so I hope somebody else will be able to contribute that part.
If I believe the list found here, your device is similar to the 901 - that is, unsupported as of now, but on the list to be supported next. From that list
REST/MQTT/JSON should work as of now
REST/MQTT/XML comes next
XMPP/XML is what I’d hope somebody else to do
If you’re willing to help with implementation, you can give it a try with this binding jar. I’ve added your device to the internal list of known devices there. After installing it, you need to do the following steps:
do feature:install openhab.tp-hivemqclient in Karaf console
do log:set TRACE org.openhab.binding.ecovacs in Karaf console
create API thing, let it discover the device
create device thing, link items to the channels (ideally via UI)
start it via app, let it run a clean cycle (so the log collects the events sent by the device)
try to send it a start cleaning command, see whether that works (most easily done via UI, same as the below)
try to send a set cleaning power level command, see whether that works
try to send a set mopping water amount command, see whether that works
… and after all of that, please provide the produced log, which would then tell me about
the XML event message format
commands that maybe are not correct
After reviewing the log and adapting the code for anything found there, we may need to do a few iterations of the same procedure.
In case anyone wants to have a look at the code, the binding above is built off this branch
Thank you for the interest
And also sorry for the delay of feedback from my side @maniac103 .
We got a new dog puppy and it takes so much time
I arranged with my girlfriend so I get some hours this evening to look into 901 support an deine testing with my n8 pro
