Closed udo1toni closed 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.
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.
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-100.png:
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. :)
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.
@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
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.
Yes, an INVERSE option would solve the problem. Should be easy enough (just subtract the position from 100 to get the inversed value)
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.
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
Cool! will test next week :)
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?
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.
Cool! I hope i will have time to test this tomorrow :)
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)
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.
:) 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.
Hi Udo, I uploaded a new version that will report a RESULT through MQTT whenever the motor stops with the actual position
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"}
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
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)
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
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.
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
Hi, I thinks that it's perfect now! Thanks
Works almost perfect :) (see new Issue...)
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.
:)