[satel-integra integration] Unable to switch switable_output sequentially

dkossako commented 4 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

Home Assistant Core release with the issue: 0.116.4
Last working Home Assistant Core release (if known): not known
Operating environment (OS/Container/Supervised/Core): Container
Integration causing this issue: satel_integra
Link to integration documentation on our website: https://www.home-assistant.io/integrations/satel_integra/

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

leshqo commented 1 year 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 #42111 (comment)

Any idea how to apply it to non dockerized HASS?

16D commented 1 year ago

Hi,

I have integrated Satel Integra with HA and I have problem with switchable_output number 17. I can turn it on with HA, but can't turn off. Other switchable outputs works without issues.

leshqo commented 1 year ago

Ok guys ... there is an answer for your needs. I've forked integration repo made by one of the guys + forked satel_integra repo. After some "rebranding" and help by @michaljonik I applied changes from above zip archive, built it and push to PYPI projects which I linked with mentioned integration repo. This repo can be easily added to HACS and once downloaded and restarted all you need to do is a change in config from satel_integra to satel_integra_ext + restart. Looks that batch processing works well. By doing it this way through HACS changes will not be lost once HASS updates. You can find it here: https://github.com/leshqo/satel_integra_ext-ha

NiccoStar86 commented 1 year ago

Great job @leshqo 🎉👏🏻 I already installed the component and finally the "Scenes" from HomeKit now have a sense🥳

NiccoStar86 commented 1 year ago

Hi, I have integrated Satel Integra with HA and I have problem with switchable_output number 17. I can turn it on with HA, but can't turn off. Other switchable outputs works without issues.

Hi @16D I remember that having a similar problem with another switchable output and solved it by configuring a virtual switchable output (on Satel controller) that operated the switchable output that the Home Assistant could not control ... a functional workaround! Hope this help!

issue-triage-workflows[bot] commented 9 months 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.

rupertas commented 9 months ago

The issue is not solved, It was corrected and moved to HACS. (thank you guys) I think that original project was abandoned :(

issue-triage-workflows[bot] commented 6 months 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 5 months ago

Hi everyone, I saw this issue is still not resolved and without perspective to be resolved in near time in this thread.

As a result of that and in meantime I spent some time to develop a completely new approach and improved approach to how Satel Integra can be integrated into Home Assistant, without the need to use YAML configuration.

Functional overview

The new implementation will not rely on external library by @c-soft as all the logic is implemented directly in the integration itself in more robust and object way. It will also allow pull configuration and structure, i.e. all objects, partitions, zones and outputs (respectively "partycje", "strefy", "wejścia" i "wyjścia" in Polish nomenclature) configured with DloadX with their attributes directly from the board, including their names. This can be extended beyond just reporting on inputs, reporting/controlling of outputs and arming/disarming partitions, but also pull events, troubles, bypass zones and so on.

Entities, automatically created based on how the items are configured in DloadX, in the new approach will be fully customizable through UI and the integration would apply some special treatment to certain types of outputs e.g. controlling covers/shutters in such a way that not only switches are exposed in HA but also the cover entity is implemented (with full support of approximate position reporting and setting and without the need for template cover configuration - I had that in my installation after lots of configuration, but still not that functional as in the new implementation) or treating outputs as binary_sensors if they are not controllable (anything else than mono- and bi-stable switch).

Also some diagnostic entities would be supported like flash_flag (if the settings are stored in flash or not), service_mode, troubles flag (current or past - in memory) and few others like flash version and date, and so on.

My final intention would be to push the reimplemented approach into the main code base of Home Assistant and replace the legacy way of configuring the integration (including abandoning the configuration through YAML) with the new one initiated through UI.

Legacy configuration support

Legacy configuration through YAML could potentially still be supported if needed by anyone (I find it not needed at all, but it might be breaking for someone else, i.e. requiring to redo/migrate all the automations, dashboards, etc. because the entity names might change - this might not be a desired effect). The legacy configuration support itself is not yet implemented though - I only started thinking on how to do it, but it seems quite a bit of a challenge as the integration is setup in HA differently when it is initiated via YAML (async_setup(hass, config)) vs. from UI (async_setup_entry(hass, config_entry)) and I didn't find a way/method to migrate from one to the other (yet?).

I already found a way to pass the config from one to the other, but the other one seems not to be automatically executed from code (or I didn't find a way yet how to force it) and therefore it requires manual configuration through UI (i.e. adding a new Satel Integra hub by specifying connection details, password, etc. in UI) in order to initiate the integration in the new way.

The change would also be that all entities would have unique ids generated eventually which might affect that even if the name would be picked from YAML file it might not be exactly the same as the legacy one (, e.g. with "_2" suffix added to every one of them) - thus breaking current functionality because the "old" entity would not be linked with the "new" one even if their names are the same.

I propose to vote here if support for legacy is that important for you or not.

Functional summary

What's currently supported and tested manually (I don't have experience in automated testing in Python so I would appreciate if someone could help here, esp. I saw that it might be required to test your code when creating PR to commit to Home Assistant master repository):

load structure from scratch: create entities:
- binary_sensor - for each input (zone) and output (if its state is anything else than cover/shutter up/down or mono-/bi-stable switch - types: 24, 25, 105 and 106),
- switch - for each output if its type is mono-/bi-stable switch or cover/shutter up/down (the latter two are disabled by default),
- cover - created for each pair of outputs when their types are cover/shutter up/down (types: 105 and 106); the cover reports its state (open/close, percentage position) and allows for full open/close operation as well as setting a percentage position; state is retained during restarts (with caveat that if cover was operated during Home Assistant being down it might not be in the position recovered after it got up),
- alarm_control_panel - created and controllable through password entered in UI (note integration password should not be allowed to arm/disarm a partition due to security reasons in my opinion) for each partition which has zones configured in DloadX (password guarded partitions are only supported, didn't test any other types because I don't have them configured in my Satel Integra and don't know how they potentially behave - just report on their state?)
reload structure - initialted manually via hub reload in case of board configuration has been changed in DloadX (I didn't find a way to do that automatically, because it makes no sense to just rescan every now and then - in case of my board it takes 3 mins+ to go through all zones/outputs and their parent partitions/objects - and there is no flag indicating that; it might be good to know how Satel implemented that in their app because it does it automatically when detecting a change)

Other functionality that might also be supported (which is not implemented, but I thought it might be useful) - the list below is not extensive and feel free to chip in if you thought of other useful or missing features:

encryption (I currently implemented checkbox in UI, but didn't implement the encryption yet),
enabling/disabling zones (bypass),
pushing troubles as events in HA,
pushing log entries as events,
support for multiple boards at the same time (each would be a separate device in HA - currently for the new implementation only one is added).

Help needed

Currently the code seems to be fully functional and pretty stable (except for the support of legacy config and other advanced features I mentioned above), but I only tested it with my board (which Satel Integra 256 Plus with ETHM-1 Plus) and I don't have a way to test it with any other because I have no access to other boards (esp. lower ones) or other ETHM modules.

Therefore question to all participants (watchers) of this discussion - anyone else able to help to test the integration? I mean to test it manually in their local test HA, via test suite, or via dedicated test code outside HA environment to check connectivity with other boards, especially with an idea on how to do it since this is my piece in Home Assistant environment, so I don't even know the standards... :)

I can provide some test scripts to be run using the same communication layer (outside of Home Assistant) to try to check communication with other types of boards if needed.

Happy to discuss here.

c-soft commented 5 months ago

Hi @pawelgarbacz!

This is great news, as indeed I had zero time to support this integration recent years, hindering its development, for which I'm quite sorry. Couple of points: 1) I'm happy to test out your code, I should find some time to do that. 2) Drop a note on Polish FB HA page, as many users are there 3) Not sure if you're noticed but there is a requirement in HA to push out any device specific communication code outside to separate library. This was the reason for developing my own in the first place.

Thanks again for your effort!

mgruszka-ops commented 5 months ago

@pawelgarbacz, I'm interested to help. Let me know how to get the code and how to implement it.

pawelgarbacz commented 5 months ago

1. I'm happy to test out your code, I should find some time to do that.

I will post it in my fork on github soon - as far as I understand this is anyway required to PR to master HA repository. I could do some assistance from your side @c-soft since you already did that... :)

2. Drop a note on Polish FB HA page, as many users are there

Unfortunately I don't use FB... :(

3. Not sure if you're noticed but there is a requirement in HA to push out any device specific communication code outside to separate library. This was the reason for developing my own in the first place.

https://developers.home-assistant.io/docs/development_checklist - do you refer to first bullet in the checklist? I read that differently - IF you use external library THEN it must be in pypi. It doesn't say anything it must use external communication layer (e.g. REST in other components can fully be handled by bare Python).

pawelgarbacz commented 5 months ago

You can find the code committed (some version - it seems it still has some issues due to switching to current dev branch of HA) in my fork here: https://github.com/pawelgarbacz/home-assistant-core. For now the easiest way to test it is to follow instructions on HA developer portal: https://developers.home-assistant.io/docs/development_environment and run fresh development instance of HA.

In order to test the connectivity code standalone I need to create some scripts so they could be run for diagnostics.

Alternatively the integration can be tested in your "production" HA (either in docker on standalone) - you just need to update the entire code in homeassistant/components/satel_integra directory to the one from repo and additionally edit homeassistant/generated/integrations.json file and set "config_flow": true in the "satel_integra" entry in order to enable configuring Satel Integra integration from UI. In this case you also need to disable satel_integra node in configuration.yaml since as I wrote before the part to load legacy configuration (even the schema validation) is not implemented yet.

pawelgarbacz commented 5 months ago

I think I need a bit more time to post the change - when applied on home assistant dev branch it generates lots of errors and pre-commit hooks prevent me from checking in. Will work on that soon - sorry, but as I wrote this is the first time I wrote something for such a big project... :)

c-soft commented 5 months ago

HI, sorry, but in the current shape I wont be able to test it out - my setup is just too fragile for that (I only have "prod" environment). So it would have to be packed into custom component. Also, you will have to have external library, otherwise your checkin wont be accepted by the HA community, sorry ...

MBarti commented 4 months ago

@c-soft In the mean time, can you please just take 5 minutes and approve the PRs for the fixes which started this thread? Otherwise with each HA update, everyone needs to apply manual fixes again. Thanks for your work so far!

https://github.com/home-assistant/core/issues/42111#issuecomment-1714371248

home-assistant / core