Actual Positions - Githubissues

AdminMBL commented 2 years ago

Hi, happy that you are currently updating the plug in. Have you considered also to work on the actual positions of shutters? eg in my case bigger/longer shutters get a very decent position back from the motor, which you can also see in the Homekit App(eg 61%). Smaller/shorter window shutters do not get a decent position. Therefore the intermediate position do not work perfectly. I can only stop the window shutters via Homekit when I set the opening time to 20(!) ms. It works here & there, but not reliable. Any clue if the stick can proceed different motors, with different positions? Kind regards Markus

AdminMBL commented 2 years ago

Changing the channel did not bring other results. What I got so far is the "check result" on several occasions.

[26/09/2022, 15:31:02] [EleroStick] Updating reportingInterval for channel 3 to 9000
[26/09/2022, 15:31:02] [EleroStick] [3] Wohnzimmer CLOSING [46.009415054197106]
[26/09/2022, 15:31:02] [EleroStick] [3][Wohnzimmer] Reported motor state MOVING_DOWN
[26/09/2022, 15:31:02] [EleroStick] [3][Wohnzimmer] Updating currentPositionState: DECREASING
[26/09/2022, 15:31:02] [EleroStick] [3][Wohnzimmer] Updating lastPosition: 45.07582005833586
[26/09/2022, 15:31:02] [EleroStick] Checking channel 3 every 9000 ms. Now at 45.07582005833586, moving to 79. Check result is true
[26/09/2022, 15:31:02] [EleroStick] [3][Wohnzimmer] Updating currentTargetPosition: 79
[26/09/2022, 15:31:02] [EleroStick] [3][Wohnzimmer] Updating lastPosition: 45.07582005833586
[26/09/2022, 15:31:02] [EleroStick] [3][Wohnzimmer] Updating currentPositionState: DECREASING
[26/09/2022, 15:31:02] [EleroStick] [3][Wohnzimmer] Setting lastPosition:  45.07582005833586
[26/09/2022, 15:31:02] [EleroStick] Updating reportingInterval for channel 3 to 9000
[26/09/2022, 15:31:02] [EleroStick] [3] Wohnzimmer CLOSING [45.07582005833586]
[26/09/2022, 15:31:02] [EleroStick] [3][Wohnzimmer] Reported motor state STOP_UNDEFINED_POS
[26/09/2022, 15:31:02] [EleroStick] [3][Wohnzimmer] Updating currentTargetPosition: 45.07582005833586
[26/09/2022, 15:31:02] [EleroStick] [3][Wohnzimmer] Updating lastPosition: 45.07582005833586
[26/09/2022, 15:31:02] [EleroStick] [3][Wohnzimmer] Updating currentPositionState: STOPPED
[26/09/2022, 15:31:02] [EleroStick] [3][Wohnzimmer] Setting lastPosition:  45.07582005833586

[26/09/2022, 15:32:18] [EleroStick] Updating reportingInterval for channel 1 to 9000
[26/09/2022, 15:32:19] [EleroStick] [2][Arbeitszimmer] Reported motor state MOVING_DOWN
[26/09/2022, 15:32:19] [EleroStick] [2][Arbeitszimmer] Updating currentPositionState: DECREASING
[26/09/2022, 15:32:19] [EleroStick] [2][Arbeitszimmer] Updating lastPosition: 0
[26/09/2022, 15:32:19] [EleroStick] Checking channel 2 every 9000 ms. Now at 0, moving to 66.19222053984801. Check result is false
[26/09/2022, 15:32:19] [EleroStick] [2][Arbeitszimmer] Updating currentTargetPosition: 66.19222053984801
[26/09/2022, 15:32:19] [EleroStick] [2][Arbeitszimmer] Updating lastPosition: 0
[26/09/2022, 15:32:19] [EleroStick] [2][Arbeitszimmer] Updating currentPositionState: DECREASING
[26/09/2022, 15:32:19] [EleroStick] [2][Arbeitszimmer] Setting lastPosition:  0

CH3 was moving to an intermediate position (45%), where CH2 was closing to full extend, altough I set it to 66%.

ma-ku commented 2 years ago

I am wondering why you go with 9000 as movingInterval since this decreases the granularity of the reporting and thus leads to major deviations between the value in HomeKit and the real opening. The diagram below describes the general functionality of the plugin with regards to the communication with the stick and the learned motors:

The picture below shows the scenario where one motor is starts moving and is stopped (via a manual remote) and how that affects the monitoring behavior of the plugin:

A few things are important to understand:

The sendInterval shall not be shorter than the time the stick requires to process the command without loosing eventual return data
The movingInterval shall not be less than #Channels times the sendInterval as otherwise the message queue containing the commands to be sent to the stick would get filled faster than it gets drained by the sending logic.
The same constraint applies to the defaultInterval but typically it should be moderate to not overload the general processing logic of the HomeBridge server. The longer the defaultInterval get, the worse the estimated shutter positions become. As shown in the diagram above, the measured running time could vary by the defaultInterval which depending on the total running time of the shutter could lead to significant differences. E.g. 30000ms total running time and a 9000ms default interval would mean that the deviation could be almost 30% from the actual position.

In my environment the sendInterval of 250ms works fine. If it is less, it becomes unreliable. I use 1500ms as movingInterval which seems to be acceptable with seven motors (7 * 250ms = 1750ms) but eventually the lower margin of the sendInterval is 200ms but I never tested that into such detail. The defaultInterval is still 5000ms which means that manually triggered motions are not so well tracked but since we are barely moving the shutters by the remote, this seems to be OK.

AdminMBL commented 2 years ago

Thank you again for the valuable info. I tried exactly the same config (sendInterval 250ms, movingInterval 1.250ms (5 motors), defaultInterval 5000ms). Result: no response (motor state) from Channel 0-3. By changing a bit ((sendInterval 1500ms, movingInterval 7500ms (5 motors), defaultInterval 9000ms) I do get all responses and a almost perfect setup. Key was definitly the multiple of motors. I do not know why 250ms is not working, but anyway I get very good results. Do you plan to integrate the possibilities (eg sendInterval) into the Alpha version of the plug in & UI? KR Markus

ma-ku commented 2 years ago

I do not know if there is a significant difference in the communication layer of different transmitter sticks?! If this is working for you, I am more than happy. As explained, these numbers introduce some deficiencies as the accuracy of the position calculation is diminishing the longer the movingInterval gets.

What hardware do you use for the HomeBridge setup and if different, which hardware is used to control the emitter stick?

Regarding the version; I will fix two things in the UI (namely stupid leftover texts) and then I can make it a release.

ma-ku commented 2 years ago

Just published version 1.4.0 on npmjs.org

AdminMBL commented 2 years ago

Hardware: Raspi 4 32GB
Stick: Raspi USB Would it be possible to integrate SendInterval into UI? Thx!

ma-ku commented 2 years ago

Reasonable hardware. Don't know why the latency is so high?!

However, the new version 1.4.1 contains the sendInterval in the UI.

github-actions[bot] commented 1 year ago

As there has not been any response in 21 days, this issue has been automatically marked as stale. At OP: Please either close this issue or keep it active It will be closed in 7 days if no further activity occurs.

github-actions[bot] commented 1 year ago

As there has not been any response in 28 days, this issue will be closed. @ OP: If this issue is solved post what fixed it for you. If it is not solved, request to get this opened again.

ma-ku / homebridge-elero-stick

Actual Positions #7