-
Notifications
You must be signed in to change notification settings - Fork 567
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
Add debug mode to config flow #79
Conversation
@rospogrigio Did you try this out? |
I can fix the conflict btw. |
Sorry no, didn't have the time these days. Will try it soon... |
I was testing this but I get "unknown error occurred". Here are the logs:
|
Are you missing parts of the exception? |
Obviously yes, sorry, I edited the previous post. |
@rospogrigio Should be fixed now. Must have totally screwed up a rebase at some point... |
No luck @postlund , I push "+", enter LocalTuya but I get pushed back to the Integrations list, and cannot proceed. I also tried refreshing the cache, can you please check? |
Hmm, I tried it yesterday and it worked fine. No errors at all? |
Nope... |
@postlund sorry, it was my fault, I had left my main HA instance running so it could not find devices (I believe it should have left the "..." only option, though, instead of going back to the integration list without any message). 2020-10-22 12:31:49 ERROR (MainThread) [custom_components.localtuya.pytuya] [860687042462ab30b1e5] Heartbeat failed (), disconnecting Let me know... |
Yeah, I noticed that as well and have a fix. Will look at the other issue as well. |
@rospogrigio Try now. |
It worked once, but then I could not redo it, nor reload the DPs.
|
Since you get |
Nope, I have been viewing the effect with the Jinvoo app, but none of my devices has shown "single connection" needs... |
Put my phone in airplane mode and retried, with a different switch. The issues I see:
|
So, I think I figured out what was wrong. I currently do "one-shot" commands, I.e. open a connection, do something and then close the connection. At some point I changed to always re-read the values of all datapoints after doing something. So if you for instance changed a datapoint it would then re-read the values, causing two connection attempts to the device within a very short time span. It seems that there should be a grace period of a second or so between connections. I believe this is the main reason for the problems you see. Now you have to reload manually every time unfortunately. But good enough for now. I changed |
@postlund been trying this. It works, but here are my considerations:
Let me know your comments, bye! |
@postlund what do you think of my last considerations? do you want to fix those things or shall we merge? |
@rospogrigio Let me have a look at it tonight again, I'll let you know by then. |
Ok, so now I have taken a looong time thinking about this. My conclusion is that I don't want to go this road anymore as it turns the config flow into a mess. I have another idea instead that I think is better in some sense. When implementing #56, we can add all datapoints as state attribute instead. That makes them easy to copy, view and it's possible to extract datapoints and create complex templates that out sensor platforms doesn't support, etc. To handle manual change of a datapoint, we can add a service instead (e.g. |
Looks like an excellent idea, in particular if you believe it is making the config flow messy (don't want you to suffer headaches!! 😆 ). |
Yeah, the config flow changes here are a nightmare... I will close this and come back later with another PR or two. |
This PR adds a "debug mode" to the config flow. When filling in the basic info, if ticking the "Enable debug mode", the following step is presented:
From here datapoints can be changed to arbitrary values (assuming supported), so it's great to try things out. It also displays current values of all datapoints in text to make it easier to copy.
Albeit, not my finest work... I think this will be pretty great when we ask for help from our users. Thoughts?