ma-ku / homebridge-elero-stick

Homebridge plugin supporting control of Elero Motors
MIT License
11 stars 1 forks source link

Actual Positions #7

Closed AdminMBL closed 1 year ago

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

ma-ku commented 2 years ago

Well,

this is a pain. I always considered having some algorithm that allows me to compute the actual coverage of the roller shutter, taking into account that before the cover is actually lifted, it needs to pull the pieces of the shutter apart before it actually moves. But the true issue here is that the elero stick does not support the necessary frequency to retrieve the information about the shutter movement. Since it is not directly connected with the motor, it needs to pull the data via the wireless connection and apparently there is a limitation in the maximum frequency we could use. In this case it is somewhere around 1.5 seconds. I currently have about nine motors paired with the transmitter and this seems to reduce the frequency again. Another side effect of this is that sending of commands seems to be limited as well. I realized that the monitoring function that controls when to stop the shutter (converting movement time into closing % and comparing that with the target value) issues a stop command to the motor but this command not always makes its way to the motor and thus the motor keeps running. I have one shutter connected via the Homematic Shutter Actor which apparently does the math onboard and this is way more reliable than I could eve be with the unreliable and lagging communication between the motors and the stick.

Probably it makes sense to get in touch with Elero to get more insight into the capabilities of the stick to improve the behavior. For now, I am facing the same challenges as you.

Greetings Mathias

ma-ku commented 2 years ago

Finally I found a tiny but important glitch that prevented the motors to stop immediately. While everything above still applies, this change makes a difference. Please check version 1.2.0 of the plugin. It should give some relief on this subject.

AdminMBL commented 2 years ago

Hi, perfect as always. For my bigger/longer shutters it is working now extremely accurate. You can now shift from one intermediate to another intermediate position. For the smaller/shorter shutters (eg window) it seems strange. You can see the actual position eg in the Eve App (small white stripe). This seems accurate for the longer shutters, but for the shorter ones the position marker (white stripe) seems in every case very near to „close“ (eg 98%). I think that is the case, why I can not achieve any intermediate position. Only open or close is possible. Do you see any options for the actual positions? KR & Danke Markus

ma-ku commented 2 years ago

Try changing the setting Polling time while moving (ms) to something smaller than 1500. The limitation is the response time from the elero stick. If the shutter is moving fast, the interval of 1500ms is eventually already too large. The interval is currently limited to a minimum of 0.5 seconds (500ms) which I believe should be ok. Give it a try and let me know if that helped. If needed, we can also eliminate the minimum time so you can go below 500ms but first check what you can achieve with the existing bounds.

ma-ku commented 2 years ago

I guess what you want to achieve with the 98% is a kind of ventilation position. That is supported by the elero motors but at least for the moment I cannot address this as I do not know how to implement this since it would be something like a push button in the Home app. See #4 for details. Technically you could program these positions (in the manual it is called Ventilationsposition and Tuchspannung) and would be reached by pressing up or down twice.

AdminMBL commented 2 years ago

Hi, the 98% (closed) is the position which I see in the Eve App as current position, even if the shutter is open. If I shift now the position in Homekit/Eve between 0-98 nothing happens. I just tested 500ms polling time while moving. For the longer shutters it is now not possible to go to 50%, as it is stopping to fast. The shorter seems not to react differently. Probably it is possible to set the polling time per motor? I would tweak around then… thx!

ma-ku commented 2 years ago

OK, understood. I had a threshold in the plugin that 'snapped' everything below 10% to 0% and above 90% to 100% but removed that recently. Maybe I should put that back in?! If the motor moves to the end position (either top or bottom), the motor reports these special positions and the plugin will then switch to 0% or 100%. Anything else is just reported as intermediate position without percentage. So the both end positions serve as fix points to calibrate the plugin. So the only reason for the plugin to stay with 98% is that the motor reports something different.

ma-ku commented 2 years ago

Please check version 1.3.0 of the plugin. This has a much finer control over the motor movements. It reduced the lower bounds for the polling intervals. In addition it allows to compensate for motors with a acceleration that basically waste time before coming up to speed. Maybe this gives you more flexibility for your setup?

