New device Kingart king-q4

[seea2005]

trafficstars

Can you please add support for cover switchs? Ewelink recognizes them as Kingart king-q4. With open, close, stop and percentage if possible, like Tuya devices do. Thanks!

[2016for]

It would be really helpful if you could also send a devices.json dump from sonoff-debug.py

On Sun, Jan 20, 2019 at 3:09 AM seea2005 [email protected] wrote:

Can you please add support for cover switchs? Ewelink recognizes them as Kingart king-q4. With open, close, stop and percentage if possible, like Tuya devices do. Thanks!

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/peterbuga/HASS-sonoff-ewelink/issues/44, or mute the thread https://github.com/notifications/unsubscribe-auth/AqJgbMb6y_CHWVdgyw3Z_h8Jj_gNykf1ks5vE5CHgaJpZM4aJWJl .

[peterbuga]

as @2016for mentioned above without the info provided with this script https://github.com/peterbuga/HASS-sonoff-ewelink/tree/master/sonoff-debug i cannot add support for any new devices. let me know if you have problems with the script ;)

[seea2005]

https://paste.ubuntu.com/p/7Zpb5PT4DB/

[peterbuga]

@seea2005 thanks for data. unfortunately i'm having a bit of a hard time linking this data to the requested values mentioned above: "open, close, stop and percentage if possible"

what i'm trying to say is that the dump looks exactly like a Sonoff Basic and you should be able to toggle it on & off right now.

any other information on how this device works might be of help, maybe even a screenshot from eWeLink app to see how it's displayed there.

[seea2005]

The device has three buttons, open, close and stop. When you install it, you have to close completely, and then open to let the device knows how many time the motor takes to open it completely, so it has a timer inside.

I think the device knows how opened or closed is by the time has happened, so just a number between 0 (opened) and 100 (closed) is needed maybe... don't know really...

The screenshot I attach is completely closed. I'll send a debug and another image half opened to let you see how it works.

Thanks for all!!

[seea2005]

Maybe the parameter setclose on 0 as open, setclose on 100 as close, switch off as stop, and something like ewelink to set the position (setclose on 24, 32, 25...)

Partially opened https://paste.ubuntu.com/p/zpFvr3bx6n/

Completely opened https://paste.ubuntu.com/p/CxvqHwTp9R/

[peterbuga]

i see it now, there's a new value in the dump "setclose": 100, and accordingly with the mentioned details above i think this might represent the state. i do have one more question right now: does anything happens right now when you turn ON/OFF the switch in HA? do you get an OPEN / CLOSE buttons effect? meanwhile, i have really no idea what is the signal for STOP (button) 😅 ... i'll probably figure it out eventually

[seea2005]

Maybe the parameter setclose on 0 as open, setclose on 100 as close, switch off as stop, and something like ewelink to set the position (setclose on 24, 32, 25...)

Right now ON means open till the end, and OFF close till the end.

Maybe something like that but mor simply, just up down stop and a scroll: https://community.home-assistant.io/t/sonoff-dual-window-cover-with-set-position/50503

[seea2005]

This one is right opening https://paste.ubuntu.com/p/NPk33xMNW7/

[seea2005]

And that one is closing https://paste.ubuntu.com/p/BNQN2gKrCF/

[seea2005]

I think this works like I told before.

• Open: setclose = 0
• Close: setclose = 100
• Stop: switch = Off
• Partially: setclose = scroll?

Would be great a state function, a different icon for each state, one for setclose = 0, another for setclose=100 and another one for 0<setclose<100. 🤣

[peterbuga]

I'm not sure it's just that easy (hint: from experience it never is 😅) but i'm sure there's some kind of combination between setclose + switch values. nevertheless we'll figure it out ;)

[seea2005]

I've checked it again and I agree with you, it isn't so easy. The order to open and close is just switch on and off respectively, set the target position with setclose, but the stop order is the hard thing, I can't see any way to send this order...

[2016for]

@peterbuga I think I have seen this more than once where you would require a command from sonoff-debug.py for integrating things however it was not possible to create appropriate json (because maybe it's just a small websocket message sent, rather than persistent state json)

Like in this case maybe the stop/pause action just sends a pulse/message to pause the action.

I think we should be able to capture this within HA component, by enabling debug, and you modifying files a little bit to show the message received and the tester can then send that message to you.

I think I did something similar in the initial stages of devp of the component

Thanks

On Tue, Jan 22, 2019 at 1:51 AM seea2005 [email protected] wrote:

I've checked it again and I agree with you, it isn't so easy. The order to open and close is just switch on and off respectively, set the target position with setclose, but the stop order is the hard thing, I can't see any way to send this order...

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/peterbuga/HASS-sonoff-ewelink/issues/44#issuecomment-456189511, or mute the thread https://github.com/notifications/unsubscribe-auth/AqJgbK30emC4fn9ARF6m1t0EoJFC0MT7ks5vFiFagaJpZM4aJWJl .

[seea2005]

I activated debugging mode (debug in logger), and I can't get any information about that as I just get the state, friendly_name and device_id by default. Is there any other change I have to do in my config to get this info?

[peterbuga]

@2016for i never captured the websocket messages (but i'm thinking to do it in order to better integrate the Sonoff Bridge) the problem is that the broadcasted (received) messages might not always be the same as the ones that the app is sending and sort of throws me off a bit (i have to dig in the ewelink app code and hopefully reverse engineer what is getting sent)

@seea2005 right now there's no extra debugging to be done, as i mentioned above i might add new features. i never imagined i would go this far in integrating new devices so i skipped this part (mostly because it involves extra steps from 3rd party persons and i wasn't sure people were actually willing to help :blush:)

[2016for]

@peterbuga, great. That's what I wanted to target. I mean tester goes to logger on HA, performs the action on the device, we see whatever websocket message that is sent to the server (hopefully the websocket message within seconds of performing the action will be the message that triggered the action), and then try to figure out that websocket message. Just like how you figured out what devices and what parameters are there for each device using a devices.json file.

On Tue, Jan 22, 2019 at 2:43 PM Peter Buga [email protected] wrote:

@2016for https://github.com/2016for i never captured the websocket messages (but i'm thinking to do it in order to better integrate the Sonoff Bridge) the problem is that the broadcasted (received) messages might not always be the same as the ones that the app is sending and sort of throws me off a bit (i have to dig in the ewelink app code and hopefully reverse engineer what is getting sent)

@seea2005 https://github.com/seea2005 right now there's no extra debugging to be done, as i mentioned above i might add new features. i never imagined i would go this far in integrating new devices so i skipped this part (mostly because it involves extra steps from 3rd party persons and i wasn't sure people were actually willing to help 😊)

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/peterbuga/HASS-sonoff-ewelink/issues/44#issuecomment-456325025, or mute the thread https://github.com/notifications/unsubscribe-auth/AqJgbASaHN5HgpSfNSaLiwoSfB9309DCks5vFtYxgaJpZM4aJWJl .

[seea2005]

Good news! Don't know really how I got it, but I got this from sonoff-debug:

https://paste.ubuntu.com/p/ndHTm3M5fZ/

So:

• Open: switch= on
• Close: switch = off
• Stop: switch = pause
• Partially: setclose = scroll? + switch on/off depending if the new value is higher or lower maybe?

[seea2005]

Or better:

• open_cover -> switch= on
• close_cover -> switch = off
• stop_cover -> switch = pause
• position_template = setclose
• set_cover_position -> scroll with setclose and maybe switch on/off depending if the new value is higher or lower?

[peterbuga]

@seea2005 with all this info it starts to make some meaning 👍

in the same time i added the advance(-r) option to log what is happening, here are the instructions:

1. update the files from the new websocket-debug branch
2. add a new option to the sonoff part in configuration.yaml -> debug: True
3. (optional) change the scan_interval option to 10 or 20 sec
4. (optional) it will be better if you could use a 2nd eWeLink account where'd you share only 1 device that you want to analyse (this way the log will be easier to read but i'll take anything otherwise) + you will be able to change stuff from inside eWeLink app with the original account and send better data to the log (otherwise the "grace period" kicks in)
5. restart HA to start generating the log (on every restart the log gets cleared)
6. leave it like 5-10 minutes running, turn on/off the device be it from HA or eWelink app, in the case of plugs with power meters (and alike) connect some devices to it too
7. a new file sonoff_debug.log will be created in the root of your config folder (where there is also configuration.yaml, custom_components folder etc) save it and post it somewhere, DM to me or anything else. but please do not post the outputs here as it might be quite big!
8. set option debug: False or just remove it & restart HA to get back to normal usage

one important thing to mention: most of the important data is still obfuscated and I cannot trace (or control) anything form my side (feel free to double check it) and also the the deviceid is NOT hidden anymore BUT instead it's an obfuscated-hash value because i need to know which-device-received-what if more of them are in the logs

@seea2005 in your particular device case it would be better if you could follow the 3. and 4. steps too. the more data the better for me 😄

[seea2005]

@peterbuga Thats what I get in the debug with the actions the device do from ewelink.

Close 2019-01-27 22:06:10.192 [W] {"action": "update", "apikey": "xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx", "deviceid": "xxx", "params": {"switch": "off"}, "sequence": "1548623170126", "ts": 0, "userAgent": "app"}

Stop 2019-01-27 22:06:12.990 [W] {"action": "update", "apikey": "xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx", "deviceid": "xxx", "params": {"switch": "pause"}, "sequence": "1548623172878", "ts": 0, "userAgent": "app"}

Open 2019-01-27 22:06:14.996 [W] {"action": "update", "apikey": "xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx", "deviceid": "xxx", "params": {"switch": "on"}, "sequence": "1548623175038", "ts": 0, "userAgent": "app"}

Set Position 2019-01-27 22:13:58.802 [W] {"action": "update", "apikey": "xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx", "deviceid": "xxx", "params": {"setclose": 75}, "sequence": "1548623638715", "ts": 0, "userAgent": "app"}

I don't post all the debug because it's so large... if you need anything else let me know

[peterbuga]

@seea2005 that's really good! thanks for the output (to be frank the log file is huge because i was trying to capture the sensor states for another and see their data between websocket messages and poll-ing data, in the end more information never hurts 😅)

now that we know for sure there's a "pause" action, i just have to figure how to represent all these actions in HA (still learning it :D). are you planning to control this device from HA frontend or just script-automate it?

[seea2005]

I'm planning to control it from HA, and do some scripts as well 😄

[seea2005]

Hi! Any news? Have you found anything about it?

[peterbuga]

No new news :( didn't work on this component lately.

[seea2005]

Is there anything I can do to help you? I'll take a look to the code

[2016for]

@peterbuga I think till the time we can figure out how to register different type of entities in HA, why not create a service, where we can define the websocket message we want to send?

Like in the services you we can create a service sonoff.send_command, select deviceid and then add the json parameters to be sent in the [switch] key.

This could be a good workaround. (I mean it seems like you have the API figured quite a lot especially after the debug file where we capture the websocket messages. The only hiccup seems to be learning more about HA on how to add different kinds of devices)

What do you think?

Thanks again for the amazing work so far!

[2016for]

This could also increase stability for those of us who want to send Turn On/Off ALL outlets in a device (by decreasing the number of spontaneous websocket messages) JSON for All outlets can be sent via just a single websocket message.

[peterbuga]

@2016for this idea cross my mind several times, but i have to (and God forgive me i hate to do it!) write documentation for it too :grimacing::sweat_smile: it's somehow easy for switch entities but things get a bit more complicated on other devices and i somehow prefer to implement it vs. explaining it (in case you didn't realise/noticed some people aren't even able to follow simple instructions of copy-pasting 3 files to install this component and this will just complicate things further, more questions etc :weary: for people looking to automate things further but have no idea what they are doing.)

[2016for]

Haha @peterbuga makes complete sense. Completely understand. Have been trying to scavenge through Docs to figure out how to create a service. But it's above my IQ. :P

Still would love to see this in the future. Maybe a dev branch with Disclaimer: No support would be provided. Only for Devs.? :P

Anyway, Love the work and support so far!