search

home-assistant / core

:house_with_garden: Open source home automation that puts local control and privacy first.
https://www.home-assistant.io
Apache License 2.0
71.11k stars 29.79k forks source link

[satel-integra integration] Unable to switch switable_output sequentially #42111

Closed dkossako closed 4 months ago

dkossako commented 3 years ago

The problem

When using script it's impossible to control two or more switchable_outputs sequentially. Workaround: add delay (at least 00:00:00.5) between next calls. Example script below. In this case second switchable_output will be never enabled or disabled (tried many times)

light_off:
  alias: Light - Off
  sequence:
  - service: switch.turn_off
    data: {}
    entity_id: switch.osw_front
  - service: switch.turn_off
    data: {}
    entity_id: switch.osw_taras
  mode: single
light_on:
  alias: Light - On
  sequence:
  - service: switch.turn_on
    data: {}
    entity_id: switch.osw_front
  - service: switch.turn_on
    data: {}
    entity_id: switch.osw_taras
  mode: single

Environment

Problem-relevant configuration.yaml

satel_integra:
  host: 192.168.100.51
  port: 7094
  code: 0000
  partitions:
    01:
      name: 'Dol'
  switchable_outputs:
    17:
      name: 'Osw. Front'
    18:
      name: 'Osw. Taras'

Traceback/Error logs

hass_1  | 2020-10-20 10:39:47 DEBUG (MainThread) [homeassistant.components.satel_integra.switch] Switch: Osw. Front status: False, turning on
hass_1  | 2020-10-20 10:39:47 DEBUG (MainThread) [homeassistant.components.satel_integra.switch] Switch: Osw. Taras status: False, turning on
hass_1  | 2020-10-20 10:39:47 DEBUG (MainThread) [homeassistant.components.satel_integra] Outputs updated callback , status: {'outputs': {17: 1, 18: 0}}
hass_1  | 2020-10-20 10:39:47 DEBUG (MainThread) [homeassistant.components.satel_integra.switch] Update switch name: Osw. Front zones: {17: 1, 18: 0}
hass_1  | 2020-10-20 10:39:47 DEBUG (MainThread) [homeassistant.components.satel_integra.switch] New state: True
hass_1  | 2020-10-20 10:39:47 DEBUG (MainThread) [homeassistant.components.satel_integra.switch] Update switch name: Osw. Taras zones: {17: 1, 18: 0}
hass_1  | 2020-10-20 10:39:47 DEBUG (MainThread) [homeassistant.components.satel_integra.switch] New state: False

Additional information

dkossako commented 3 years ago

@c-soft as far as I explored you made this integration? Do you have any idea where do I have to take a look? I can try to debug this.

Based on logs from the bottom I assume second switchable_output is never changed?

probot-home-assistant[bot] commented 3 years ago

satel_integra documentation satel_integra source (message by IssueLinks)

github-actions[bot] commented 3 years ago

There hasn't been any activity on this issue recently. Due to the high number of incoming GitHub notifications, we have to clean some of the old issues, as many of them have already been resolved with the latest updates. Please make sure to update to the latest Home Assistant version and check if that solves the issue. Let us know if that works for you by adding a comment 👍 This issue has now been marked as stale and will be closed if no further activity occurs. Thank you for your contributions.

dkossako commented 3 years ago

Issue is still present in latest stable version of HA.

NiccoStar86 commented 3 years ago

Hello everyone, I've also experienced this problem with the roller shutters. If I activate them individually, everything works properly. If I activate two, or more with automations in HA or with a scene from HomeKit / Alexa, only one is actually activated. I've tried to add some "delays" without little improvement. Any suggestions? Thank you

github-actions[bot] commented 3 years ago

There hasn't been any activity on this issue recently. Due to the high number of incoming GitHub notifications, we have to clean some of the old issues, as many of them have already been resolved with the latest updates. Please make sure to update to the latest Home Assistant version and check if that solves the issue. Let us know if that works for you by adding a comment 👍 This issue has now been marked as stale and will be closed if no further activity occurs. Thank you for your contributions.

dkossako commented 3 years ago

Issue is still present, also in latest stable HA version.

github-actions[bot] commented 3 years ago

There hasn't been any activity on this issue recently. Due to the high number of incoming GitHub notifications, we have to clean some of the old issues, as many of them have already been resolved with the latest updates. Please make sure to update to the latest Home Assistant version and check if that solves the issue. Let us know if that works for you by adding a comment 👍 This issue has now been marked as stale and will be closed if no further activity occurs. Thank you for your contributions.

NiccoStar86 commented 3 years ago

Issue is still present also in latest core-2021.7.4.

github-actions[bot] commented 2 years ago

There hasn't been any activity on this issue recently. Due to the high number of incoming GitHub notifications, we have to clean some of the old issues, as many of them have already been resolved with the latest updates. Please make sure to update to the latest Home Assistant version and check if that solves the issue. Let us know if that works for you by adding a comment 👍 This issue has now been marked as stale and will be closed if no further activity occurs. Thank you for your contributions.

dkossako commented 2 years ago

Nothing new, still present

c-soft commented 2 years ago

Yepp, no work has been done on it. But I haven't given up on it, winter comes, so Ill try to find some time.... Sorry for looooooooooooong wait :(

NiccoStar86 commented 2 years ago

Thank you for your work @c-soft

c-soft commented 2 years ago

OK, so I played around with this and I don't do anything special - it's the API on the other side that's ignoring the calls. I will research workarounds - essentially implementing some sort of throttling...

NiccoStar86 commented 2 years ago

@c-soft when you implemented the workaround I'm available to test it in my environment (I use the switchable_outputs for the rolling shutters with INT-IORS) if you need other data ... let me know!

tempImagerWdNIT

c-soft commented 2 years ago

That's a nice setup!! :)

pawelgarbacz commented 2 years ago

Hi, I in fact face similar issue: having defined multiple covers grouping pairs of switchable ouptuts when I try to close more than one of them at the same time only the first one (always the first one only even if I change the order of entities) in the defined group is responding (the output is activated) and others are not.

The configuration is as follows:

configuration.yaml file:

satel_integra:
  ...
  switchable_outputs:
    57:
      name: "Satel - roleta: gabinet (otwórz)"
    58:
      name: "Satel - roleta: gabinet (zamknij)"
    59:
      name: "Satel - roleta: sypialnia (otwórz)"
    60:
      name: "Satel - roleta: sypialnia (zamknij)"

For these two inputs I created covers called "sypialnia" and "gabinet" using template platform and then I grouped these under group cover - config below:

  - platform: template
    covers:
      sypialnia:
        device_class: shade
        friendly_name: Sypialnia
        open_cover:
          service: switch.turn_on
          target:
            entity_id: switch.satel_roleta_sypialnia_otworz
        close_cover:
          service: switch.turn_on
          target:
            entity_id: switch.satel_roleta_sypialnia_zamknij
        stop_cover:
          service: switch.turn_off
          target:
            entity_id:
              - switch.satel_roleta_sypialnia_otworz
              - switch.satel_roleta_sypialnia_zamknij

      gabinet:
        device_class: shade
        friendly_name: Gabinet
        open_cover:
          service: switch.turn_on
          target:
            entity_id: switch.satel_roleta_gabinet_otworz
        close_cover:
          service: switch.turn_on
          target:
            entity_id: switch.satel_roleta_gabinet_zamknij
        stop_cover:
          service: switch.turn_off
          target:
            entity_id:
              - switch.satel_roleta_gabinet_otworz
              - switch.satel_roleta_gabinet_zamknij

  - platform: group
    unique_id: rolety_pietro
    name: Rolety (piętro)
    entities:
      - cover.sypialnia
      - cover.gabinet

See part of my log:

2022-01-05 11:27:25 INFO (MainThread) [homeassistant.components.script.rolety_pietro_zamknij] Rolety piętro - zamknij: Running script sequence
2022-01-05 11:27:25 INFO (MainThread) [homeassistant.components.script.rolety_pietro_zamknij] Rolety piętro - zamknij: Executing step call service
2022-01-05 11:27:25 DEBUG (MainThread) [homeassistant.components.satel_integra.switch] Switch: Satel - roleta: sypialnia (zamknij) status: False, turning on
2022-01-05 11:27:25 DEBUG (MainThread) [homeassistant.components.satel_integra.switch] Switch: Satel - roleta: gabinet (zamknij) status: False, turning on
2022-01-05 11:27:26 DEBUG (MainThread) [homeassistant.components.satel_integra] Outputs updated callback , status: {'outputs': {57: 0, 58: 0, 59: 0, 60: 1}}
2022-01-05 11:27:26 DEBUG (MainThread) [homeassistant.components.satel_integra.switch] Update switch name: Satel - roleta: gabinet (otwórz) zones: {57: 0, 58: 0, 59: 0, 60: 1}
2022-01-05 11:27:26 DEBUG (MainThread) [homeassistant.components.satel_integra.switch] New state: False
2022-01-05 11:27:26 DEBUG (MainThread) [homeassistant.components.satel_integra.switch] Update switch name: Satel - roleta: gabinet (zamknij) zones: {57: 0, 58: 0, 59: 0, 60: 1}
2022-01-05 11:27:26 DEBUG (MainThread) [homeassistant.components.satel_integra.switch] New state: False
2022-01-05 11:27:26 DEBUG (MainThread) [homeassistant.components.satel_integra.switch] Update switch name: Satel - roleta: sypialnia (otwórz) zones: {57: 0, 58: 0, 59: 0, 60: 1}
2022-01-05 11:27:26 DEBUG (MainThread) [homeassistant.components.satel_integra.switch] New state: False
2022-01-05 11:27:26 DEBUG (MainThread) [homeassistant.components.satel_integra.switch] Update switch name: Satel - roleta: sypialnia (zamknij) zones: {57: 0, 58: 0, 59: 0, 60: 1}
2022-01-05 11:27:26 DEBUG (MainThread) [homeassistant.components.satel_integra.switch] New state: True
2022-01-05 11:27:28 DEBUG (MainThread) [homeassistant.components.satel_integra.switch] Switch name: Satel - roleta: sypialnia (zamknij) status: True, turning off
2022-01-05 11:27:29 DEBUG (MainThread) [homeassistant.components.satel_integra] Outputs updated callback , status: {'outputs': {57: 0, 58: 0, 59: 0, 60: 0}}
2022-01-05 11:27:29 DEBUG (MainThread) [homeassistant.components.satel_integra.switch] Update switch name: Satel - roleta: gabinet (otwórz) zones: {57: 0, 58: 0, 59: 0, 60: 0}
2022-01-05 11:27:29 DEBUG (MainThread) [homeassistant.components.satel_integra.switch] New state: False
2022-01-05 11:27:29 DEBUG (MainThread) [homeassistant.components.satel_integra.switch] Update switch name: Satel - roleta: gabinet (zamknij) zones: {57: 0, 58: 0, 59: 0, 60: 0}
2022-01-05 11:27:29 DEBUG (MainThread) [homeassistant.components.satel_integra.switch] New state: False
2022-01-05 11:27:29 DEBUG (MainThread) [homeassistant.components.satel_integra.switch] Update switch name: Satel - roleta: sypialnia (otwórz) zones: {57: 0, 58: 0, 59: 0, 60: 0}
2022-01-05 11:27:29 DEBUG (MainThread) [homeassistant.components.satel_integra.switch] New state: False
2022-01-05 11:27:29 DEBUG (MainThread) [homeassistant.components.satel_integra.switch] Update switch name: Satel - roleta: sypialnia (zamknij) zones: {57: 0, 58: 0, 59: 0, 60: 0}
2022-01-05 11:27:29 DEBUG (MainThread) [homeassistant.components.satel_integra.switch] New state: False

From what I've been able to find out from this debugging information it seems that only the first message (although HA is sending all of them to Satel integration component) gets sent to ETHM-1 Plus (async?) and before it's getting confirmed the second one is probably sent when ETHM-1 Plus is not ready yet to process it (?).

Maybe it would be good to batch such messages somehow and send them together? From what I've read in protocol specification it seems that one can activate multiple outputs in a single message so I thought if we e.g. send only first state change (async) and put the next ones coming in from HA in some buffer in Satel integration component until received confirmation from ETHM-1 it's been processed (status update) and only then send all other messages in a single call - maybe this would solve the issue?

The issue as I observed is a general one - not related to covers only - it does not even allow for control of group of lights (using UI-level group switch and predefined group of entities) too (tried that - same symptoms, first one switching on/off, rest are not responding at all, but individually are responsive :).

Let me know if you needed any additional debugging info or help with testing the changes.

c-soft commented 2 years ago

I had a look into that in the past and don't think that batching is doable. This would be the right solution, but the architecture is just not suitable - or maybe I just don't know enough about HA. The easiest approach is to implement throttling before sending requests to ETHM. I got it on my list, but severe lack of time is keeping it not done :(

I would ask you to put sleeps in your script as a workaround, can you pinpoint minimal delay that makes all of your outputs switched?

pawelgarbacz commented 2 years ago

1 second is good. 200 ms is too little definitely. Around 400 ms seems to be quite fine, will check further.

rupertas commented 2 years ago

@pawelgarbacz I think you are right: "If frame is corrupted (i.e. wrong crc sum or interrupted by 0xFE, 0xFE before completed) or cmd is not know or data length is not suitable for cmd - it is dropped and no answer is given back." as HA is sending commands asynchronous - second command could be "interrupted". I'm not familiar with HA integrations programming, but if there would be a chance to get all triggered group at once - 0x88 and 0x89 commands could be used. The problem is in satel's api implementation. It is slow and has no queue for messages on its side :(

pawelgarbacz commented 2 years ago

So it means that to avoid dropped frames Satel integration in HA must keep the state of async call and not try to send another one (queue calls with deduplication that allows batch messages?) only after the previous one has been successfully finished (or timed out).

For other languages I know there are frameworks to allow debouncing and grouping of messages (e.g. ReactiveX) - maybe using it would help with solving the problem?

On Wed, Jan 5, 2022 at 12:37 PM rupertas @.***> wrote:

@pawelgarbacz https://github.com/pawelgarbacz I thin you are right: "If frame is corrupted (i.e. wrong crc sum or interrupted by 0xFE, 0xFE before completed) or cmd is not know or data length is not suitable for cmd - it is dropped and no answer is given back." as HA is sending commands asynchronous - second command could could be "interrupted". I'm not familiar with HA integrations programming, but if there would be a chance to get all group at once 0x88 and 0x89 commands could be used. The problem is in satel's api implementation. Is is slow and has no queue for messages on its side :(

— Reply to this email directly, view it on GitHub https://github.com/home-assistant/core/issues/42111#issuecomment-1005611329, or unsubscribe https://github.com/notifications/unsubscribe-auth/AWFA3BN7L7BGGNW2QS3LLCTUUQURNANCNFSM4SX37ATQ . Triage notifications on the go with GitHub Mobile for iOS https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Android https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub.

You are receiving this because you were mentioned.Message ID: @.***>

rupertas commented 2 years ago

I guess so. We need to track if previous command has finished or timeout'ed while collecting new calls to stacks and then perform 0x88 for outputs on and 0x89 for outputs off providing content of collected outputs accordingly. But i think it is easier said then done

c-soft commented 2 years ago

I don't think the issue here is related to interrupting messages: instead, I believe that Satel is just dropping them on the floor when still processing previous ones.

@pawelgarbacz thanks for timing this. 400ms seems quite long but this will be the value I start with when implementing. This would mean that hitting 10 switches "at once" will take 4 seconds.... not beautiful, but at least it would work.

rupertas commented 2 years ago

I have a script for tilting blinds that turns "blinds up" and after 500ms activates "blinds down" to stop them. This is the timing that almost every time seems to work. But as satel panel is on remote place and communicates using "wifi tunnel" (300m between HA network and panel network) it is not always enough. Depends hardly on wifi latency. Its a pity we are stuck here with satels hardwere/firmware. Do you think there is a chance that Satel itself could do something with that?

By the way @c-soft could you please explain me this line of documentation: + 4 bytes - partition list, e.g.: if partition 1, 2, and 29 have to be armed: 0x03, 0x00, 0x00, 0x10 how do they get these 4 bytes (0x03, 0x00, 0x00, 0x10) from three decimals 1, 2 and 29?? or these 16 bytes from 3,14 and 128 *0x00+ 16/32 bytes ()(e.g. 04 20 00 00 00 00 00 00 00 00 00 00 00 00 00 80 - zones 3, 14 and 128)**

thanks in advance

pawelgarbacz commented 2 years ago

.0x03 0x00 0x00 0x10 translates to (in binary)

1100000 0000000 0000000 00001000

"1" on certain position codes specific zone/output/partition as active/affected. Just the order of bit positions is reversed :)

Auroray commented 2 years ago

I've just had this experience as well, totally didn't expect it - I guess I just wasn't appreciating the integration that Domoticz has enough. Until this is fixed, what would be the workaround for lights? I managed to figure out the specific minimal reliable delay in my setup and just created scripts and cover template entities to handle them, but lights I can't really figure out. Even with scripts running on a delay, both before and after the service is called to turn on the switch, creating a scene to turn all lights off only turns off the first one. Same behaviour when HA is piped to HomeKit.

Any ideas? As it is this integration isn't really usable for people that use Integra to control lights.

github-actions[bot] commented 2 years ago

There hasn't been any activity on this issue recently. Due to the high number of incoming GitHub notifications, we have to clean some of the old issues, as many of them have already been resolved with the latest updates. Please make sure to update to the latest Home Assistant version and check if that solves the issue. Let us know if that works for you by adding a comment 👍 This issue has now been marked as stale and will be closed if no further activity occurs. Thank you for your contributions.

pawelgarbacz commented 2 years ago

The problem is still open and requires some kind of resolution. After longer thinking I came to a conclusion that perhaps the solution might to block any further messages sent (just buffer them) to Satel before obtaining notification for the previously processed command. This should prevent from receiving 0xFE messages? Any idea if this could be addressed somehow?

c-soft commented 2 years ago

Just to confirm: this issue is unfortunately still alive. The only resolution I can think of is throttling to ~400ms between calls. Have not implemented it due to lack of time ...

mgruszka-ops commented 2 years ago

Hi @c-soft, I'm not good in Python, but if, possibly, I can add my 2 cents here... Maybe two arrays of output states: one representing current relays (0x17 command), another for expected states from user (user changes the states in an array) and plugin will compare both arrays then send 0x88 and 0x89 commands when requested, then check the results. Of course every time waiting for response or timeout (you have some code "send_and_wait_for_answer" in your .py - commented out). For INT-RS the timeout is 3 sec, but based on experiments in this thread, I assume the 0,5 to 1 second timeout should be ok.

sqet commented 1 year ago

Issue still alive. Only way to handle the automation is the to delay or use Node Red and create custom entities

issue-triage-workflows[bot] commented 1 year ago

There hasn't been any activity on this issue recently. Due to the high number of incoming GitHub notifications, we have to clean some of the old issues, as many of them have already been resolved with the latest updates. Please make sure to update to the latest Home Assistant version and check if that solves the issue. Let us know if that works for you by adding a comment 👍 This issue has now been marked as stale and will be closed if no further activity occurs. Thank you for your contributions.

Auroray commented 1 year ago

The issue is still active and needs resolution.

On Mon, 23 Jan 2023 at 14:10, issue-triage-workflows[bot] < @.***> wrote:

There hasn't been any activity on this issue recently. Due to the high number of incoming GitHub notifications, we have to clean some of the old issues, as many of them have already been resolved with the latest updates. Please make sure to update to the latest Home Assistant version and check if that solves the issue. Let us know if that works for you by adding a comment 👍 This issue has now been marked as stale and will be closed if no further activity occurs. Thank you for your contributions.

— Reply to this email directly, view it on GitHub https://github.com/home-assistant/core/issues/42111#issuecomment-1400313536, or unsubscribe https://github.com/notifications/unsubscribe-auth/AGM5LZEEKCIR45B24LPYOBDWTZ7MPANCNFSM4SX37ATQ . You are receiving this because you commented.Message ID: @.***>

WojciechSzefler commented 1 year ago

is there any workaround ?, sorry for my lack of knowledge but i tried to use script/scene (to put some delay) but "switchable_outputs" do not appears there if there is no "final" solutions maybe is good to have a workaround :) thx !!!

bad00 commented 1 year ago

What exactly would a solution using delay in Node Red look like?

misha1111 commented 1 year ago

Hello is there a chance that the integration will work with HA groups?

kaniagandzowski commented 1 year ago

I would like to report a problem I encountered when expanding my system with additional INT-IORS modules as part of the Satel ETHM-1 Plus integration with Home Assistant. After adding new features such as control of ventilation, lights and irrigation system, I noticed that I am encountering difficulties with sequential control of multiple outputs.

The main problem is that I can turn on a relay, but cannot then turn it off, or vice versa. The problem applies to a single relay. And as I added more controllable outputs the control problem appeared elsewhere, where before it worked fine. This is especially frustrating because I had no problems with controlling roller shutters before. I've noticed that other users on various forums have reported similar problems, which suggests that this is not an isolated case.

As a temporary solution, I'm adding an artificial delay time between each call, but it's not ideal. It looks like it may be a problem with the communication protocols between Home Assistant and Satel ETHM-1 Plus.

In addition, I created a virtual output (e.g., output #121) that controls the target output (e.g., output #66) to get around this problem. Unfortunately, I discovered that other outputs suddenly start malfunctioning.

Has anyone else experienced similar problems? Is there any way to permanently solve this problem? Any help would be greatly appreciated. Thank you!

pawelgarbacz commented 1 year ago

I managed to enable batch state switch updates (on / off) in the following patch to the underlying satel_integra library (see this project: https://github.com/c-soft/satel_integra). It's very quick and dirty and not really tested thoroughly yet. Unfortunately I have no idea how to put that in the main repository (I can't commit even into a separate branch, so publishing the updated source here). satel_integra.zip

mgruszka-ops commented 1 year ago

Hi @pawelgarbacz , I would like to test your solution. I’ve tried to find location of original file, but inside HAOS webgui Terminal (so inside the container, as I understand) the file is missing. Are you able to guide me a little bit?

pawelgarbacz commented 1 year ago

I run my HA on Docker, so after altering the library code I uploaded it to docker container using the following command:

docker cp satel_integra.py homeassistant:/usr/local/lib/python3.11/site-packages/satel_integra/satel_integra.py

You must check in your case what Python version you have and whether the site-packages reside at this particular location. You can enter the docker instance using this command: docker exec -it homeassistant /bin/bash and look in the filesystem where is the satel_integra.py script

mgruszka-ops commented 1 year ago

Hi Paweł, Thanks for detailed information. It allowed me (with some other hacks ;) ) to upload your code. It works well and smooth. Until now I noticed that 0xFE byte is not enriched by 0xF0 in CRC, which in combination of my user code disallow me to switch off (command 89) output # 29.

In wireshark I see (user code already changed):

fe-fe-89-92-83-74-ff-ff-ff-ff-ff-00-00-00-08-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-fe-e1-fe-0d Where it should be: FE-FE-89-92-83-74-FF-FF-FF-FF-FF-00-00-00-08-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-FE-F0-E1-FE-0D

So at the end we have (CRC+to the end):

fe-e1-fe-0d FE-F0-E1-FE-0D

As per Protocol Documentation from Satel:

If any byte of the frame (i.e. cmd, d1, d2, ..., dn, crc.high, crc.low) to be sent is equal 0xFE, the following two bytes must be sent instead of single 0xFE byte: 0xFE, 0xF0. In such case only single 0xFE should be used to update crc.

Further tests ongoing ;)

mgruszka-ops commented 1 year ago

I spot the bug in Satel_integrra.py, line 76 use bytearray.replace(), which always generate new output (as found on https://docs.python.org/3/library/stdtypes.html#bytes-and-bytearray-operations), so simple solution is: replace line 76: data.replace(b'\xFE', b'\xFE\xF0') with following: data = data.replace(b'\xFE', b'\xFE\xF0')

Until now I tested it on extracted part of code (outside HA), I'll update the script next week.

rupertas commented 1 year ago

Hi all, it is so waited functionality, is there any chance that it will be added to the integration it self?

pawelgarbacz commented 1 year ago

@c-soft, what would be the way to promote the above changes to your library so it gets pulled from repository with HA?

pawelgarbacz commented 1 year ago

Posted this issue in the underlying satel integration library. I hope this allows us to put the change in the default code base since now any HA version update causes overwriting the library with old code (at least in docker environment).

MBarti commented 1 year ago

@c-soft Please help integrate @pawelgarbacz & @mgruszka-ops fix. There are a lot of us that are waiting for it to be fixed. Since my whole set-up is used through Homekit, I can't use Scenes (no way to put delays in them) and many of them don't work...

MBarti commented 12 months ago

I managed to enable batch state switch updates (on / off) in the following patch to the underlying satel_integra library (see this project: https://github.com/c-soft/satel_integra). It's very quick and dirty and not really tested thoroughly yet. Unfortunately I have no idea how to put that in the main repository (I can't commit even into a separate branch, so publishing the updated source here). satel_integra.zip

I tested it and confirm this solves the problem for me!

@c-soft please integrate it.

NiccoStar86 commented 12 months ago

Hi @MBarti could you explain how to do the test? I would also like to try it with my Satel INT-IORS component to check if it is resolving. Thank you

MBarti commented 12 months ago

I just downloaded the zip file form comments above and addedd it to my container with home assistant, using the command form the comments above. Then restarted HA. Possibly, it'd be best to also include that other fix from https://github.com/home-assistant/core/issues/42111#issuecomment-1616130426

MBarti commented 12 months ago

I managed to enable batch state switch updates (on / off) in the following patch to the underlying satel_integra library (see this project: https://github.com/c-soft/satel_integra). It's very quick and dirty and not really tested thoroughly yet. Unfortunately I have no idea how to put that in the main repository (I can't commit even into a separate branch, so publishing the updated source here). satel_integra.zip

Upon further testing, it mostly works, but not always. It works for multiple outputs, like 2 lights. But does not work, when in a scene I also want to arm or disarm the alarm (e.g. a night scene, turning off all lights and arming the Satel system) - the switches work, but the alarm doesn't start to arm.