-
-
Notifications
You must be signed in to change notification settings - Fork 32
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Better message format #61
Comments
@jamedeus submitted this log of their devices: [
{
"smartlife.iot.smartbulb.lightingservice": {
"get_light_details": {
"lamp_beam_angle": 180,
"min_voltage": 100,
"max_voltage": 120,
"wattage": 10,
"incandescent_equivalent": 60,
"max_lumens": 800,
"color_rendering_index": 80,
"err_code": 0
}
},
"sw_ver": "1.0.6 Build 200630 Rel.102631",
"hw_ver": "2.0",
"model": "KL130(US)",
"deviceId": "80129F350A3500A88C839AF924A72DD51D955202",
"oemId": "936CC35F9C27073112B5651D1B17EFD4",
"hwId": "1E97141B9F0E939BD8F9679F0B6167C8",
"rssi": -47,
"latitude_i": 0,
"longitude_i": 0,
"alias": "TP-LINK_Smart Bulb_4847",
"status": "new",
"description": "Smart Wi-Fi LED Bulb with Color Changing",
"mic_type": "IOT.SMARTBULB",
"mic_mac": "84D81BEA4847",
"dev_state": "normal",
"is_factory": false,
"disco_ver": "1.0",
"ctrl_protocols": {
"name": "Linkie",
"version": "1.0"
},
"active_mode": "none",
"is_dimmable": 1,
"is_color": 1,
"is_variable_color_temp": 1,
"light_state": {
"on_off": 1,
"mode": "normal",
"hue": 165,
"saturation": 100,
"color_temp": 2777,
"brightness": 69
},
"preferred_state": [
{
"index": 0,
"hue": 0,
"saturation": 0,
"color_temp": 2700,
"brightness": 50
},
{
"index": 1,
"hue": 0,
"saturation": 100,
"color_temp": 0,
"brightness": 100
},
{
"index": 2,
"hue": 120,
"saturation": 100,
"color_temp": 0,
"brightness": 100
},
{
"index": 3,
"hue": 240,
"saturation": 100,
"color_temp": 0,
"brightness": 100
}
],
"err_code": 0
},
{
"smartlife.iot.smartbulb.lightingservice": {
"err_code": -1,
"err_msg": "module not support"
},
"sw_ver": "1.0.3 Build 200326 Rel.082355",
"hw_ver": "2.0",
"model": "HS220(US)",
"deviceId": "8006A73C553A459F19C8C831FDDF2D871DAC6C26",
"oemId": "97D03CA037C71B6BCFAB8705E9B0C417",
"hwId": "CA321A94521D18706FC7C34CA84F99A4",
"rssi": -45,
"latitude_i": 0,
"longitude_i": 0,
"alias": "TP-LINK_Smart Dimmer_574E",
"mic_type": "IOT.SMARTPLUGSWITCH",
"feature": "TIM",
"mac": "E4:C3:2A:15:57:4E",
"updating": 0,
"led_off": 1,
"relay_state": 0,
"brightness": 100,
"on_time": 0,
"icon_hash": "",
"dev_name": "Wi-Fi Smart Dimmer",
"active_mode": "none",
"next_action": {
"type": -1
},
"preferred_state": [
{
"index": 0,
"brightness": 100
},
{
"index": 1,
"brightness": 75
},
{
"index": 2,
"brightness": 50
},
{
"index": 3,
"brightness": 25
}
],
"err_code": 0
},
{
"smartlife.iot.smartbulb.lightingservice": {
"err_code": -1,
"err_msg": "module not support"
},
"sw_ver": "1.0.3 Build 200326 Rel.082355",
"hw_ver": "2.0",
"model": "HS220(US)",
"deviceId": "800674BE957D906B765901888E2955A11DC04DF9",
"oemId": "97D03CA037C71B6BCFAB8705E9B0C417",
"hwId": "CA321A94521D18706FC7C34CA84F99A4",
"rssi": -43,
"latitude_i": 0,
"longitude_i": 0,
"alias": "TP-LINK_Smart Dimmer_F3B7",
"mic_type": "IOT.SMARTPLUGSWITCH",
"feature": "TIM",
"mac": "A4:2B:B0:2C:F3:B7",
"updating": 0,
"led_off": 0,
"relay_state": 1,
"brightness": 100,
"on_time": 2400,
"icon_hash": "",
"dev_name": "Wi-Fi Smart Dimmer",
"active_mode": "none",
"next_action": {
"type": -1
},
"preferred_state": [
{
"index": 0,
"brightness": 100
},
{
"index": 1,
"brightness": 75
},
{
"index": 2,
"brightness": 50
},
{
"index": 3,
"brightness": 25
}
],
"err_code": 0
}
] You can see the dimmers don't seem to support the long-format (at least for I'd prefer to not keep a giant table of models to check what format to send (it's fragile, and would require constant maintenance to support new devices, most of which I can't test with) but I think it might be possible to check the initial |
Here is a similar setup logged form my 3 devices: [
{
"smartlife.iot.smartbulb.lightingservice": {
"get_light_details": {
"lamp_beam_angle": 150,
"min_voltage": 110,
"max_voltage": 120,
"wattage": 10,
"incandescent_equivalent": 60,
"max_lumens": 800,
"color_rendering_index": 80,
"err_code": 0
}
},
"sw_ver": "1.8.6 Build 180809 Rel.091659",
"hw_ver": "1.0",
"model": "LB130(US)",
"description": "Smart Wi-Fi LED Bulb with Color Changing",
"alias": "livingroom",
"mic_type": "IOT.SMARTBULB",
"dev_state": "normal",
"mic_mac": "50C7BF597B46",
"deviceId": "80128B97D01975EA8D858E5C71DB60C718580CFB",
"oemId": "05BF7B3BE1675C5A6867B7A7E4C9F6F7",
"hwId": "111E35908497A05512E259BB76801E10",
"is_factory": false,
"disco_ver": "1.0",
"ctrl_protocols": {
"name": "Linkie",
"version": "1.0"
},
"light_state": {
"on_off": 0,
"dft_on_state": {
"mode": "normal",
"hue": 0,
"saturation": 0,
"color_temp": 4123,
"brightness": 100
}
},
"is_dimmable": 1,
"is_color": 1,
"is_variable_color_temp": 1,
"preferred_state": [
{
"index": 0,
"hue": 0,
"saturation": 0,
"color_temp": 2700,
"brightness": 50
},
{
"index": 1,
"hue": 0,
"saturation": 75,
"color_temp": 0,
"brightness": 100
},
{
"index": 2,
"hue": 120,
"saturation": 75,
"color_temp": 0,
"brightness": 100
},
{
"index": 3,
"hue": 240,
"saturation": 75,
"color_temp": 0,
"brightness": 100
}
],
"rssi": -37,
"active_mode": "none",
"heapsize": 291712,
"err_code": 0
},
{
"smartlife.iot.smartbulb.lightingservice": {
"err_code": -1,
"err_msg": "module not support"
},
"sw_ver": "1.5.5 Build 181204 Rel.081041",
"hw_ver": "2.0",
"mic_type": "IOT.SMARTPLUGSWITCH",
"model": "HS200(US)",
"mac": "B0:BE:76:0D:6A:33",
"dev_name": "Smart Wi-Fi Light Switch",
"alias": "Porch",
"relay_state": 0,
"on_time": 0,
"active_mode": "none",
"feature": "TIM",
"updating": 0,
"icon_hash": "",
"rssi": -53,
"led_off": 0,
"longitude_i": -1227114,
"latitude_i": 455867,
"hwId": "12657950800085A27A64E9E775C8A7A7",
"fwId": "00000000000000000000000000000000",
"deviceId": "800667FB9EF668A05A70CB63A32BE5A61AA8E1DE",
"oemId": "4748FB6E209D782A854A4B5AEDC89284",
"next_action": {
"type": -1
},
"err_code": 0
},
{
"smartlife.iot.smartbulb.lightingservice": {
"err_code": -1,
"err_msg": "module not support"
},
"sw_ver": "1.5.5 Build 181204 Rel.081041",
"hw_ver": "2.0",
"mic_type": "IOT.SMARTPLUGSWITCH",
"model": "HS200(US)",
"mac": "B0:BE:76:0D:5B:DB",
"dev_name": "Smart Wi-Fi Light Switch",
"alias": "Entryway",
"relay_state": 1,
"on_time": 168428,
"active_mode": "none",
"feature": "TIM",
"updating": 0,
"icon_hash": "",
"rssi": -46,
"led_off": 0,
"longitude_i": -1227114,
"latitude_i": 455867,
"hwId": "12657950800085A27A64E9E775C8A7A7",
"fwId": "00000000000000000000000000000000",
"deviceId": "800695D97B289CC9DD02737C4C7955F71AA9274C",
"oemId": "4748FB6E209D782A854A4B5AEDC89284",
"next_action": {
"type": -1
},
"err_code": 0
}
] As you can see, I have similar "1 supports long messages" configuration. |
I did some grepping of the decompiled Kasa Android app. It's not exact, as the kasa app sends it's commands through a cloud service to the bulbs, but often the commands are the same format. This list is probably not exhaustive list of supported commands, as it's a subset for the cloud. You can see there is a mix of long and short messages. First I looked for known commands, then looked for others around them:
I noticed a ton had @C6878c in them, so I grepped for that, which breaks it down by device-type:
|
There are 2 formats for messages, what I am calling "long" and "short" format. They seems to be kind of mixed, and support for the different types overlaps sometimes (but not always.) Like some devices support both formats for different commands, but not always. Generally "long" gives better data (more verbose, more fields, etc.)
Currently, I get around this by trying 1 format first, then if that fails, try the other format. You can see the wifi functions for an example of this, but several different functions do this sort of thing. It would be cool to detect the supported format before making a request, using the initial
info
object (like via firmware or hardware id numbers.) It would save making a failed request, so it would work a bit faster. I think it will require a bunch of captured info, so an integration-test that collects the basic info (stripping secrets), then tries both formats for all the endpoints, then saves what worked would probly help make it easier for people to collect data. At my house, I only have 3 devices, and can't see a reliable pattern of any of the data-fields, and the types of messages they work with.One idea I had is do an initial long and short message, up-front (to get info) then store which ones worked, and use that as a flag for the format of future messages.
Related: #60
The text was updated successfully, but these errors were encountered: