stefanbode / Sonoff-Tasmota

Provide ESP8266 based itead Sonoff with Web, MQTT and OTA firmware using Arduino IDE, enhanced with I2C options
GNU General Public License v3.0
126 stars 40 forks source link

Shutter position wrong #53

Closed udo1toni closed 6 years ago

udo1toni commented 6 years ago

In question of Shutter position, Wiki states that OPEN = 100 and CLOSED = 0.

There may be systems which use this Definition, but as Tasmota does also provide knx: In knx upper position of a rollershutter is always 0, while lower position is 100. This is also correct for openHAB and other well-known smarthome systems.

At least the direction should be configurable.

:)

stefanbode commented 6 years ago

I do 100% disagree. OpenHAB and homematic uses this configuration. It’s running here. Also for valves it makes sense because no flow at 0 and max flow at 100. Just switching this the other way round sounds easier than it is to code. Therefore I plan not to change it.

stefanbode commented 6 years ago

I did google a bit and for me it looks like that knx default is also 0 closed and 100 open. Could it be that you changed something. Whatever automation system I google they all agreed on the implemented definition.

udo1toni commented 6 years ago

No, knx is definitely: 100% means "100% down" When looking at the commands, a DPT1.008 0 is UP where 1 is DOWN. There is no option in knx to change this behavior. If someones shutters do it the other way, the shutter is wired the wrong way.

In question of openHAB, please take a look at the icons: rollershutter-0.png: rollershutter-0 rollershutter-100.png: rollershutter-100

This is only for blinds or something similar, please imagine the blind as "active" and "inactive". Now which position is "inactive"? I'm pretty sure the upper position is "inactive", as the blind will stop the light when closed and not stop the light when opened. It's the opposite of a dimmed lamp. :)

stefanbode commented 6 years ago

Hm, you're definitely right with the images. It looks like openhab is aware that homematic is doing it the other way around (0=close 100=open) and internally change it to the right icons. I get correctly the OPEN icon when it is on 100%. Quite interesting. Ok. let me check how I can switch direction without to much overhead.

B1G1 commented 6 years ago

@stefanbode i hope it will not change the actual behavior. I use home assistant and with template cover 100 = open 0 = closed

https://www.home-assistant.io/components/cover.template/#position_template

stefanbode commented 6 years ago

No, the default behavior will be the same, but maybe there is an INVERSE option possible, that also KNX can deal with it. I just took a look and I assume is just doing reporting with inverse and keeping all calculation as is.

udo1toni commented 6 years ago

Yes, an INVERSE option would solve the problem. Should be easy enough (just subtract the position from 100 to get the inversed value)

stefanbode commented 6 years ago

Yeah, theoretically true. But you have also check on OPEN and CLOSE and on the set50percent option and restart and the web interface with the slider....... Just more to check and test. Anyhow on the way. Maybe later today.

stefanbode commented 6 years ago

Ok, we have a new tested version that seems to do the job. Default behavior is the same. ONE important thing: In SENSOR reporting now the first shutter will report as Shutter-1 not 0 anymore. To enable the KNX behavior you have to invert every shutter that should do it. the command is "shutterinvert[index] 1". For example to invert the first shutter "shutterinvert1 1".

Have fun

udo1toni commented 6 years ago

Cool! will test next week :)

udo1toni commented 6 years ago

Tested :) and works (almost) as described.

First point is, the command is not shutter_invert 1 but shutterinvert 1, just a little typo in readme. The second point is, when setting the shutter through the wall switch, I get no shutterposition update, but have to request through cmnd/%postfix%/shutterposition.

Should I open another Issue for that?

stefanbode commented 6 years ago

There was a similar request just yesterday. Yes, this makes absolute sense. The issue was with shutteropen, shutterclose and shutterstop. Now the new position will be reported in RESULT after executing the command.

udo1toni commented 6 years ago

Cool! I hope i will have time to test this tomorrow :)

udo1toni commented 6 years ago

Hmm... I get a shutterposition update if using shutteropen, shutterclose or shutterstop, but I get no shutterposition update if switching the shutter manually. Even if using the ON/OFF Buttons in the web frontend, I get no position update. A position update should always be sent when a relay goes in OFF-Position (i.e. both relays are in OFF-Position)

stefanbode commented 6 years ago

You can use teleperiod 10 and evaluate the reported shutterposition for that. I also support momentary shutters that just need the Impuls to start moving. Therefore sending the position as a result is also strange. But let me check the code. It is well organized and the change should be only at one place. But what did you expect if during the movement a switched is pressed or an an additional command is send? Typical usecase of my wife. Change everything just in motion.

udo1toni commented 6 years ago

:) Well, funny thing is, the correct position is there, but it's not published. But of course reducing teleperiod would solve the problem :) Will try that later today.

stefanbode commented 6 years ago

Hi Udo, I uploaded a new version that will report a RESULT through MQTT whenever the motor stops with the actual position

udo1toni commented 6 years ago

I can confirm that the module does send a RESULT when the motor is stopped 👍

But... Now, when using shutteropen or shutterclose, the module does a complete restart when reaching the (virtual) end:

Let's say, the duration is 10 Seconds, and the virtual position is 50%, then when using shutterclose the module will start the motor and stop it after 5 Seconds,, but then will not be reachable, no more communication, and after 10 Seconds I get a INFO3: {"RestartReason":"Software Watchdog"}

stefanbode commented 6 years ago

Hi Udo, a restart at the end of shutterstop and or shutetrstart is definitly not a good idea. Thanks for the RestartReason. I will do some investigations and send my logs. please compare with ours and give me the difference to get an idea where it hangs

stefanbode commented 6 years ago

Hi Udo, changed the behavior and removed the RESULT stuff. Instead now introduces the TAG SHUTTER. This will be retained like the POWER and behave the same.

14:57:45 Shutter 0: Real Pos: 8700, Target 14000, source: Shutter, pos %: 0, direction: 1, rtcshutter: 88 14:57:46 Shutter 0: Real Pos: 10700, Target 14000, source: Shutter, pos %: 0, direction: 1, rtcshutter: 108 14:57:47 Shutter 0: Real Pos: 12700, Target 14000, source: Shutter, pos %: 0, direction: 1, rtcshutter: 128 14:57:47 MQT: hm/status/sonoff/SHUTTER1 = 70 (retained) 14:57:47 MQT: hm/status/sonoff/RESULT = {"POWER1":"OFF"} 14:57:47 MQT: hm/status/sonoff/POWER1 = OFF (retained)

B1G1 commented 6 years ago

Hi @stefanbode i've uploaded this new version, and I noticed a strange behavior, from position 90 I sent command shutteropen and the shutter opened, but the sonoff restarted with the RestartReason Software Watchdog and position not updated to 100.

same for shutterclose

stefanbode commented 6 years ago

Hi all, yes I can reproduce the behavior by sending the command through webconsole or mqtt. Interesting: when sending the same command through serial there is no restart. Anyhow, I have an idea where this loop came from. I use some kind of recursion.

stefanbode commented 6 years ago

Hi Bigi and all. The crash was initiated by the latest change to report shutterposition to Homeassistant. I now found the timing problem and fixed it. @udo1toni as mentioned above: To remember the last position after a reboot of HA this is something you must do at the platform level normally. Anyhow I leave in the SHUTTER1 topic to report after stopping the shutter the actual position

B1G1 commented 6 years ago

Hi, I thinks that it's perfect now! Thanks

udo1toni commented 6 years ago

Works almost perfect :) (see new Issue...)