Code/usage examples

[kevinstadler]

Great to see that MiIO is within reach for ESP8266 devices! I managed to install the library and all of its dependencies in my Arduino IDE, but I was wondering if you already have some working example sketches that you could share to get other users started? I'd very much like to have a go at my Xiaomi humidifier!

[ar2rus]

Hi, Kevin I added a simple example sketch right now. You can see how to connect, send messages and handle responses/errors here: 3537060 I used my library to communicate with xiaomi vacuum mirobo, so this example contains its specific commands. But you can use this library for your device no doubt. Welcome to ask any questions. Arthur сб, 11 апр. 2020 г. в 18:22, Kevin Stadler <notifications@github.com>:

…

Great to see that MiIO is within reach for ESP8266 devices! I managed to install the library and all of its dependencies in my Arduino IDE, but I was wondering if you already have some working example sketches that you could share to get other users started? I'd very much like to have a go at my Xiaomi humidifier! — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#1>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ACASXB5W5RGXGN5PFGEHY6TRMB4LJANCNFSM4MGAOEKA> .

[kevinstadler]

That's great, thanks so much!

I managed to connect to the humidifier, but I can't execute any commands at the moment because all of my device's commands (get_prop and 5 different Set... methods) require parameters. I see that there is already some commented out code to include an extra params argument in the current repository version. Did you run into any troubles sending the extra "param" payload over the ESP or did you just not get around to implementing incorporating the extra parameter in the JSON command? I'd be happy to work on a pull request to add parameter support, if you don't already have the code lying around anyway...

[ar2rus]

No one command for vacuum mirobo require parameters. So I just didn't implement them. Welcome to a pull request if you want to add support of them. You can see this java implementation of MiIO, which I've ported to this ESP-Arduino code

[kevinstadler]

Managed to get everything working, turned out a bit too hackish for a pull request I'm afraid...I didn't just have to add a parameters argument but also change the library-internal parsing of the response: the current code assumes that the JSON result field is always an array containing an object, but in my case the array only contains a single JSON primitive (string or number), so I made the code extract a general JsonVariant from the result array instead.

One issue that I didn't manage to sort out was trying to disconnect and then reconnect to another device (or the same device but on another IP address), I kept getting stack traces whenever I tried to change anything about the IPAddress or MiioDevice objects. Have you ever tried such a use case? I think it must have to do with the UDP connection object not being freed up properly even after calling disconnect(), and the Ticker not being detached when I try to remove its target functions/data structures...

[ar2rus]

Could you please show some examples of your JSON request/responses.
I didn't try to connect/disconnect to different IP address devices. I have the only single device, but I can start virtual device from repo I shared you before. I will try to check it tonight

[kevinstadler]

I just committed the code changes here kevinstadler/ESPMiIo@c1d777be26ca9a5d85b5ce0a5e8e5b56afb78362 -- the command parameters have to be passed as a JSON string which is first deserialized before being serialized again within the library, it's a bit stupid I know but allows for relatively easy code on the client-side (i.e. just passing the fully written JSON string instead of having to create a whole ArduinoJson document...)

The response to informative 'getter' commands like

device.send("get_prop", "\"OnOff_State\"", ...)

-- note the escaped quotation marks in the command argument, which makes sure it also ends up as a string in JSON! -- is result: [0], i.e. an array of one integer)

'setter' functions return some kind of acknowledgement string but again in an array, e.g.

device.send("Set_OnOff", "1", ...)

-- note how the command argument is a string but it gets parsed and then passed as an integer in the JSON request -- gives result: ["ok"].

[ar2rus]

You made excellent fixes! JSONVariant is the best choise for this nonJSONable api. -) I think, your code is ok, make a pull request.
I saw connect/disconnect methods, and the only way to connect to other IP address device is to create another MiioDevice instance. You should pass an IPAddress parameter to MiioDevice constructor. And it's immutable. Show example, if you don't mind

[kevinstadler]

Ah great, I managed to generate new devices with different IP addresses now!

I also figured out why I used to get lots of stack traces: I know it's generally frowned upon but you can normally get away with a little Serial.println() in the callbacks. Turns out the error callback function to device.connect() is extremely sensitive to blocking commands. It looks like for some of my code the callback is called at the end of every loop(), and the chip reboots with Exception 28 when any code attempts to print to Serial between the loops. I'll try to debug this one a little more, but already a great increase in stability!

I will prepare a pull request later today, I might add a new example as well.

[kevinstadler]

Just made the pull request!

I'm still hunting down a very bizarre bug that seems to be caused by deleteing a device that never managed to connect to its target IP address. For some reason the internal ticker stays attached and then causes a stack trace at the end of the next loop (triggered by the arduino-internal loop_wrapper function).

I think this might be related to the fact that the MiioDevice->connect() method does not obey the timeout value in the same way that send() does, is that right? Is there a particular reason for that?

Still working on getting a minimal working/broken code demonstration together, can hopefully post one later today...

[kevinstadler]

Here it is, a minimally breaking example where an outstanding connect() timeout causes the ESP8266 to reset. Can you reproduce it on your side?

#include <ESP8266WiFi.h>
#include <ESPMiio.h>

#define AP_SSID "FILL IN"
#define AP_PASSWORD "FILL IN"
#define MIIO_TOKEN "FILL IN"
#define TIMEOUT 1000

// point this IP to your local device
IPAddress device_ip(192, 168, 1, 4);

// ip that doesn't point to a MiIO device
IPAddress non_device_ip(1, 2, 3, 4);

void setup() {
  Serial.begin(115200);
  WiFi.mode(WIFI_STA);
  WiFi.begin(AP_SSID, AP_PASSWORD);
  Serial.print("Connecting to Wifi...");
  while (WiFi.waitForConnectResult() != WL_CONNECTED) {
    Serial.print("failed, retrying...");
    delay(1000);
  }

  MiioDevice nonDevice(&non_device_ip, MIIO_TOKEN, TIMEOUT);

  // this connect() attempt (which doesn't get a response) attaches a
  // ticker which causes a reset at the finish(!) of the first loop(!!)
  nonDevice.connect(); // comment out this line to stop exceptions

  delay(TIMEOUT);
  Serial.println(nonDevice.isConnected()); // should yield 0
  
  MiioDevice device(&device_ip, MIIO_TOKEN, TIMEOUT);
  device.connect(); // this line is no problem
  delay(TIMEOUT);
  Serial.println(device.isConnected()); // should yield 1
}

int i = 1;

void loop() {
  Serial.printf("Loop %d\n", i++);
  delay(1000);
}

In this particular example both of the (temporary) device objects are deleted at the end of the setup, but the ticker object of the one that's failing to connect stays attached so that something in the ticker library blows up when it is updated at the end of the loop. I've also tried with dynamically creating objects and deleteing them when they fail to connect, the behaviour is the same in all cases.

[kevinstadler]

Ok, I nailed the culprit! Turns out it had nothing to do with connect() vs send() but only with the fact that the calls were happening in my setup as opposed to loop. The problem is that MiioDevice::udp_send() currently schedules the timeout ticker using ticker.once_ms_scheduled(), which is only ever triggered between loops:

https://github.com/esp8266/Arduino/blob/ea1fdb210f84fbed421340a1341376e179e4addb/libraries/Ticker/src/Ticker.h#L103-L104

The solution in my case was to replace ticker.once_ms_scheduled() with ticker.once_ms(), which means I need to be more careful with what I put in the callbacks (no Serial.print or anything like that), but at least the timeouts also work in setup (and even within the same loop!) now.

Edit: here's some more explanation of the difference between the two, I wouldn't have been able to tell from the sparse Ticker library documentation alone... https://gitter.im/esp8266/Arduino?at=5d641e634b1189084e6b5590

[ar2rus]

Ok, I replaced ticker.once_ms_scheduled() with ticker.once_ms(). connect() in setup() is typical use case. To use Serial.print just set flag in callback and check it outside