General SwitchBot devices status decoders

[DigiH]

Discussion about various SwitchBot devices' status implementations and testing of such …

[DigiH]

SwitchBot Curtain status decoder ready to test with

decoder = https://github.com/DigiH/decoder#switchbot-curtain

in platformio.ini

Would be great to get some feedback, especially if

motionstate should report back the current strings "stationary"/"movement"

or if it's nicer to rename it and make it a blooean

motion should report back the current strings false/true

[1technophile]

For the Switchbot W2301500 thermometer and hygrometer, here are some sample messages:

{"id":"E0:HH:HH:HH:HH:CE","mac_type":1,"manufacturerdata":"6909e02122c12fce060208993b","rssi":-63,"servicedata":"6900ba08993b","servicedatauuid":"0xfd3d"} 25.8C 56%
{"id":"E0:HH:HH:HH:HH:CE","mac_type":1,"manufacturerdata":"6909e02122c12fce0702089938","rssi":-56,"servicedata":"6900ba089938","servicedatauuid":"0xfd3d"} 25.8C 56%
{"id":"E0:HH:HH:HH:HH:CE","mac_type":1,"manufacturerdata":"6909e02122c12fce0b02009ab8","rssi":-51,"servicedata":"6900ba009ab8","servicedatauuid":"0xfd3d"} 78.8F 56% (set in Farenheit)

[1technophile]

Good catch. Maybe we keep it like you have SWITCHBOT-METER and add the different models in the .md

[DigiH]

I've just tried with the latter suggestion above and I think it doesn't look bad

DigiH@77f67c5

unless you think the asterisk * might cause issues on some platform, an alternative would be

"model_id":"TH X1/W230150X",

or do you think it's best as you said above, revert to what I had before and list the modelIDs in the .md?

Also thanks for testing the sub-zero temperature ;) once we decide on the modelID this is good to go, and one of the SwitchBot inclusions which doesn't really require any WRITE command integration.

Thanks

[1technophile]

Thanks,

Let's just remove the ampersand, add the list of models in the .md and we are good to go

[DigiH]

Hi @1technophile, naming the SwitchBot modelIDs in the .md files with an asterisk (*) sort of backfired

https://decoder.theengs.io/devices/SBMT.html

where it should have been
TH *1 (W230150*)

now the two asterisks are invisible, but making the type in between them italic ;)

So maybe really best to replace the asterisks with "X"s.

TH X1 (W230150X)
X1

And this could also then be presented as modelIDs in the JSON withouth any issues.

What do you think?

Thanks

[1technophile]

So maybe really best to replace the asterisks with "X"s.

Yes that works.

[h2zero]

@DigiH Yes the bin bit test is certainly a good addition. There is nothing wrong with your code, just that for such a simple case it is overkill 😄.

Here is another version for you to try:

if (data_src) {
  size_t cond_len = strlen(prop_condition[i + 2 + inverse].as<const char*>());
  if (strstr((const char*)prop_condition[i + 2], "binbit") != nullptr) {
    char ch = *(data_src + prop_condition[i + 1].as<int>());
    uint8_t data = 0;
    if (ch >= '0' && ch <= '9')
      data = ch - '0';
    else if (ch >= 'a' && ch <= 'f')
      data = 10 + (ch - 'a');
    else if (ch >= 'A' && ch <= 'F')
      data = 10 + (ch - 'F');
    else
      return false;
  
    uint8_t shift = prop_condition[i + 3].as<uint8_t>();
    uint8_t val = prop_condition[i + 4].as<uint8_t>();
    if (((data >> shift) & 0x01) == val) {
      cond_met = true;
    }
    i += 2;
  } else if (!strncmp(&data_src[prop_condition[i + 1].as<int>()],

Also, maybe "binbit" should be just "bit"?

[DigiH]

Thanks @h2zero @1technophile , I added the bit evaluation condition and converted the new SwitchBot Meter and the existing SwitchBot S1 decoder, saving quite a bit of real estate and leaving m_docMax untouched.

DigiH@ffdbd6e

This will also be a prerequisite for most other upcoming SwitchBot decoders and a few existing decoders will also benefit from an adjustment.

[DigiH]

SwitchBot Motion Sensor initial status decoder ready for testing with

decoder = https://github.com/DigiH/decoder/tree/switchbot-motionsensor

in platformio.ini

Would be great to get some feedback about

• areLED state and IoT state really required to be reported?
• is scope tested fine wiht only showing up when false?

Thanks

[h2zero]

Wow that thing is huge lol, trimming anything unnecessary would be the best practice.

[DigiH]

As I previously wondered, who would have thought that a simple motion sensor would be so overloaded with possible properties ;) you really wouldn't have wanted to see it when it was still using long stringed together OR conditions!

I also think that several statuses could be removed, like the LED state and IoT state mentioned above, and possibly some more, but until someone who has the actual device joins in with some sample data and suggestions on the necessary properties I'm just leaving it as is for the time being, obviously without any intention on submitting it like that ;)

BTW with the recent conversions of some decoders to use the bit condition the required m_docMax has gone down for the first time; to 5895, but I didn't touch the current 7168 to leave some breathing space.

ADDENDUM: With the recent bit condition introduction it often is the case that two conditions for the same property have static results solely depending on the 0 or 1 state of the bit. If some new static_value addition here would also reduce the size of several decoders, like

      "movement":{
         "condition":["servicedata", 2, "bit", 2, 0],
         "decoder":["static_value", false],
         "is_bool":1
      },
      "_movement":{
         "condition":["servicedata", 2, "bit", 2, 1],
         "decoder":["static_value", true],
         "is_bool":1
      },

to

      "movement":{
         "decoder":["static_value", "servicedata", 2, "bit", 2, ? false : true],
         "is_bool":1
      },

or

      "mode":{
         "condition":["servicedata", 2, "bit", 3, 1],
         "decoder":["static_value", "on/off"]
      },
      "_mode":{
         "condition":["servicedata", 2, "bit", 3, 0],
         "decoder":["static_value", "onestate"]
      },
      "state":{
         "condition":["servicedata", 2, "bit", 2, 0],
         "decoder":["static_value", "on"]
      },
      "_state":{
         "condition":["servicedata", 2, "bit", 2, 1],
         "decoder":["static_value", "off"]
      },

to

      "mode":{
         "decoder":["static_value", "servicedata", 2, "bit", 3, ? "onestate" : "on/off"]
      },
      "state":{
         "decoder":["static_value", "servicedata", 2, "bit", 2, ? "on" : "off"]
      },

in the SwitchBot Bot decoder - just a thought for possible future further compressions.

[DigiH]

Initial test with my lacking experience, but I think the compression in the example SwitchBot Bot, Xiaomi Sclaes and CGH1 decoders is quite desirable.

@h2zero I'm sure you have a few correction/improvement suggestions :)

https://github.com/DigiH/decoder/tree/static-bitwise-test

Even with my current, to be optimised, code

OMG [env:esp32dev-ble]

decoder = https://github.com/theengs/decoder.git#v0.4.0
RAM:   [==        ]  17.8% (used 58384 bytes from 327680 bytes)
Flash: [=======   ]  73.5% (used 1444280 bytes from 1966080 bytes)

decoder = https://github.com/DigiH/decoder#static-bitwise-test
RAM:   [==        ]  17.8% (used 58384 bytes from 327680 bytes)
Flash: [=======   ]  73.4% (used 1443496 bytes from 1966080 bytes)

at least a slight reduction with the so far converted decoders.

I suppose here we don't actually need the upper case evaluations, as servicedata and manufacturerdata are always present in lower case ...

Thanks

[DigiH]

• condensed getBinaryData to its own function, it being called twice
• commented out the UPPER case condition, as all presented data should only be presented lower case
• commented out the static_value bool cast which I introduced in #96, as this doesn't seem to be necessary any longer, possibly due to an included library change?!? Ok to delete it, or better to keep it in, just in case a future change might revert this again?

Thanks