-
-
Notifications
You must be signed in to change notification settings - Fork 26
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
Integrate native Tasmota support #29
Comments
@buenyamin-olgun Please provide details of web URL's and responses, and will evaluate. Wondering if this would be a better fit for you? |
I can't use this because I don't know how to get the current_state out of the firmware. I saw that you use a cache in your project, thought you could make use of that. Here the details: Always GET requests. Get current position (where current position 79): Response: Set target position to 75%: Response: |
I would just have it set to
Have you tried the following?
This should get you close. If that part is working, let me know I'd be willing to look into it, but it involves some more processing. We also need to consider whether the homekit values of 0-100 mirror the tasmota values of 0-100 for blind position, and if not, how to translate them in a simple and configurable way. Feel free to submit a PR as well :) |
2 would mean STOPPED, right?
This works so far.
I've tried before to replace lines 113-114 with
... but that didn't work out.
Yes, that part works. Also the mapping from 0-100 to homekit values seems to work fine. Here's my used config:
Maybe a bit off-topic but I've seen that it spams the hardware with http requests & the console log with:
Like you see above I have a basic knowledge of coding but I'm too unexperienced with HomeKit, homebridge and Node.js in general to realize such a thing on my own :/ |
Yes, but the code for this plugin also just indicates that it is stopped at certain points. There is no need for this really - HomeKit handles opening/closing states based on target/current position.
Try this version. // add these lines
try {
const json = JSON.parse(body);
body = Object.values(json)[0];
} catch (err) {
}
// unchanged part below
const pos = parseInt(body, 10);
if (pos < 0 || pos > 100) { // invalid
return callback(pos);
}
That is weird. Are you running the latest version (1.3.13)? Also, maybe something with the position_url before? It seems like it's triggering an endless loop. I recall something about that in an earlier release but I thought it should be fixed now. If it's still happening, please enable verbose would like to see how this loop happens. |
@buenyamin-olgun see this commit: Now, I added a way for you to have the position specified in the URL. Instead of 100 or 0, simply use the keyword {
"accessory": "BlindsHTTP",
"name": "Window",
"up_url": "http://192.168.0.94/cm?cmnd=ShutterPosition%20%%POS%%",
"down_url": "http://192.168.0.94/cm?cmnd=ShutterPosition%20%%POS%%",
"stop_url": "http://192.168.0.94/cm?cmnd=Power3%20ON",
"http_method": {
"method": "GET"
},
"success_codes": [
200
],
"max_http_attempts": 5,
"retry_delay": 2000,
"use_same_url_for_stop": false,
"show_stop_button": true,
"show_toggle_button": false,
"motion_time": 20000,
"response_lag": 0,
"trigger_stop_at_boundaries": false,
"verbose": false
} |
I've just committed a fix for that issue, I think. I didn't have a way of testing it before, so I appreciate the fact that you have a way to test it. Please replace your https://raw.githubusercontent.com/zwerch/homebridge-blinds/master/index.js Also, make the changes as I mentioned to add |
After downloading the new version & changing the config.json there's this error (& it's again looping):
|
Missed that one. Try again: https://raw.githubusercontent.com/zwerch/homebridge-blinds/master/index.js |
OK, I think I know the cause. Try again: https://raw.githubusercontent.com/zwerch/homebridge-blinds/master/index.js |
|
Btw, have made one other batch of changes I'm hoping will fix it. https://raw.githubusercontent.com/zwerch/homebridge-blinds/master/index.js |
Your last change seems to fix the loop issue, thank you! To point 4: im using it to stop the blinds accuractely when I want instead of using a percentage value because percentage values are kinda hard to guess. Hopefully the last couple of problems:
Case Stop Button used via Home App:
Blind position changed via physical buttons (blinds are at position 63%, Home app shows 75%):
|
@buenyamin-olgun thanks for your testing and reports.
I've pushed a number of changes that I'm hoping will address at least the majority of your issues. Would be grateful for you to test it as I have no practical way to do so since my blinds don't work like this. I've also added a feature to disable sending the stop command when a value is provided. To me, this makes intuitive sense -- if your blinds can receive a value to target, there should be no reason that we need to also send a stop command for intermediate values. (Note: the stop 'button' still works). https://raw.githubusercontent.com/zwerch/homebridge-blinds/master/index.js
The problem is: the blinds only have knowledge of the position from the Therefore, I modified the behavior as follows. The motion time is used as an internal estimate. Once this "estimate" is reached, it will poll the position_url to update the blind's position. If the desired position is reached, it will end the motion. However, if the desired position is not reached it will keep waiting and retrying again using similar estimates. The goal is that it should not be polling for current position so frequently. The icon may be very slightly out of sync, but I think it should be quite close if you're using the correct motion time for your blinds. |
Sorry for the delay, had working hours of nonstop +1 day. First everything seemed to be okay, what I did was: Took the blind, set it to a lower position and stopped the blinds with the stop button. After that I tried to move the blinds up, it spammed me and the device again with values. The device crashed and restarted so I'm not sure which commands were spammed. Here's the full log:
|
Thanks @buenyamin-olgun. Pushed a few more commits. Originally, you wrote:
But, in some cases, your blinds are returning multiple values for the {"POWER3":"OFF","POWER1":"ON","ShutterPosition1":0} That was causing an issue. For now, I just filter to return only the numeric values. More robust handling probably needs to be added at some point. In your case, there is only one so hopefully it will resolve the issue. |
Thank you for your further fixes. Forgot to mention that the endpoint is reporting ShutterPosition1 = 0 during movement and also while it is really fully closed. Already opened an issue on tasmota for this. The 0 value (completely closed) seems to be problem for your plugin:
Homebridge Log:
and updating the estimated value by the correct one by closing and reopening the Home App also does not work (real value: 6%; set value via Home App: 7%):
|
This is a problem. The only way to proceed from here (maybe) would be some additional JSON parsing... IF... we can guarantee that the POWER values would also be reported in that timeframe.
Fixed.
I'm not sure what you mean here? Anyway, it is likely related to the |
Hopefully tasmota devs will fix it soon.
Thanks!
I don't think that it is related to the upper issue since you can see that ShutterPosition1 was reporting 6 at that time but your plugin cached / estimated (?) 7. |
In anticipation of this, I added some JSONata handling of the result. You will have to run
Can you clearly explain which commands you pressed on your blinds to initiate this? It's not clear to me how it happened. Also, the 0% response from Tasmota is definitely causing a problem. I would suggest increasing motion time / lag time a little bit so that the blinds are never checking while the blinds are in motion. That being said, this could be a major issue if the position is requested by HomeKit itself while the blinds are moving. |
Wow, this time it worked incredibly well until the point where it started looping again :( :
|
There is some issue with the Tasmota or the positions being specified. When you are requesting 12% from HomeKit, it is sending a request for 12% but stopping at 11%. So, the code is looping waiting for the blinds to hit 12%. I noticed something similar earlier. |
I'll do further tests regarding this problem (but it'll take some time since I will be away from home for a short period). |
@buenyamin-olgun no problem. I pushed a new commit that sets an upper bound on the number of retries (in case of this type of failure, it won't loop forever). Also, is it always off by 1 or does it sometimes look equal to the target? If it's always off by 1, this could be resolved by setting You can experiment more with JSONata using their playground. |
It seems to be off by one, couldn't detect any other off-value. Seems like it is doing this in both ways (up & down). I've opened a issue on tasmota for this as well. While moving it reports 0, this causes an issue right now (shows the blinds closed and doesn't revert after it was stopped). Let's wait for the reply on this tasmota issue. Thank you very much so far! |
In this case, my suggestion could work fine. You just adjust the value by 1 using the jsonata. |
Btw, have pushed several more commits to account for some other cases. Will be grateful if you're able to test with your setup and just be sure there are no differences. |
Thank you. The problem is that tasmota reports 0 during movement which makes it hard to test things. Right now your code sets the shutter-value correctly to closed if shutterposition is 0 during a movement but doesn't gets updated afterwards:
I think we'll have to wait for this issue be fixed on tasmota side. |
Sure, np. |
@buenyamin-olgun any progress on this? I was wondering if (at least part?) of your issue is Tasmota calibration.
This all being said, I think perhaps MQTT would be a superior way to interact with Tasmota. You can use https://github.com/arachnetech/homebridge-mqttthing#window-covering
|
@dxdc Was away until today, had to do work so didn't had any time yet. The major issue that it was not reporting its current position should be fixed now, the devs pushed a commit 2 days ago: arendst/Tasmota#7785 I'm waiting that a final version gets released. 1.) Yes, the shutter is calibrated with the provided instructions by tasmota. 2.) Yes, currently it is running the latest version (8.1). 3.) On my device I have a separate stop button (Power 3) which I was using. This was set to the same function as ShutterStop by using the rule:
During tests I already silently swapped Power3 by ShutterStop, didn't make any difference. I agree with you that MQTT would be a superior way to interact with the device but unfortunately I don't have any infrastructure right now and it would be one more item in the chain to the device which I'm trying to avoid. Your plugin seems to work well so far, when the tasmota devs publishes their changes as a release I think it could work out well how it is right now. Waiting for that. |
Great news @buenyamin-olgun, and thanks for the explanation. |
Hi @buenyamin-olgun have you had a chance to upgrade to the latest Tasmota release? |
@buenyamin-olgun you may also be interested in the feature I added that lets you update the blinds position manually (on a one-time basis) via webhook. See discussion #30 here |
Just found out through your post that the new version has been released, thanks for that! The position_url parameter would imho be more suitable for my situation if tasmota sends correct values. But will look into it if tasmota starts again to make trouble. Did I say thank you? Oh, just six times. but one more can't hurt: THANK YOU FOR YOUR GREAT WORK! |
Quite welcome... cheers :) Keep me posted and close the issue (or comment) once you finish testing on your side. |
Tested it now with Tasmota 8.2.0 for about half an hour, seems to work fine so far! |
Great! Thanks for the feedback. |
Hey,
first of all: thank you for your very nice plugin!
Would it be possible for you to implement this plugin "the tasmota way"? Could support you if it is necessary with all the details.
Main differences between it and your plugin:
Thank you.
Kind Regards
The text was updated successfully, but these errors were encountered: