dalinicus / homeassistant-acinfinity Goto Github PK

Is your feature request related to a problem? Please describe.
UIS protocol allows for changing operating values of UIS Enabled Devices connected to the controller. A user should be able to change these values from the home assistant interface

Describe the solution you'd like
At the most basic, Controls should be created for the following UIS fields

• Operating Mode (atType) - Select Entity
• Off Speed - Number Entity
• On Speed - Number Entity

These controls, and the already created SPEAK and ONLINE sensors, should be grouped under a new device for each port.. and that device should be linked to the controller device.

• Devices created for each port

Once implemented, additional feature request(s) should be added to create read/write controls for the remaining fields.

• Feature request(s) created
• Auto Mode Triggers
  • High Temp
  • Low Temp
  • High Humidity
  • Low Humidity
• VPD Mode Triggers
  • High VPD
  • Low VPD
• Cycle Mode Durations
  • On Duration
  • Off Duration
• Timer to On Duration
• Timer to Off Duration
• Schedule Mode Triggers
  • Start Time
  • End Time

Continuation of #14

Add the following controls that change how the controller operates in Timer Mode

• Timer to On Duration
• Timer to Off Duration

When changing modes I started having the following error message appear at the bottom of the screen...

This is what the log says...

Logger: homeassistant.components.websocket_api.http.connection
Source: components/websocket_api/commands.py:230
Integration: Home Assistant WebSocket API (documentation, issues)
First occurred: 5:39:53 PM (6 occurrences)
Last logged: 5:53:00 PM

[281473424745280] {'msg': 'Something went wrong with your request.\nPlease try again later.', 'code': 100001}
[281472154391232] {'msg': 'Something went wrong with your request.\nPlease try again later.', 'code': 100001}
Traceback (most recent call last):
  File "/usr/src/homeassistant/homeassistant/components/websocket_api/commands.py", line 230, in handle_call_service
    await hass.services.async_call(
  File "/usr/src/homeassistant/homeassistant/core.py", line 2035, in async_call
    response_data = await coro
                    ^^^^^^^^^^
  File "/usr/src/homeassistant/homeassistant/core.py", line 2072, in _execute_service
    return await target(service_call)
           ^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/src/homeassistant/homeassistant/helpers/entity_component.py", line 235, in handle_service
    return await service.entity_service_call(
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/src/homeassistant/homeassistant/helpers/service.py", line 876, in entity_service_call
    response_data = await _handle_entity_call(
                    ^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/src/homeassistant/homeassistant/helpers/service.py", line 948, in _handle_entity_call
    result = await task
             ^^^^^^^^^^
  File "/usr/src/homeassistant/homeassistant/components/select/__init__.py", line 106, in async_select_option
    await entity.async_select_option(option)
  File "/config/custom_components/ac_infinity/select.py", line 49, in async_select_option
    await self.set_setting_value(
  File "/config/custom_components/ac_infinity/__init__.py", line 148, in set_setting_value
    await coordinator.ac_infinity.set_device_port_setting(
  File "/config/custom_components/ac_infinity/ac_infinity.py", line 219, in set_device_port_setting
    await self.set_device_port_settings(device_id, port_id, [(setting, value)])
  File "/config/custom_components/ac_infinity/ac_infinity.py", line 228, in set_device_port_settings
    await self._client.set_device_port_settings(
  File "/config/custom_components/ac_infinity/client.py", line 105, in set_device_port_settings
    _ = await self.__post(API_URL_ADD_DEV_MODE, payload, headers)
        ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/config/custom_components/ac_infinity/client.py", line 119, in __post
    raise ACInfinityClientRequestFailed(json)
custom_components.ac_infinity.client.ACInfinityClientRequestFailed: {'msg': 'Something went wrong with your request.\nPlease try again later.', 'code': 100001}

Before I begin, I just wanted to say thank you for putting the time into creating this integration. It's made my life so much easier because now I can integrate 3rd party devices with my AC Infinity system. I have an AC Unit, dehumidifier, exhaust fan, secondary sensors, and more all using various automation and scripts inside HA to make everything runs smooth. I have found a couple small issues that you might want to fix as well as a couple of things to take into consideration if you're building a card. I made one HA with various cards but it keeps evolving. I have some basic coding knowledge but I'm lost as to how GitHub works or else I'd be trying to help you out. Hopefully one day I have the time to figure out what a pull request.

• In one of your previous updates you made the change to use _status be shown as Plugged In or Unplugged. That's fine but since it's a binary_sensor the state shows as on or off instead. That through me off a little when I was trying to get use the state in a template I made because I was checking for Plugged In or Unplugged.

• In the README file under Data Available you refer to "Power - Current Power supplied to the connected device" but you no longer use that. You've replaced it with _current_speed which I think is better but you just need to update that change in the README file.

• Also in regards to _current_speed I would consider changing it to something other than "speed" because it doesn't really apply when it comes to the lights, humidifiers, etc. My suggestion is to use what they use in the app which is "level". I think using _current_level would apply to all of the devices better than _current_speed currently does.

• When changing the mode entity for one of the devices there is a delay based on what you have the polling set to. If I am polling new data every 5 seconds then it's not that bad however if I have it set to a minute then it can cause issues. I haven't had a lot of time to mess with it yet but I plan to later today. One of the issues that I have is that I use Conditional cards to only show the controls for the selected mode. The Conditional cards check the state of the mode entity and then display the associated settings for the selected mode. If I am polling data every 30-seconds then it's possible that I have to wait 30-seconds for the Conditional card to see the new state and show the correct card and entities. I also noticed that when using an entities: card the drop down menu sometimes doesn't show in full and gets cutoff which I think is due to cards that am I using above and below it. The entities: card that I use to display and change the state of the mode also does not seem to update like it should but I need to mess with it a little more. I want to try creating my own input_select with all of the modes and then use that in place of the mode entity. This way the display will update correctly regardless of what the mode state is.

• On - Just like _current_speed I would consider changing this from _on_speed to something like _on_level. For example, the light that I have connected shows as number.tent_001_light_on_speed and I think something like number.tent_001_light_on_level works better.

• Off - The same as On Mode. I would consider changing this from _off_speed to something like _off_level.

• Auto - There are eight entities for Auto Mode. Four of them enable triggers and the other four are the levels of the trigger. All of them are named the same and start with auto except for two of them. Just to keep them all uniform I would change _humidity_low_trigger to auto_humidity_low_trigger and _humidity_high_trigger to auto_humidity_high_trigger.

• Timer To On - Instead of using _minutes_to_on use _time_to_on or _timer_to_on because it could be minutes or hours.

• Timer To Off - Instead of using _minutes_to_on use _time_to_off or _timer_to_off because it could be minutes or hours.

• VPD - Seems okay to me and it uses a toggle switch to enable which works better than the assumed_state that Schedule Mode uses.

• Cycle - Instead of using _cycle_minutes_off or _cycle_minutes_on use _cycle_off_duration and _cycle_on_duration because it could be minutes or hours.

• Schedule - Use a toggle switch instead of a assumed_state to show whether the start or end time is enabled. I think it feels more like the flow of the app. That's the way you did it in VPD and Auto mode so I would continue to do the same for Schedule Mode.

Below is what the card on my dashboard currently looks like. I put the off_speed and on_speed on each all of the views of the card for easier access. When I use the app and want to change the level of a device I have to leave the mode I am in and go to either the Off mode or the On mode to make the change. Then I have to make sure to remember to set it back to the correct mode. So having it available for each move makes things a lot easier. I also might change the card to a popup card because it takes up so much room on the dashboard. The tab card is working fine to change between each device but I don't like using the drop down menu to change the mode. I think I'm going to replace that with a small grid of buttons similar to the app.

Continuation of #14

Add the following controls that change how the controller operates in Schedule Mode

• Start Time
• End Time

Add the following sensors that show how long until the next schedule switch. This sensor will also apply to other modes.

• Time Left (Surplus)

puled bluetooth input and your not readin the correct hex value for vpd being sent by the system. please address.

Describe the solution you'd like
Unit tests achieving 80%+ code coverage

Acceptance Criteria

• Achieve 80%+ code coverage
• Add code coverage badge to README
• Add code style badge to README

The AC Infinity API sometimes hangs and times out. It's not consistent, and usually instantly recovers on the next call. Instead of spitting scary exceptions into the log for a one time occurrence, we should first retry the request after a delay.

• Retry requests twice, then pass error to HA
• Log that a retry was made with a warning

Currently, data is fetched when HA asks a sensor for new data, which calls an throttled update method. This is not the most efficient way of fetching data, and it seems to cause an unnecessary delay on updating controls on startup.

We should switch to a DataUpdateCoordinator, which is the documented way of updating data.

https://developers.home-assistant.io/docs/integration_fetching_data/

All the values like temperature, humidity, and VPD do not store as statistics so I cannot see the values in default statistics
graph.

Am I doing something wrong? Or is this something that has not been done yet?

Thank you and sorry if this was user error.

Is your feature request related to a problem? Please describe.
Currently you can only view entities via all entities tab.

Describe the solution you'd like
I'd like to see each unit as a device with even device ip / firmware version and be able to associate an area + more.

When it pulls data from AC is it possible to create sensor.fan for the Fan card in HA?
Thank you

Is your feature request related to a problem? Please describe.
No, although it is mildly annoying to have to delete the integration device and re-add it to update the user/pass login information.

Describe the solution you'd like
It would be nice if the Web UI configuration option allowed the user to update the login credentials along with the polling interval.

Thanks!

Currently, VPD and Schedule modes will update the "enabled" flag or show as disabled in the AC Infinity app if they're configured for certain values. This design choice was to reduce the number entities needed to be added to HA, as the number of them was already quite large without having to add a toggle for individual settings.

Since we're moving to custom cards, this is no longer necessary and in fact kind of undesirable. Add these settings so they can be added to the card.

• VPD High Enabled
• VPD Low Enabled
• Schedule Start Enabled
• Schedule End Enabled

I installed AC Infinity through hack, but
Devices and entities cannot be found.
I don't even see the configure button.
It just logged in with my email.

2023-10-23 18:10:35.869 WARNING (SyncWorker_1) [homeassistant.loader] We found a custom integration ac_infinity which has not been tested by Home Assistant. This component might cause stability problems, be sure to disable it if you experience issues with Home Assistant
2023-10-23 18:10:35.869 WARNING (SyncWorker_1) [homeassistant.loader] We found a custom integration hacs which has not been tested by Home Assistant. This component might cause stability problems, be sure to disable it if you experience issues with Home Assistant

Hello,
It appears Im experiencing an issue with the API this morning.

'msg': 'Something went wrong with your request.\nPlease try again later.', 'code': 100001} (home_assistant_error)

Unable to update settings. Retry attempt limit exceeded

Are these API rate limits? If so, what are those rate limits?

The integration seems to pull data every 30 seconds or at least that's what it shows in the history on Home Assistant. I have automations setup in Home Assistant that trigger when there are changes in temperature, humidity, and vpd. Since there are three event that I use as triggers my automation is being run more than I would like it to. Is there anyway to add a feature to change the frequency in which the data is being pulled? So instead of it being 30 seconds I could change it to 1 min or 2 minutes?

As I was writing this I thought of a possible work around for now which I think would work. I all three of the above mentioned sensors pull data at 30 second intervals then I could probably just use one of them as a trigger. I could then probably setup condition in my automation that check the state of all three sensors and then preform any actions accordingly. That should work to decrease the amount of times the automation is run from 6 times a minute to 2 times a minute but that's it. A feature that adds the option to change the frequency in which the data is being pulled would allow me to decrease that even more.

Continuation of #14.

Add the following controls that change how the controller operates in VPD Mode

• High VPD
• Low VPD

The following items need to be verified or changed in order to be added as a default HACS repository

General Requirements

• Only public repositories on GitHub will work with HACS.
• Your repository on GitHub needs to have a description that in a few words describes the purpose of the repository. This description is used in HACS.
• Your repository on GitHub needs to have topics. Topics are not displayed in HACS, but they can be used for searchability in the HACS store.
• Your repository needs to have a readme with information about how to use it. This is not used in HACS, unless you have defined the key render_readme in hacs.json below.
• hacs.json - This is a special manifest file that both defines the information that HACS shows in the UI and what files/paths that HACS should use. This file must be located in the root of your repository.
• If the repository uses GitHub releases, the tagname from the latest release is used to set the remote version. Just publishing tags is not enough, you need to publish releases.
• Badges - Tell your users that your repository can be tracked with HACS.

Integration Requirements

• Repository structure
  • There must only be one integration per repository, i.e. there can only be one subdirectory to ROOT_OF_THE_REPO/custom_components/. If there are more than one, only the first one will be managed.
  • All files required for the integration to run must be located inside the directory ROOT_OF_THE_REPO/custom_components/INTEGRATION_NAME/.
• manifest.json - In your integration directory you must have a manifest.json file, which must at least define these keys:
  • domain
  • documentation
  • issue_tracker
  • codeowners
  • name
  • version
• Home Assistant Brands - You must have added your integration to home-assistant/brands conform to the UI standards in Home Assistant.
• GitHub releases (optional)
  • It is preferred but not required to publish releases in your repository. If you publish releases in your repository, HACS will present the user with a nice selection view of the 5 latest releases together with the default branch when they are downloading or upgrading your integration. If you don't publish releases in your repository, HACS will use the files in the branch marked as default.
  • References and examples - A good template to use as a reference is blueprint. You can generate a template similar to blueprint and customized to your context by using cookiecutter-homeassistant-custom-component

Before Submitting

• Add both these actions to your own repository and make sure they pass: hassfest, hacs
  • Check Brands - This checks that the repository are added to https://github.com/home-assistant/brands
  • Check Manifest - This runs the same validation that HACS itself uses.
  • Check HACS - This runs the same validation that HACS itself uses.
  • Check HACS Manifest - This checks that the hacs.json file at least contains the following: name
  • Check Info - This checks that there is an info.md (or readme.md if configured) file with content in the repository.
  • Check Archived - This checks if the repository is archived.
  • Check Owner - This checks if the submitter is the owner of repository, this can fail if the repository belong to an org. or that the submitter is a major contributor to the repository.
  • Check Repository - This checks general things about the repository like:
    • It has a description
    • Issues are enabled
    • It has topics defined
    • Lint [jq] - This make sure that the files still are valid JSON.
    • Lint [sorted] - This make sure that the files still are sorted correctly.

Is your feature request related to a problem? Please describe.
Currently, in order to use the integration, a user must first capture traffic from a phone app in order to obtain their token. This is not user intuitive, and most likely out of reach for those that aren't technical.

There's also the possibility that this AC Infinity will update to rotating tokens, which will break this integration

Describe the solution you'd like
Try and find a login endpoint that accepts a user name and password. That way, the user token can be obtained for the user on integration startup rather than having to have the user supply it.

Displayed values way into the negatives. Started with 2024.2.0:

Continuation of #14. Add setting controls for Auto Mode Triggers that change how the controller operates in Auto Mode

• High Temp
• Low Temp
• High Humidity
• Low Humidity

This new integration popped up in my HACS screen and it appears to be a completely independent integration. However, there's already an existing ac-infinity-hacs integration by hunterjm and which saves it's configuration files in custom_components/ac_infinity, which is where this dalinicus/homeassistant-acinfinity integration also saves it's files.
So installing this one would corrupt the existing integration.

What I'm finding confusing is that there's absolutely no mention of the existing hunterjm/ac-infinity-hacs integration in the readme here, and there's no mention of this new integration if I search for it in /community.home-assistant.io.

So it would really help if there was some clarification of this new HACS integration as well as what to do if the other one is already installed, since it uses the same folder.

Love the work, played around and used the techniques to implement my own quick and dirty app to read sensor data and state and write them to text files for display on my twitch stream. I didn't love the process of getting the API key, trial install of fiddler just seemed a bit too bulky for the tiny need, so I wrote a quick and simple go app to spin up a proxy server and simply write out the API key and user-agent strings to the console once spotted. Certainly nothing wrong w/ the Fiddler approach but figured you may be interested in a simpler alternative, if so, the code and release can be found at https://github.com/dwot/ACScraper

Thanks again for all the work here!

--dwot

Continuation of #14 . Add setting controls for Cycle Mode Triggers that change how the controller operates in Cycle Mode

• On Duration
• Off Duration

Create a custom dashboard card for AC Infinity Devices connected to a UIS Controller. The card should organize the dozen or so entities each device adds to HA. This should also solve the desired intent of #13

• User should be able to select a mode from the card
• Card should show if a device is actively connected to the controller port (using the online entity)
• Card should show and hide entities based on if they're relevant for the selected mode
• Timer based modes should show the duration sensor entity
• Trigger based modes should show the state of the sensors relevant to the triggers for that mode

Mock ups demonstrating how the card should show and hide various settings based on the mode.