AdminMBL commented 2 years ago

Hi, it‘s getter better and better. Amazing. 3 out of 5 I can control. But 2 still behave strange. Is there kind of an internal counter per motor which I could reset? Altough I have 3 similar motors, only 1 can controlled, the other 2 have the same issue of the „position“ which is always near to close. Even I would stop the motor with eve app by 50%, the app thinks the motor is nearly closed. Therefore I was thinking of the internal counter (=position estimation). KR Markus

AdminMBL commented 2 years ago

Edit: where I do fail at the moment is, that I let my window shutters stop somewhere between open & close (eg when the sun is shinning). I would not mind if it is 30% or 60%. Probably there is a possibility instead of the mathematical operation, to key in ms or seconds per motor for a stop signal (simple timer). Just as an option. The idea is, if you have an open shutter its just counting. You would not achieve any other intermediate until total open, total close and 1 intermediate (calculated by seconds) . KR Markus

ma-ku commented 2 years ago

I believe the issue is not if the system is counting or calculating percentages. The true issue is that the system needs to get attention of movements once they start. Since the communication from the motors to the receiver is not a push communication that is then propagated to any software, the software needs to pull the information. The frequency of that operation is what makes the difference in that case.

Question: How 'long' are these shutters? Are we talking about something shorter than a meter?

ma-ku commented 2 years ago

Regarding any changes to the calculation of the positions; since Homebridge is about connecting arbitrary devices to HomeKit, we need to play by its rules. This means that shutters positions are expressed as percent and we will get no other data for this. The same applies for alternative functions; Elero supports additional positions such as fabric tension and ventilation position. These could be addressed by the stick but for now I do not know any way to express this so that HomeKit would give the user an appropriate user interface to control the feature. And this kind of also relates to your request for counters.

AdminMBL commented 2 years ago

Hi, I have normal Window shutters (app 1,25m) where the plug in is not working while with my terrace door shutters (app 2,1m) working fine. By testing intensivly I have the feeling that these shutters, where i defined certain limits (with the add motors function) have kind of a dependency to each other. If one is functioning acceptable, the other is going worse. Current status: Homekit says „opening“ constantly without coming ever to „open“, therefore it is not possible to close the shutters at all. The terrace door shutters do not have specific parameters & working proberly. I do not know if it is possible to adress 0x44 Intermediate position with a switch in Homekit. KR Markus

ma-ku commented 2 years ago

Hmm. Same here and the algorithm is pretty accurate. Did you check if the channels are unidirectional or bidirectional? Sometimes you can end up in unidirectional mode which certainly does not give information about the motor state.

Read the documentation, there is some way to determine the directionality. Something about the way the lights are blinking…

AdminMBL commented 2 years ago

Hi, should be bidirectional (DIP switch correct, Lights Red/Green). The stick is anyway bidirectional only. I found the main issue, why the shutters where not moving at all: Polling time: 1500 Polling time while moving shut down a bit. I set Polling time to 5000 and it is working. What I do not get is any info of the window shutters, if they are open or closed. Will find out the motor type to check if they are capable of bidirectional mode. KR Markus

ma-ku commented 2 years ago

I will tell you a secret; turn on debugging in Homebridge and then add the following setting to the Elero platform config: "debugSerial": true, This will give you maximum insight into what is happening between the plugin and the receiver. Maybe this helps you getting behind this?!

AdminMBL commented 2 years ago

[12/09/2022, 20:55:31] [EleroStick] easyInfo [ 0, 1, 2, 3, 4 ] [12/09/2022, 20:55:31] [EleroStick] Received data from elero stick: � [12/09/2022, 20:55:31] [EleroStick] Received data from elero stick: M [12/09/2022, 20:55:31] [EleroStick] Serial port data received [12/09/2022, 20:55:31] [EleroStick] Incoming data [12/09/2022, 20:55:31] [EleroStick] [0] Updating currentTargetPosition: 0 [12/09/2022, 20:55:31] [EleroStick] [0][Channel 0] Updating lastPosition: 0 [12/09/2022, 20:55:31] [EleroStick] [0] Updating currentPositionState: 2 [12/09/2022, 20:55:31] [EleroStick] [0] Setting lastPosition: 0 [12/09/2022, 20:55:31] [EleroStick] Updating reportingInterval for channel 0 to 5000 [12/09/2022, 20:55:32] [EleroStick] Received data from elero stick: �M [12/09/2022, 20:55:32] [EleroStick] Received data from elero stick: [12/09/2022, 20:55:32] [EleroStick] Serial port data received [12/09/2022, 20:55:32] [EleroStick] Incoming data [12/09/2022, 20:55:32] [EleroStick] [1] Updating currentTargetPosition: 0 [12/09/2022, 20:55:32] [EleroStick] [1][Channel 1] Updating lastPosition: 0 [12/09/2022, 20:55:32] [EleroStick] [1] Updating currentPositionState: 2 [12/09/2022, 20:55:32] [EleroStick] [1] Setting lastPosition: 0 [12/09/2022, 20:55:32] [EleroStick] Updating reportingInterval for channel 1 to 5000 [12/09/2022, 20:55:32] [EleroStick] Received data from elero stick: �M� [12/09/2022, 20:55:32] [EleroStick] Serial port data received [12/09/2022, 20:55:32] [EleroStick] Incoming data [12/09/2022, 20:55:32] [EleroStick] [3] Updating currentTargetPosition: 0 [12/09/2022, 20:55:32] [EleroStick] [3][Channel 3] Updating lastPosition: 0 [12/09/2022, 20:55:32] [EleroStick] [3] Updating currentPositionState: 2 [12/09/2022, 20:55:32] [EleroStick] [3] Setting lastPosition: 0 [12/09/2022, 20:55:32] [EleroStick] Updating reportingInterval for channel 3 to 5000 [12/09/2022, 20:55:32] [EleroStick] Received data from elero stick: �M � [12/09/2022, 20:55:32] [EleroStick] Serial port data received [12/09/2022, 20:55:32] [EleroStick] Incoming data [12/09/2022, 20:55:32] [EleroStick] [4] Updating currentTargetPosition: 0 [12/09/2022, 20:55:32] [EleroStick] [4][Channel 4] Updating lastPosition: 0 [12/09/2022, 20:55:32] [EleroStick] [4] Updating currentPositionState: 2 [12/09/2022, 20:55:32] [EleroStick] [4] Setting lastPosition: 0 [12/09/2022, 20:55:32] [EleroStick] Updating reportingInterval for channel 4 to 5000

AdminMBL commented 2 years ago

1 First interesting thing: 1 channel (2) totally missing, 1 channel (4) is changing position values acc to real status

ma-ku commented 2 years ago

the values for currentPositionState can be found in the enumeration below. The value 2 is the BOTTOM_POS_STOP value which resets the position accordingly.

What you see with channel 2 is that either it has not yet responded (sometimes the data comes in later) or does not respond at all. But maybe a first clue where to look at?

