Closed AdminMBL closed 1 year 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
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.
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
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.
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.
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!
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.
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?
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
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
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?
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.
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
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…
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
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?!
[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
1 First interesting thing: 1 channel (2) totally missing, 1 channel (4) is changing position values acc to real status
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
}; `
[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
If you restart homebridge all channels are there (i have ch 2 deactivated)
[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
After I few seconds only channel 3 & 4 are updated (= terrace doors). That‘s why I can not move the others accordingly.
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
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?
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:
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:
and pick 'Install previous version' or as in German:
Then, in the next dialog you can select any published version and also the beta releases.
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
After that channels3&4 are updated within seconds, all the others I can not find again.
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.
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
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).
I have pushed a new beta to NPM that allows to configure two things:
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?!
Hi, Thx! Where should I set the send intervall. Directly in the config or via UI?
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: 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
Here you can see that after I while no further information is received
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.
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.
Appreciated! Config { "name": "EleroStick", "port": "/dev/ttyUSB0", "updateInterval": 5000, "movingUpdateInterval": 1500, "platform": "EleroStick" } Sendintervall not set yet
Thank you. What about the motors? Do you have any configs for these?
As this was not helping at the moment I did not set motor specifics.
It seems now that i get reasonable info for alle the channels exp CH2 (problem:NaN) by setting update interval to 10.000ms. Progress!
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.
If I specify every motor like you do, I get following: Current status: NaN everywhere. Don‘t know whats the difference…
Hi, I set now
Intermediate result:
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.
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.
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
I have looked through the log and I am still not sure what the issue is. Here are a few observations:
[20/09/2022, 20:50:16] [EleroStick] Updating reportingInterval for channel 4 to 9000
[20/09/2022, 20:50:17] [EleroStick] [1][Kinderzimmer] Reported motor state MOVING_UP
[20/09/2022, 20:50:17] [EleroStick] [1][Kinderzimmer] Updating currentPositionState: INCREASING
[20/09/2022, 20:50:17] [EleroStick] [1][Kinderzimmer] Updating lastPosition: 100
[20/09/2022, 20:50:17] [EleroStick] [1][Kinderzimmer] Updating currentTargetPosition: 100
[20/09/2022, 20:50:17] [EleroStick] [1][Kinderzimmer] Updating lastPosition: 100
[20/09/2022, 20:50:17] [EleroStick] [1][Kinderzimmer] Updating currentPositionState: INCREASING
[20/09/2022, 20:50:17] [EleroStick] [1][Kinderzimmer] Setting lastPosition: 100
[20/09/2022, 20:50:17] [EleroStick] Updating reportingInterval for channel 1 to 1500
[20/09/2022, 20:50:17] [EleroStick] [1] Kinderzimmer OPENING [100]
[20/09/2022, 20:50:20] [EleroStick] checkChannelStates (1500 ms)
[20/09/2022, 20:50:20] [EleroStick] [1][Kinderzimmer] Reported motor state MOVING_UP
[20/09/2022, 20:50:20] [EleroStick] [1][Kinderzimmer] Updating currentPositionState: INCREASING
[20/09/2022, 20:50:20] [EleroStick] [1][Kinderzimmer] Updating lastPosition: 100
[20/09/2022, 20:50:20] [EleroStick] [1][Kinderzimmer] Updating currentTargetPosition: 100
[20/09/2022, 20:50:20] [EleroStick] [1][Kinderzimmer] Updating lastPosition: 100
[20/09/2022, 20:50:20] [EleroStick] [1][Kinderzimmer] Updating currentPositionState: INCREASING
[20/09/2022, 20:50:20] [EleroStick] [1][Kinderzimmer] Setting lastPosition: 100
[20/09/2022, 20:50:20] [EleroStick] Updating reportingInterval for channel 1 to 1500
Why this happens is totally unclear to me. I would suggest that you learn the motor to a second channel (e.g. 6) and disable channel 1 in the config file. That way we can check if either the channel is somehow learned wrong (?) or if maybe something is wrong with the way the plugin is addressing the channel?
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