ˋˋˋ export const ELERO_STATES = {

NO_INFORMATION:         0x00,
TOP_POS_STOP:           0x01,
BOTTOM_POS_STOP:        0x02,
INTERM_POS_STOP:        0x03,
TILT_POS_STOP:          0x04,
BLOCKING:               0x05,
OVERHEATED:             0x06,
TIMEOUT:                0x07,
START_MOVE_UP:          0x08,
START_MOVE_DOWN:        0x09,
MOVING_UP:              0x0A,
MOVING_DOWN:            0x0B,
STOP_UNDEFINED_POS:     0x0D,
TOP_VENT_POS_STOP:      0x0E,
BOTTOM_INTERM_POS_STOP: 0x0F,
SWITCHING_DEVICE_OFF:   0x10,
SWITCHING_DEVICE_ON:    0x11

}; `

AdminMBL commented 2 years ago

[12/09/2022, 21:59:41] [EleroStick] [0] Get Name: Channel 0 [12/09/2022, 21:59:41] [EleroStick] [0] Requested CurrentPosition: 0 [12/09/2022, 21:59:41] [EleroStick] [0][Channel 0] Requested PositionState: 2 [12/09/2022, 21:59:41] [EleroStick] [0] Requested TargetPosition: 0 [12/09/2022, 21:59:41] [EleroStick] [0][false] Get ObstructionDetected: %s [12/09/2022, 21:59:41] [EleroStick] [1] Get Name: Channel 1 [12/09/2022, 21:59:41] [EleroStick] [1] Requested CurrentPosition: 0 [12/09/2022, 21:59:41] [EleroStick] [1][Channel 1] Requested PositionState: 2 [12/09/2022, 21:59:41] [EleroStick] [1] Requested TargetPosition: 0 [12/09/2022, 21:59:41] [EleroStick] [1][false] Get ObstructionDetected: %s [12/09/2022, 21:59:41] [EleroStick] [3] Get Name: Channel 3 [12/09/2022, 21:59:41] [EleroStick] [3] Requested CurrentPosition: 0 [12/09/2022, 21:59:41] [EleroStick] [3][Channel 3] Requested PositionState: 2 [12/09/2022, 21:59:41] [EleroStick] [3] Requested TargetPosition: 0 [12/09/2022, 21:59:41] [EleroStick] [3][false] Get ObstructionDetected: %s

AdminMBL commented 2 years ago

If you restart homebridge all channels are there (i have ch 2 deactivated)

AdminMBL commented 2 years ago

[12/09/2022, 21:59:45] [EleroStick] [3] Updating currentTargetPosition: 0 [12/09/2022, 21:59:45] [EleroStick] [3][Channel 3] Updating lastPosition: 0 [12/09/2022, 21:59:45] [EleroStick] [3] Updating currentPositionState: 2 [12/09/2022, 21:59:45] [EleroStick] [3] Setting lastPosition: 0 [12/09/2022, 21:59:45] [EleroStick] Updating reportingInterval for channel 3 to 5000 [12/09/2022, 21:59:45] [EleroStick] [4] Updating currentTargetPosition: 0 [12/09/2022, 21:59:45] [EleroStick] [4][Channel 4] Updating lastPosition: 0 [12/09/2022, 21:59:45] [EleroStick] [4] Updating currentPositionState: 2 [12/09/2022, 21:59:45] [EleroStick] [4] Setting lastPosition: 0

AdminMBL commented 2 years ago

After I few seconds only channel 3 & 4 are updated (= terrace doors). That‘s why I can not move the others accordingly.

AdminMBL commented 2 years ago

Now - after a while - Channel 0 is coming in and is also frequently updated like Ch 3 & 4. I am confused. What is triggering the updates? Why are there channels, which seems not to be updated frequently? KR

ma-ku commented 2 years ago

Since the communication between the receiver and the motors is not synchronous, the responses are coming in at arbitrary times. That's exactly what makes the whole process so complex. Ultimately I can only trigger an information request but if and when it is fulfilled, remains undefined.

I guess you should take a close look at motor #2 as it is not responding. What type of motors do you have? or do you have some control module in-between?

AdminMBL commented 2 years ago

Motor #2 up and running again. Think I lost it in my last testing round. Had do let the motor learn again. Nothing is n between motor & stick. What I found out so far:

ma-ku commented 2 years ago

OK, I would suggest to collect another seat of logs. I have published a new (beta) version of the plugin that provides better logs so maybe you pick this version before preparing the logs.

If you want to install a beta plugin, go to Plugins and click on the wrench symbol:

image

and pick 'Install previous version' or as in German:

image

Then, in the next dialog you can select any published version and also the beta releases.

AdminMBL commented 2 years ago

Hi, this is the log AFTER Restart HB an all shutters down: [15/09/2022, 19:52:30] [EleroStick] [0] Get Name: Channel 0 [15/09/2022, 19:52:30] [EleroStick] [0] Requested CurrentPosition: 0 [15/09/2022, 19:52:30] [EleroStick] [0][Channel 0] Requested PositionState: STOPPED [15/09/2022, 19:52:30] [EleroStick] [0] Requested TargetPosition: 0 [15/09/2022, 19:52:30] [EleroStick] [0][false] Get ObstructionDetected: %s [15/09/2022, 19:52:30] [EleroStick] [1] Get Name: Channel 1 [15/09/2022, 19:52:30] [EleroStick] [1] Requested CurrentPosition: 0 [15/09/2022, 19:52:30] [EleroStick] [1][Channel 1] Requested PositionState: STOPPED [15/09/2022, 19:52:30] [EleroStick] [1] Requested TargetPosition: 0 [15/09/2022, 19:52:30] [EleroStick] [1][false] Get ObstructionDetected: %s [15/09/2022, 19:52:30] [EleroStick] [2] Get Name: Channel 2 [15/09/2022, 19:52:30] [EleroStick] [2] Requested CurrentPosition: 0 [15/09/2022, 19:52:30] [EleroStick] [2][Channel 2] Requested PositionState: STOPPED [15/09/2022, 19:52:30] [EleroStick] [2] Requested TargetPosition: 0 [15/09/2022, 19:52:30] [EleroStick] [2][false] Get ObstructionDetected: %s [15/09/2022, 19:52:30] [EleroStick] [3] Get Name: Channel 3 [15/09/2022, 19:52:30] [EleroStick] [3] Requested CurrentPosition: 0 [15/09/2022, 19:52:30] [EleroStick] [3][Channel 3] Requested PositionState: STOPPED [15/09/2022, 19:52:30] [EleroStick] [3] Requested TargetPosition: 0 [15/09/2022, 19:52:30] [EleroStick] [3][false] Get ObstructionDetected: %s [15/09/2022, 19:52:30] [EleroStick] [4] Get Name: Channel 4 [15/09/2022, 19:52:30] [EleroStick] [4] Requested CurrentPosition: 0 [15/09/2022, 19:52:30] [EleroStick] [4][Channel 4] Requested PositionState: STOPPED [15/09/2022, 19:52:30] [EleroStick] [4] Requested TargetPosition: 0 [15/09/2022, 19:52:30] [EleroStick] [4][false] Get ObstructionDetected: %s

AdminMBL commented 2 years ago

After that channels3&4 are updated within seconds, all the others I can not find again.

ma-ku commented 2 years ago

Really strange behavior. So, what components are involved? Maybe we can pin that down to the types of devices?

And the configuration of the plugin would be great.

AdminMBL commented 2 years ago

Hi, -> all Motors Rol Top 868 -> Elero Transmitter Stick -> Raspi 4B -> HB no Bluetooth Tongle, no other USB Device, no Zigbee / 1 Remote VarioTel 2 available

AdminMBL commented 2 years ago

I did a few tests. Interesting fact: with the version 1.01 of the plugin, I get every channel status as requested (not everywhere the right one, bit instead of seeing nothing, I do see all channels reported).

ma-ku commented 2 years ago

I have pushed a new beta to NPM that allows to configure two things:

  1. Send interval: This is the duration between two send operations on the stick.
  2. Motors can be disabled (disabled property of each motor), also supported by the Config UI.

I would suggest to first disable the working motors to see if it is a kind of congestion in the IO. If that revives the three motors, we have a hint that eventually the sending queue gets overloaded. That leads to the sendInterval parameter and the default updateInterval. If the one is to slow and the other too fast, then messages will get dropped. Please play around with these values and check if that helps?!

AdminMBL commented 2 years ago

Hi, Thx! Where should I set the send intervall. Directly in the config or via UI?

AdminMBL commented 2 years ago

I disabled the 2 motors, which were regularly updated. Then i get 3 remaining motors with status: 0 (current position etc). All motors are shown as closed in HK (in reality they are open). When I close eg CH2 I will get the following: ADB437E5-8DA2-4A8B-8551-5B74D0635EFD Status: NaN After 1 Minute no other status is shown in the log until I move a shutter in HK. I did read in other threats that the info (easyinfo, easyakr) must be triggert per channel. I don’t know if this is the case. KR

AdminMBL commented 2 years ago

AAE14C87-C654-4220-B78E-B2D84FD99170 Here you can see that after I while no further information is received

ma-ku commented 2 years ago

The "sendInterval": 500, is expected in the platform config. Would you please post your config for the Elero stick here. I somehow have the feeling that something is messed up and have a second look on things sometimes helps.

ma-ku commented 2 years ago

Status: NaN This is interesting. Typically the state is supposed to be a number. I guess I have missed an execution path.

I did read in other threats that the info (easyinfo, easyakr) must be triggert per channel. I don’t know if this is the case. KR That's exactly what the plugin is doing. No matter how many channels are active, each channel will get polled individually.

I will take a look at things and maybe send another update today or tomorrow that has improved logging.

AdminMBL commented 2 years ago

Appreciated! Config { "name": "EleroStick", "port": "/dev/ttyUSB0", "updateInterval": 5000, "movingUpdateInterval": 1500, "platform": "EleroStick" } Sendintervall not set yet

ma-ku commented 2 years ago

Thank you. What about the motors? Do you have any configs for these?

AdminMBL commented 2 years ago

As this was not helping at the moment I did not set motor specifics.

AdminMBL commented 2 years ago

It seems now that i get reasonable info for alle the channels exp CH2 (problem:NaN) by setting update interval to 10.000ms. Progress!

ma-ku commented 2 years ago

So my config is the following:

{
            "platform": "EleroStick",
            "name": "EleroStick",
            "port": "/dev/ttyUSB0",
            "updateInterval": 3500,
            "movingUpdateInterval": 1500,
            "motors": [
                {
                    "channel": 0,
                    "name": "Fenster Teeküche",
                    "type": "shutter",
                    "disabled": false,
                    "duration": 24000
                },
                {
                    "channel": 1,
                    "name": "Gartentür",
                    "type": "shutter",
                    "duration": 30000
                },
                {
                    "channel": 2,
                    "name": "Fenster Küche",
                    "type": "shutter",
                    "duration": 24000
                },
                {
                    "channel": 4,
                    "name": "Volant",
                    "type": "shutter",
                    "reverse": true,
                    "duration": 15000
                },
                {
                    "channel": 5,
                    "name": "Markise",
                    "type": "shutter",
                    "duration": 28000
                },
                {
                    "channel": 9,
                    "name": "Schlafzimmer links",
                    "type": "shutter",
                    "duration": 24000,
                    "startDelay": 1000
                },
                {
                    "channel": 7,
                    "name": "Schlafzimmer rechts",
                    "type": "shutter",
                    "duration": 24000,
                    "startDelay": 1000
                }
            ]
        }

As you can see, I am polling the state in rest ever 3.5 seconds and ever 1.5 seconds when things are moving. This works perfect with all the different motors I have deployed. Detection of manual controlled movements is of course a bit less accurate but still acceptable.

AdminMBL commented 2 years ago

If I specify every motor like you do, I get following: 124C3162-6727-482A-87B8-81498AFEDAA6 Current status: NaN everywhere. Don‘t know whats the difference…

AdminMBL commented 2 years ago

Hi, I set now

AdminMBL commented 2 years ago

Intermediate result:

ma-ku commented 2 years ago

Sounds weird to me as the sendInterval should be less than any other interval as it basically means that the send queue will run full as anyone else is queuing messages faster than the messages get pushed to the Transmitter stick.

please install the latest beta before pulling logs. And ideally do not post screenshots rather than the actual log as a text file. This will make things easier to read and analyze.

AdminMBL commented 2 years ago

Thx. Sorry for the screenshots last time. Did not had access to the logs to prepare. That’s why I will do it until tomorrow.

AdminMBL commented 2 years ago

Hi, log attached. Everything was ok until I moved up one channel (CH1). _[20/09/2022, 20:50:17] [EleroStick] [1][Kinderzimmer] Reported motor state MOVINGUP checkChannelStates moved from 5000 ms to 1500 ms (which is ok, because of config movingUpdateInterval). It never came back to 5000 ms & 2 channels have never been reported again (CH1&CH0). homebridge.log.txt_beginn.txt

ma-ku commented 2 years ago

I have looked through the log and I am still not sure what the issue is. Here are a few observations: