GithubHelp home page GithubHelp logo

haswitchplate / openhasp-custom-component Goto Github PK

View Code? Open in Web Editor NEW
50.0 6.0 11.0 333 KB

Home Assistant custom component for openHASP

Home Page: https://www.openhasp.com

License: MIT License

Python 100.00%
home-automation home-assistant-custom openhasp

openhasp-custom-component's People

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar  avatar  avatar  avatar

openhasp-custom-component's Issues

Adjustable brightness levels and Moodlight defaults

Would be nice to have these configurable from yaml, as more plates can be present in the system and they may require different settings:

  • a service to set the idle_brightness and awake_brightness dynamically at HA runtime. To use with automations which could monitor light conditions in the room.
  • a default color for moodlight (specific to that room, for example) + service to change it
  • an option to switch moodlight on before turning screen off (now possible with automation, but can be triggered only after the screen turns off thus the unit blinks through full-dark for a moment, see below)
  • plates's short and long idle times (they are configurable form plate's web interface but would look nice to read them from there and set them from HA)

Feature request: pseudo-plate for group topic

Is your feature request related to a problem? Please describe.
When we have multiple plates configured in the same home automation system, there are many things which are displayed the same on all the plates. Currently you have to configure these things one by one for all the plates.
Besides increasing the network traffic, it also makes it harder to maintain whenever something has to be changed - one has to manually change the same thing in all places.
One good use case is the weather example but also basic stuff like clock and temperature in the headers.

Describe the solution you'd like
Very simply add an extra dedicated config file like group.yaml to the CC configuration directory, with the group topic of the plates set as slug. An exception here that there's no discovery, this has to be added without discovery.
One may have multiple group topics configured (say 1st floor rooms, 2nd floor rooms) so it would be probably useful to handle multiple such configs (multiple slugs) within that file.
Also would be nice to have a stripped down entity for the pseudo-platee (no switches/pages etc, only reset and antiburn) so that services could be run against this - run commands on all the plates on the same group topic.

Describe alternatives you've considered
Achieving the same is only possible with automations outside CC, which make things a bit more complicated as they need triggers.

Additional context
N/A

Feature request: Entity offline handling

Is your feature request related to a problem? Please describe.
Make more exact the way HA is handling plate entities when they are unreachable on the network, in order for the user to be able to correctly identify which plate has problems and fix the correct one.

Describe the solution you'd like
Currently only switch/light entities go to Unavailable state when plate goes off the network. Main entity should also turn to Unavailable.
In HA > Configuration > Integrations where the plates are listed a notification icon should be present (just like when config slug is missing currently) at the plates which are offline (a yellow triangle with exclamation mark would be good). This way the user can immediately be aware which one(s) need fixing.

Describe alternatives you've considered
N/A

Additional context
N/A

Idle brightness cannot be changed + not applied

Version of the custom_component

0.6.0 main f597d75

Configuration

N/A

Describe the bug

The idle brightness value can only be set during discovery and first setup of plates.

It's impossible to change this after the plate has been added to the system, if path field is empty: "User input malformed" error shows.
kép

Also, when the plate was set during setup with a different idle brightness value, in reality it's still set to 25:
kép

Debug log


N/A

Enhance CC `push_image` service with an optional argument (`group_topic`)

openHASP 0.6.3 - HA supervised core-2021.10.5

Configuration

- id: hasp_sonos_image
  alias: hasp_sonos_image
  # restart mode used to minimize plate mqtt queue issues if skipping rapidly through a playlist
  mode: restart
  trigger:
    - platform: state
      entity_id: media_player.kokken
      attribute: entity_picture
  # condition added as media player picture entity sometimes changes to None briefly in between image changes. 
  condition:
    - condition: template
      value_template: "{{ state_attr('media_player.kokken', 'entity_picture') != None }}"
  action:
  - delay: '00:00:01' # Adding this delay has almost removed all plate crashes
  - service: openhasp.push_image
    data:
      obj: p2b40
      image: >-
        http://192.xxx.xxx.xxx:8123{{state_attr('media_player.kokken', 'entity_picture')}}
      width: 250
      height: 250
    target:
      entity_id:
        - openhasp.wt32_01
    # - openhasp.wt32_02 #Removed again. Pushing to two plates resulted in numerous crashes.

Describe the bug

EDIT: 191221
Added additional combined HA CC debug log / plate serial log entry.

HW:

  • 2 x wt32-sc01's with identical fw installed.
    Both plates are running rock solid without the push image automation.
    WiFi connection good/fair (appx. -58dbm)
    No mqtt failures, no PSram memory leaks or LVGL memory fragmentation issues when I check plate's info page.
  • HA supervised installed on a Intel Pentium NUC with ssd disk
  • Media player entities are Sonos speakers through HA's Sonos standard integration.

I'm experiencing issues with random plate crashes when pushing media player images to plate/plates.
Crashes seems to be completely random and unrelated to any other mqtt messages processed at plate at same time.

My test scenario is running a repeated non-stop playlist, which will push new images at some 3-5 min. intervals 24/7.
Prior to image push two seperate mqtt messages are sent to plate with artist/title. Last message typically send some 100-300 ms. before image is pushed. To ensure that plates mqtt queue doesn't choke on messages to be processed prior to the image, I'll keep automation delay at min. 1 second as I have now.

Automation has been refined a long the way during my test process.

  • Pushing images to two plates (in automation as two entities) without my added automation delay, gave numerous random plate crashes. Without added delay, and with two plates in automation, skipping rapidly through playlist will force a plate crash very quickly (often within 10-30 seconds).

  • With only one plate in automation and no delay, plate will still crash - but with larger intervals.

  • With one plate in automation and the 1 second delay, plate will crash at large intervals (typically many hours apart)

  • Latest currently runnning test version is with automation 'as is' in this issue report. Just with the twist that I patched CC init.py with a fixed path hasp/plates/command/ to update both plates at once with mqtt group commands.

This test scenario has now been running for some sixteen hours with only one crash/reboot at some five hours ago. So almost stable, but not completely stable yet.

Seems like the issue lies within files access/availability though on the HA side ? Check my first combined log entry (HA CC debug log and plate serial log). Here I tried to force a crash, rapidly (2-3 seconds interval) flicking back and forth in a playlist and hardly giving HA's entities/file writes any time to 'settle'. On two accounts file apparently can't be opened by cc and no conversion is done according to log. But cc still pushes an image to plate ?? Second time that happens plate crashes and reboots.

Debug log

First log entry is a combined HA CC debug log / plate serial log

Extra two 'plates only' serial logs at the end. Seems to be completely identical.



Combined HA cc debug log with plate serial log

2021-12-19 00:24:05 ERROR (SyncWorker_11) [custom_components.openhasp.image] Failed to open http://192.XXX.XXX.XXX:8123/api/media_player_proxy/media_player.kokken?token=2829b0fd83402e23858cf296bbc59aee7782786e30669e87cdfb6d063b82fd6f&cache=b0fdf6b115485cf0
2021-12-19 00:24:05 DEBUG (MainThread) [custom_components.openhasp] Push hasp/plates/command/p2b40.src with http://192.XXX.XXX.XXX:8123/api/openhasp/serve/d3787797bbb2123c253fd80da8de726c
2021-12-19 00:24:05 ERROR (MainThread) [custom_components.openhasp.image] Unknown image_id d3787797bbb2123c253fd80da8de726c
2021-12-19 00:24:05 ERROR (MainThread) [custom_components.openhasp.image] Unknown image_id d3787797bbb2123c253fd80da8de726c
2021-12-19 00:24:06 DEBUG (MainThread) [custom_components.openhasp] p2b41.max - Template("{{ state_attr('media_player.kokken','media_duration') | int }}") changed, updating with: 192
2021-12-19 00:24:06 DEBUG (MainThread) [custom_components.openhasp] p2b41.max - Template("{{ state_attr('media_player.kokken','media_duration') | int }}") changed, updating with: 192
2021-12-19 00:24:06 DEBUG (MainThread) [custom_components.openhasp] p2b41.val - Template("{{ state_attr('media_player.kokken','media_position') | int }}") changed, updating with: 13
2021-12-19 00:24:06 DEBUG (MainThread) [custom_components.openhasp] p2b41.val - Template("{{ state_attr('media_player.kokken','media_position') | int }}") changed, updating with: 13
2021-12-19 00:24:07 ERROR (SyncWorker_13) [custom_components.openhasp.image] Failed to open http://192.XXX.XXX.XXX:8123/api/media_player_proxy/media_player.kokken?token=2829b0fd83402e23858cf296bbc59aee7782786e30669e87cdfb6d063b82fd6f&cache=a6afe20ac4bc6ae8
2021-12-19 00:24:07 DEBUG (MainThread) [custom_components.openhasp] Push hasp/plates/command/p2b40.src with http://192.XXX.XXX.XXX:8123/api/openhasp/serve/99a25d250cafb7590ce8e58350b0766a

*** PLATES CRASHES HERE ***

2021-12-19 00:24:07 DEBUG (MainThread) [custom_components.openhasp] p2b41.max - Template("{{ state_attr('media_player.kokken','media_duration') | int }}") changed, updating with: 157
2021-12-19 00:24:07 DEBUG (MainThread) [custom_components.openhasp] p2b41.max - Template("{{ state_attr('media_player.kokken','media_duration') | int }}") changed, updating with: 157
2021-12-19 00:24:09 DEBUG (MainThread) [custom_components.openhasp] p2b41.max - Template("{{ state_attr('media_player.kokken','media_duration') | int }}") changed, updating with: 164
2021-12-19 00:24:09 DEBUG (MainThread) [custom_components.openhasp] p2b41.val - Template("{{ state_attr('media_player.kokken','media_position') | int }}") changed, updating with: 16
2021-12-19 00:24:09 DEBUG (MainThread) [custom_components.openhasp] p2b41.max - Template("{{ state_attr('media_player.kokken','media_duration') | int }}") changed, updating with: 164
2021-12-19 00:24:09 DEBUG (MainThread) [custom_components.openhasp] p2b41.val - Template("{{ state_attr('media_player.kokken','media_position') | int }}") changed, updating with: 16
2021-12-19 00:24:09 DEBUG (SyncWorker_11) [custom_components.openhasp.image] image_to_rgb565 out_image: /tmp/tmpkgfvllw9
2021-12-19 00:24:09 DEBUG (MainThread) [custom_components.openhasp] Push hasp/plates/command/p2b40.src with http://192.XXX.XXX.XXX:8123/api/openhasp/serve/efd946f49b70fe1d327f0e7955575988
2021-12-19 00:24:11 DEBUG (SyncWorker_9) [custom_components.openhasp.image] image_to_rgb565 out_image: /tmp/tmpc1updf6q
2021-12-19 00:24:11 DEBUG (MainThread) [custom_components.openhasp] Push hasp/plates/command/p2b40.src with http://192.XXX.XXX.XXX:8123/api/openhasp/serve/5b143b2263b321b58a2b6c944f282a3e
2021-12-19 00:24:16 DEBUG (MainThread) [custom_components.openhasp] Received LWT = online
2021-12-19 00:24:16 WARNING (MainThread) [custom_components.openhasp] Refreshing wt32_02


00:24:04.938 -> 0KPrompt > [18:24:05.382] [103664/105872  2] [27564/28256  3] MQTT RCV: hasp/plates/command/p2b40.src = http://192.XXX.XXX.XXX:8123/api/openhasp/serve/d3787797bbb2123c253fd80da8de726c
00:24:05.125 -> 0KPrompt > [18:24:05.431] [100500/101692  1] [27564/28272  3] ATTR: HTTP result 404
00:24:05.171 -> 0KPrompt > [18:24:06.282] [103664/105664  1] [27672/28272  3] MQTT RCV: hasp/wt32_01/command/p2b41.max = 192
00:24:06.015 -> 0KPrompt > [18:24:06.466] [103664/105664  1] [27608/28272  3] MQTT RCV: hasp/plates/command/p2b14.txt = White Christmas - Spotify Singles - Holiday, Recorded at Air St
00:24:06.250 -> 0KPrompt > [18:24:06.648] [103664/105664  1] [28004/28248  1] MQTT RCV: hasp/wt32_01/command/p2b41.val = 13
00:24:06.390 -> 0KPrompt > [18:24:06.708] [103664/105664  1] [27428/28156  3] MQTT RCV: hasp/plates/command/p2b15.txt = George Ezra
00:24:06.485 -> 0KPrompt > [18:24:07.688] [103664/105664  1] [27508/28244  3] MQTT RCV: hasp/plates/command/p2b40.src = http://192.XXX.XXX.XXX:8123/api/openhasp/serve/99a25d250cafb7590ce8e58350b0766a
00:24:07.423 -> 0KPrompt > CORRUPT HEAP: Bad head at 0x3f80701c. Expected 0xabba1234 got 0x3fbffff4
00:24:07.470 -> abort() was called at PC 0x4008e221 on core 1
00:24:07.470 -> 
00:24:07.470 -> ELF file SHA256: 0000000000000000
00:24:07.470 -> 
00:24:07.470 -> Backtrace: 0x40093cd8:0x3ffb1760 0x40093f51:0x3ffb1780 0x4008e221:0x3ffb17a0 0x4008e34d:0x3ffb17d0 0x4015715f:0x3ffb17f0 0x40152a45:0x3ffb1ab0 0x401529cd:0x3ffb1b00 0x40098751:0x3ffb1b30 0x40086c52:0x3ffb1b50 0x4008e119:0x3ffb1b70 0x4000bec7:0x3ffb1b90 0x400d62d2:0x3ffb1bb0 0x400d9a59:0x3ffb1bd0 0x400de7a9:0x3ffb1e00 0x400db20d:0x3ffb1e20 0x400dc2d1:0x3ffb1ef0 0x400e6a83:0x3ffb1f10 0x401cbe9b:0x3ffb1f30 0x400f3da5:0x3ffb1f50 0x400817e0:0x3ffb1f90 0x401373e3:0x3ffb1fb0 0x40094f56:0x3ffb1fd0
00:24:07.517 -> 
00:24:07.517 -> Rebooting...


Two extra 'plates only' serial logs


10:13:52.779 -> 0KPrompt > [04:13:53.798] [104708/106308  1] [27780/28324  2] MQTT RCV: hasp/plates/command/p2b14.txt = Feliz Navidad
10:13:53.248 -> 0KPrompt > [04:13:53.813] [104708/106308  1] [27780/28324  2] HASP: txt is obsolete, use text instead
10:13:53.248 -> 0KPrompt > [04:13:53.867] [104708/106516  1] [27688/28328  3] MQTT RCV: hasp/plates/command/p2b15.txt = José Feliciano
10:13:53.294 -> 0KPrompt > [04:13:53.882] [104708/106516  1] [27688/28328  3] HASP: txt is obsolete, use text instead
10:13:53.340 -> 0KPrompt > [04:13:57.333] [104708/106516  1] [28072/28332  1] MQTT RCV: hasp/wt32_01/command/p2b40.src = http://192.xxx.xxx.xxx:8123/api/openhasp/serve/9a32464e4592396a48b1076f6e139ed7
10:13:56.806 -> 0KPrompt > 9CCORRUPT HEAP: Bad head at 0x3f80001c. Expected 0xabba1234 got 0x3fbffff4
10:13:56.806 -> abort() was called at PC 0x4008e221 on core 1
10:13:56.806 -> 
10:13:56.806 -> ELF file SHA256: 0000000000000000
10:13:56.806 -> 
10:13:56.806 -> Backtrace: 0x40093cd8:0x3ffb1760 0x40093f51:0x3ffb1780 0x4008e221:0x3ffb17a0 0x4008e34d:0x3ffb17d0 0x4015715f:0x3ffb17f0 0x40152a45:0x3ffb1ab0 0x401529cd:0x3ffb1b00 0x40098751:0x3ffb1b30 0x40086c52:0x3ffb1b50 0x4008e119:0x3ffb1b70 0x4000bec7:0x3ffb1b90 0x400d62d2:0x3ffb1bb0 0x400d9a59:0x3ffb1bd0 0x400de7a9:0x3ffb1e00 0x400db20d:0x3ffb1e20 0x400dc2d1:0x3ffb1ef0 0x400e6a83:0x3ffb1f10 0x401cbe9b:0x3ffb1f30 0x400f3da5:0x3ffb1f50 0x400817e0:0x3ffb1f90 0x401373e3:0x3ffb1fb0 0x40094f56:0x3ffb1fd0
10:13:56.852 -> 
10:13:56.852 -> Rebooting...



07:53:56.593 -> 0KPrompt > [01:53:58.116] [103476/107708  3] [27712/28292  3] MQTT RCV: hasp/plates/command/p2b15.txt = Meghan Trainor
07:53:56.825 -> 0KPrompt > [01:53:58.131] [103476/107708  3] [27712/28292  3] HASP: txt is obsolete, use text instead
07:53:56.871 -> 0KPrompt > [01:53:59.386] [103476/107708  3] [27712/28292  3] MQTT RCV: hasp/plates/command/p2b40.src = http://192.XXX.XXX.XXX:8123/api/openhasp/serve/d396ad860387af4d1fa954135680a1ad
07:53:58.096 -> 0KPrompt > CCORRUPT HEAP: Bad head at 0x3f80001c. Expected 0xabba1234 got 0x3fbffff4
07:53:58.143 -> abort() was called at PC 0x4008e221 on core 1
07:53:58.143 -> 
07:53:58.143 -> ELF file SHA256: 0000000000000000
07:53:58.143 -> 
07:53:58.143 -> Backtrace: 0x40093cd8:0x3ffb1760 0x40093f51:0x3ffb1780 0x4008e221:0x3ffb17a0 0x4008e34d:0x3ffb17d0 0x4015715f:0x3ffb17f0 0x40152a45:0x3ffb1ab0 0x401529cd:0x3ffb1b00 0x40098751:0x3ffb1b30 0x40086c52:0x3ffb1b50 0x4008e119:0x3ffb1b70 0x4000bec7:0x3ffb1b90 0x400d62d2:0x3ffb1bb0 0x400d9a59:0x3ffb1bd0 0x400de7a9:0x3ffb1e00 0x400db20d:0x3ffb1e20 0x400dc2d1:0x3ffb1ef0 0x400e6a83:0x3ffb1f10 0x401cbe9b:0x3ffb1f30 0x400f3da5:0x3ffb1f50 0x400817e0:0x3ffb1f90 0x401373e3:0x3ffb1fb0 0x40094f56:0x3ffb1fd0
07:53:58.189 -> 
07:53:58.189 -> Rebooting...



bad link to repository

Version of the custom_component

Configuration

Add your config here.

Describe the bug

A clear and concise description of what the bug is.

Debug log


Add your logs here.

```Logger: homeassistant.components.hassio
Source: components/hassio/__init__.py:454
Integration: Hass.io (documentation, issues)
First occurred: 4:20:07 PM (1 occurrences)
Last logged: 4:20:07 PM

Invalid config for [openhasp]: required key not provided @ data['openhasp']['openhasp']['objects']. Got None required key not provided @ data['openhasp']['openhasp']['pages']. Got None required key not provided @ data['openhasp']['openhasp']['topic']. Got None. (See /config/configuration.yaml, line 27).

Dimmer Lights: Can't toggle light on if no previous brightness. FW & CC issue

Version of the custom_component

0.6.2

Configuration

N/A, configure using card entity frontend.

Describe the bug

IF turning on light for first time since restart, HA will not turn on light on as there was no previous brightness known.

Occurs after resetting both HA and Plate.

Debug log

HA Log:

2021-08-31 16:01:46 WARNING (MainThread) [homeassistant.helpers.template] Template variable warning: 'mappingproxy object' has no attribute 'brightness' when rendering '{{ states.light.b3_lights.attributes.brightness }}'

Telnet Log:

[08:03:13.770][96656/99960  3][35304/35520  1] MQTT RCV: hasp/b3/command/output12 = {"state": true, "brightness": 0}
[08:03:13.776][96656/98308  1][35304/35520  1] GPIO: Dimmer => ef 02 00 ed
[08:03:13.781][95104/96376  1][35304/35520  1] MSGR: GROUP 1 value 0 (0-255)
[08:03:13.791][93552/94636  1][35304/35520  1] MQTT PUB: output12 => {"state":"off","brightness":0}

OpenHASP

HASwitchPlate/openHASP#212

Question/Feature: Plate MQTT Name from inside template inside Event Handler?

Assuming we start with the "Simple Page Navigation" openHASP example...

Perhaps this is already possible, but I haven't figured out a way to make it work.

Let's say I have:

# configuration.yaml
openhasp:
  plate_foo:
    objects: !include openhasp.yaml
  plate_bar:
    objects: !include openhasp.yaml
  plate_baz:
    objects: !include openhasp.yaml
# openhasp.yaml
     - obj: "p0b2"            
       event:            
         "down":             
           - service: persistent_notification.create
             data:                         
                message: Some way to get plate name? Maybe inside {{ state.state }}                

My goal is to handle the "home" (back) action via home-assistant, rather than via the built in openhasp action:back function.

image

This way I can have plates in different rooms that start on their own "default" page, but keep all of the configuration global.

When pressing "home" on the master bedroom plate, home would be page 1 (the default).
But when pressing "home" on the entry plate, home would actually be page 4
And "home" on the living room plate would be page 3.

It's straight forward to send the "go to page" function but no idea how I can get the current plate name.

  - obj: "p0b2"                                                                    
    event:                             
      "down":               
        - service: mqtt.publish
          data:
            topic: hasp/{{ HOW DO I GET THE PLATE NAME }}/command/page
            payload: '5'

Since the openhasp-custom-component is just responding to an MQTT request, the custom component must know which plate is involved to dispatch to the correct event handler, but I haven't figured out how to pull that into a template to respond with an MQTT message back to that same plate.

Create touch binary sensor

A binary sensor "Screen touched" which should change to True in the moment somebody touches the screen, and reverts to false after 1s.

Useful to automate backlight levels.

Integration cannot be setup in HomeAssistant 2021.12

Version of the custom_component

0.6.3

Describe the bug

Integration doesn't start since HomeAssistant was upgraded to version 2021.12 (see error log).
Removing integration and rebooting HA core results in HASP discovery, but integration can't be added with the same error.
Removing and re-adding integration gives configuration flow error.

Debug log


Logger: homeassistant.config_entries
Source: custom_components/openhasp/__init__.py:409 
Integration: openHASP (documentation, issues) 
First occurred: 16:09:56 (1 occurrences) 
Last logged: 16:09:56

Error setting up entry plate for openhasp
Traceback (most recent call last):
  File "/usr/src/homeassistant/homeassistant/config_entries.py", line 313, in async_setup
    result = await component.async_setup_entry(hass, self)  # type: ignore
  File "/config/custom_components/openhasp/__init__.py", line 251, in async_setup_entry
    await component.async_add_entities([plate_entity])
  File "/usr/src/homeassistant/homeassistant/helpers/entity_platform.py", line 382, in async_add_entities
    await asyncio.gather(*tasks)
  File "/usr/src/homeassistant/homeassistant/helpers/entity_platform.py", line 613, in _async_add_entity
    await entity.add_to_platform_finish()
  File "/usr/src/homeassistant/homeassistant/helpers/entity.py", line 747, in add_to_platform_finish
    await self.async_added_to_hass()
  File "/config/custom_components/openhasp/__init__.py", line 409, in async_added_to_hass
    self.hass.components.mqtt.async_publish(
TypeError: async_publish() missing 1 required positional argument: 'payload'

YAML support for the JSONL files

Is your feature request related to a problem? Please describe.
No, not a problem

Describe the solution you'd like
I see that the configuration file for the plate can be written in plain JSON, that will then be translated to JSONL: https://haswitchplate.github.io/openHASP-docs/0.6.2/integrations/home-assistant/howto/#json-files

My immediate question was: why not YAML too? Since the plugin already translates from JSON to JSONL and it is possible to translate from yaml to JSON I see no reason why this could not be possible.

Describe alternatives you've considered
Nothing really

Additional context
The advantages of this is that YAML is less verbose and easier to write by hand than JSON

Backlight turns back on if turned off manually

Version of the custom_component

a7fdd68

Configuration

kép

{"page":0,"id":6,"obj":"obj","swipe":1,"x":0,"y":0,"h":35,"w":240,"opacity":0,"radius":0,"comment":"swipe-area-at-top"}
      - obj: "p0b6"  # backlight turn off long-press
        event:
          "long":
            - service: light.turn_off
              entity_id: "light.plate_4_backlight"

Describe the bug

I manually turn off the backlight of the plate by long-touching an object on the plate mapped to HA's light.plate_4_backlight switch.
After the plate changes to short idle, the light turns back on by itself.

If the user manually turns off the backlight at any time, no idle state change should turn it back on.

Debug log

2021-07-07 19:41:18 DEBUG (MainThread) [custom_components.openhasp.light] received backlight plate_4 backlight: {'state': False, 'brightness': 255}
2021-07-07 19:42:19 DEBUG (MainThread) [custom_components.openhasp.light] Idle state for plate_4 backlight is short - Dimming to 125; Backlight to 1
2021-07-07 19:42:20 DEBUG (MainThread) [custom_components.openhasp.light] received backlight plate_4 backlight: {'state': True, 'brightness': 125}

Feature request: use component-local variables in the configuration

Is your feature request related to a problem? Please describe.
Current way of creating configurations supports templates which is great but sometimes it becomes quite hard to maintain changes to objects belonging to the same functionality or entity in Home Assistant. The same entity_id is referenced uniquely a lot of times.

For example in the thermostat/climate example climate.thermostat_1 is referenced 52 times.
In media player example media_player.sound_my_room is referenced 61 times.

This is even more true for pXbY object references, where all objects are on the same page. X could be a variable which could be specified at the beginning, and changing objects page can be done in a single place (likewise in the jsonl file, where page can be specified only once for the following objects).

It would be good to be able to use this for any repetitive part of the configuration, not just entity ids or page numbers.

Would make it easier to share code and multiply it to pages/plates simply by having to adjust only once the variables at the beginning.

Describe the solution you'd like
In the plate configuration, under the plate identifier slug (same level with objects) have a dictionary with user-defined variables which could be referenced in the configuration.
When parsing the configuration, resolve the variables back to their values before applying the template engine of HA. I think a programatic search and replace (regex?) would be enough.
Config should be possible something like:

openhasp:
  plate35:
    variables:
      - climate_thermostat_1: "climate.thermostat_room_1"  # assign to variable climate_thermostat_1 the name of entity in HA
      - _page_thermostat_: 6
      - media_player_1: "media_player.sound_my_room" 
      - media_player_sources: '["TV","Jazzy","Rádió 1","Retró","Sláger","Best FM","Forrás","Jzy Soul","Info"]'
      - _page_media_player_: 3

    objects:  # resolve the variables within the templates 
      - obj: "p_page_thermostat_b41"  # on/off switch
        properties:
          "val": "{{ 0 if (is_state('climate_thermostat_1', 'off') or is_state('climate_thermostat_1', 'unavailable')) else 1 }}"
        event:
          "down":
            - service_template: >
                {% if val == 0 -%}
                climate.turn_on
                {% else -%}
                climate.turn_off
                {% endif -%}
              entity_id: "climate_thermostat_1"

      - obj: "p_page_media_player_b2" # artist
        properties:
          "text": "{{ state_attr('media_player_1','media_artist') if state_attr('media_player_1','media_artist') else '-' }}"

      - obj: "p_page_media_player_b40" # sources buttons
        properties:  
          "options": media_player_sources
          "toggle": '{{ 1 if ( not state_attr("media_player_1","source") in media_player_sources) or (is_state("media_player_1","unavailable")) -}}'
          "val": >
            {% if not (is_state('media_player_1','unavailable')) -%}
            {% if not state_attr(media_player_1','source') in media_player_sources -%}-1{% else -%}
            {% for source in media_player_sources -%}
            {{loop.index - 1 if source == state_attr('media_player_1','source') }}
            {%-endfor%}
            {%- endif %}
            {%- endif %}

Describe alternatives you've considered
Currently the users have to search and replace all occurences in the config, when applying the examples to their plates, or when duplicating/moving code from one plate/page to another.

Additional context
N/A

Character encoding for properties

Looks like some properties need special character encodings:
HASwitchPlate/openHASP#105
What I was trying to do:
For object:
{"obj":"dropdown","id":4,"x":75,"y":235,"w":90,"h":30,"options":""}
Trying to populate the options property programmatically with the hvac_modes of the climate:

      - obj: "p2b4"
        properties:
          "options": >
            {% for mode in state_attr('climate.my_thermostat','hvac_modes') %}
            {{ mode }}\n{%- if not loop.last %}
            {%- endif %}
            {%- endfor %}

Feature request: pages max and page loop

A way to specify how many pages are configured on the plate. Looks like hasp-lvgl only sends data about how many pages are maximum possible on the plate, not the number of pages containing objects. This currently results in the possibility to also switch to empty pages with next and previous.

Having a page interval configured would allow us not to go beyond that with previous and next, so the end-user doesn't get surprised by empty pages.
Having an optional loop setting would allow for navigation to the first page after the last one when pressing next, and reversely to the last page after the first one when pressing prev.

Service to change page by the number directly would allow to jump to pages outside the interval, this would be helpful to show pages the user normally can't navigate to, for exceptional cases when warning messages have to be sent out like when on fire alarm, or handle special cases when a notification has to be dismissed first etc. Navigating away from this with prev/next would jump to the next page from the interval according to the loop above.
This would also make a big difference between page next/prev and change page services, and would add a plus justification why we need both types of services.

push_image service not working

Version of the custom_component 0.6.3

Configuration

service: openhasp.push_image
target:
  entity_id: openhasp.plate
data:
  image: https://megawubs.duckdns.org/local/images/image.png
  obj: p2b17
{"page":1,"id":17,"obj":"img","x":230, "y":30, "w":70,"h":70, "border_color":"white", "border_opa":0, "src":"/littlefs/genietmomentjes.png", "auto_size":0}

Describe the bug

I'm unable to push an image to an image obj on my m5stack core 2. It doesn't matter if I add a url or path from /littlefs/*.png. The initial image is shown, but i'm unable to update it.

Debug log


[139951158890064] Error handling message: invalid url for dictionary value @ data['image']. Got None

current page not updated

Current page number should be also updated from hasp/plate/state/page (and maybe hasp/plate/state/statusupdate) because it looses sync if someone changes page from HA for example:

- alias: lanbon-back-to-page-1-after-5min
  initial_state: 'on'
  trigger:
    - platform: state
      entity_id: sensor.plate_idle
      from: 'off'
      for: "00:05:00"
  action:
    - service: number.set_value
      data:
        value: '1'
      target:
        entity_id: number.plate_page

if the page was left at 3 when the automation above runs and sets the page on hasp-lvgl back to 1, when somebody touches the next page button, it will jump directly to page 4.

image not always resizing on cast

Version of the custom_component

0.63

Configuration

Nothing in yaml yet I am just testing image casting via thgis service call

service: openhasp.push_image
data:
  image: http://hass.lan:8123{{state_attr('media_player.kitchen', 'entity_picture')}}
  obj: p3b1
  width: 320
  height: 320
target:
  entity_id: openhasp.plate50

## Describe the bug
I am casting from my media player entity (it is a logitech media server using the HA squeezebox client). I have set up a 320x320 image on my wt32-sc01 device as a test.

Usually the pic is scaled to 320x320, but sometimes it is not, and appears quite a bit smaller.


## Debug log

<!-- To enable debug logs check this https://www.home-assistant.io/components/logger/ -->

```text
[00:23:20.420][104036/106664  2][36544/36592  1] MQTT RCV: hasp/plate50/command/p3b1.src = http://192.168.20.254:8123/api/openhasp/serve/bb7520125e85dc25c6c33aff637b79c9




Push image not working with SSL cert/key active on HA

openHASP 0.6.3 - HA supervised core-2021.10.5

HA Configuration

homeassistant:
  allowlist_external_dirs:
    - /config
    - /share
    - /tmp
  
  allowlist_external_urls:
    - "https://www.life360.com/img/user_images/"

  internal_url: http://192.X.X.X:8123
  external_url: https://my_personal.duckdns.org

http:
  ssl_certificate: /ssl/fullchain.pem
  ssl_key: /ssl/privkey.pem

HA direct service call used to test

service: openhasp.push_image
data:
  image: https://my_personal.duckdns.org/local/Mikkel.png
  obj: p5b40
  width: 50
  height: 50
target:
  entity_id: openhasp.wt32_01

Describe the bug

Using duckdns to gain access to HA from external network, causes issues with paths/permissions using openhasp.push_image
Using SSL on HA will also disable the possibility to gain local access to HA via http://local_ip_address:port. Only access via https://local_ip_address:port is possible with the expected insecure browser warning.
Installing reverse proxy will solve the local access issue with url's, but not necessarily issue with permission/access rights to HA's folders.

Seems like converted image is never recieved. Test picture is tested to be accessible via browser using same url
Most likely permission issues with the api/openhasp/serve path. Can't add that specific path to HA's allowlist_external_dirs, as it's not exposed to HA.
Also noted that URL pushed to openhasp device is the internal_url from HA configuration. Could also be an issue, as device only will be able to access HA via https URL's (alternatively external duckdns url)

Note: If SSL is deactivated in HA, everything works perfectly without issues at all.

Debug log

2021-12-04 21:20:30 DEBUG (SyncWorker_3) [custom_components.openhasp.image] image_to_rgb565 out_image: /tmp/tmpdghbzkiu
2021-12-04 21:20:30 DEBUG (MainThread) [custom_components.openhasp] Push hasp/wt32_01/command/p5b40.src with http://my.local.ip.address:port/api/openhasp/serve/4ab482c80ba29d55629f5a44f9e1e0f7


wt32-sc01 device log:

21:19:59.876 -> 0KPrompt > MQTT RCV: hasp/wt32_01/command/p5b40.src = http://my.local.ip.address:port/api/openhasp/serve/4ab482c80ba29d55629f5a44f9e1e0f7
21:20:30.415 -> 0KPrompt > ATTR: HTTP result -5



Consider a less rigid version checking policy

Is your feature request related to a problem? Please describe.
Shortly after I found openHasp, I ran into a problem with the firmware: my mqtt hostname didn't fit in the allocated memory and the plates could not connect.
See: HASwitchPlate/openHASP#265

The fix was quickly rolled out and I was able to test a revised build soon after opening the issue.
However, I was quickly hit with another issue: the test firmware was running version 0.7 and I was unable to discover the device and integrate it with Home Assistant.

This is because the device config/registration logic requires an exact match:

I installed the custom component via HACS and chose the main release as the most recent release had a 0.6 in the tag.
https://hacs.xyz/docs/publish/integration#github-releases-optional

I was hoping that the main branch would work with 0.7 devices since it appeared that there were releases meant specifically for 0.6 devices.

Nope. Even the main code wants 0.6 devices:

It was an easy fix: I just modified the custom component install:

root@ha-container [/custom_components/openhasp]# diff const.py const.py.orig 
5,8c5
< # 2022-01-09: trying to get things working with custom FW that I have on the test plate
< #MINOR = "6"
< MINOR = "7"
---
> MINOR = "6"

I was then able to add the latest 0.7 device and have been developing various UI and HA automations against a few different openHasp devices all running some 0.7 build. SO far, no issues with the custom component and the devices.

That got me thinking... how strict does the version check really need to be?

Describe the solution you'd like

This has been discussed on and off on discord over the past few days but I thought I'd create a dedicated thread / issue to track all discussion in a place where more people can see it / comment. 2 weeks from now, nobody is going to be searching through discord for the conversation(s)!

I was initially planning on a simple pull request that would change the version comparison to checking if the openHasp device that was just discovered had a firmware in a list of supported versions. This approach is simple / has the least invasive code changes but is far from ideal. Who is going to maintain the list? What level of "works" will be needed to consider a firmware 'supported'?

Describe alternatives you've considered

Other suggestions:

  • Only check the major version, all versions within the same major version should be accepted, it's up to the users to check logs to see if anything did go wrong
  • If the reported firmware is more than 1 minor version, don't accept. E.G.: CC wants .6, device has .7 and since math.abs(.6-.7) <= .1, the device is accepted. If the CC wants .6 but the device has .4, that's a delta of 2 and 2 > 1 so device is rejected.
  • Semantic versioning in the yyyy-mm format to track the same version naming scheme that home assistant uses, use similar logic as above and only accept devices that have firmware +/- a few months from the desired...

Additional context

Feature request: separate backlight level setting for awake and idle

Backlight level currently only has one slider, which acts on the awake level.
A bit confusing though that the slider position goes down to the value of idle brightness, when the plate is idle - the slider is showing the actual brightness value, whilst it's setting the awake brightness level.

As we had earlier in the component config, we could offer a way to configure default levels:

  • max backlight level, default for awake if not set manually
  • min backlight level, default for idle if not set manually

To impose some practical constraints for accidental or unwanted settings (one may drag the slider to 0 and then misunderstand why the screen turned off completely; max limit would help the owner to save for long-term burn-in or power consumption).

This would require two separate sliders, either by implementing two virtual lights, or alternatively by re-using some other property of light component like white_value (maybe not a good idea as it may conflict with other stuff in HA).

Feature request: link event and properties between objects directly

Is your feature request related to a problem? Please describe.
Currently properties of an object can be linked only to values coming from entities in Home Assistant. We also need a way to directly link properties of an object to events coming from the (same) plate's other objects too.

Describe alternatives you've considered
For example, I have a tabview with 3 tabs, and a label:

{"page":3,"id":26,"obj":"label","x":90,"y":220,"w":60,"h":30,"text":"#000000 \u2022# #909090 \u2022# #909090 \u2022#","text_font":24,"align":"center","text_color":"grey","border_width":0}
{"page":3,"id":30,"obj":"tabview","x":0,"y":235,"w":240,"h":80,"btn_pos":0,"bg_opa":0,"border_width":0,"radius":0}
{"page":3,"id":31,"obj":"tab","parentid":30}
{"page":3,"id":32,"obj":"tab","parentid":30}
{"page":3,"id":33,"obj":"tab","parentid":30}

Switching between the tabs is done by swiping left and right. The label shows 3 dots, the goal is to highlight the the dot corresponding to the tab.

kép
kép
kép

This can be achieved with some trickery:

  • I either have to create an input_select in HA in order to just track the state of the tabview, and based on its value, set the label property. This is an overkill...
  • I can directly send MQTT messages using mqtt.publish to the plate's topic (see example below). The problem is that this kind of communication goes outside the component.
      - obj: "p3b30"  # tab dots
        event:
          "changed":
            - service: mqtt.publish
              data:
                topic: hasp/plate_halo/command/p3b26.text
                payload: >
                  {% if val == 0 %}
                  {{ "#000000 \u2022# #909090 \u2022# #909090 \u2022#" | e }}
                  {%-elif val == 1 %}
                  {{ "#909090 \u2022# #000000 \u2022# #909090 \u2022#" | e }}
                  {%-elif val == 2 %}
                  {{ "#909090 \u2022# #909090 \u2022# #000000 \u2022#" | e }}
                  {% endif %}

Describe the solution you'd like
Since data goes back to the same plate, something more efficient could be implemented, like:

      - obj: "p3b30"  # tab dots
        event:
          "changed":
            - obj_properties: "p3b26"
                "text": >
                  {% if val == 0 %}
                  {{ "#000000 \u2022# #909090 \u2022# #909090 \u2022#" | e }}
                  {%-elif val == 1 %}
                  {{ "#909090 \u2022# #000000 \u2022# #909090 \u2022#" | e }}
                  {%-elif val == 2 %}
                  {{ "#909090 \u2022# #909090 \u2022# #000000 \u2022#" | e }}
                  {% endif %}

Additional context
https://discord.com/channels/538814618106331137/692393568266092617/852874097653186579
https://haswitchplate.github.io/openHASP-docs/0.6/integrations/home-assistant/sampl_conf/#generic-thermostatclimate

Feature request: allow condition in events

Is your feature request related to a problem? Please describe.
I'd like to display a message on the plate when a button is pressed, but only when the sun is up.

Describe the solution you'd like
Use conditions, pretty much like in automations, in object events.

      - obj: "p2b2"  # light-switch toggle button warning
        event:
          "down":
            - condition: template
              value_template: "{{ (states('switch.plate_4_switch_12') == 'on' and state_attr('sun.sun','elevation') > 15) }}"
            - service: openhasp.command
              target:
                entity_id: openhasp.plate_4
              data:
                keyword: jsonl
                parameters: >-
                  {"page":2,"id":200,"obj":"obj","x":5,"y":55,"w":230,"h":160,"shadow_opa":140,"shadow_color":"black","shadow_width":20,"shadow_spread":0}
                  {"page":2,"id":201,"obj":"label","parentid":200,"x":10,"y":10,"w":215,"h":110,"text_font":24,"align":"center","text":"\uE595 It's daytime!\nPlease pull up\nthe covers instead!"}
                  {"page":2,"id":202,"obj":"btn","parentid":200,"x":20,"y":110,"w":190,"h":40,"text":"Thank you: a greener world","mode":"break","align":"center"}

Describe alternatives you've considered
Putting this in a script outside the component. But this makes the whole thing very clunky if you have lots of things like this.

Additional context
Add any other context or screenshots about the feature request here.

Delay between HA and openHASP can cause loops when not using groupid

Perform all steps below and tick them with [x]

  • Check the related part of the Documentation
  • Update openHASP to the latest version
  • Reproduce the issue and describe all steps

Describe the bug

When turning on the light, the command is sent from the plate to HA to turn on the light. If you are using the openHASP custom component to set state values for buttons, they can sometimes lag out and cause small loops.

  1. Use plate to turn on light, MQTT message to HA, button state changes.
  2. HA sees that the light is OFF, so sets button state to OFF, triggering another MQTT message.
  3. HA receives the ON command, turns on light, sets button state to ON.

This causes the light to flicker a few times, until it finds a normalised states. Unfortunately it can finally decide to settle in the OFF state, so it is impossible to turn lights on and keep on using the plate in production with this bug. Usually a reset of the plate (remove from wall and reconnect) can resolve this. Will usually occur a few days later.

To Reproduce

I think this could potentially be caused by a delay caused in WiFi messages and MAY be more pronounced the further your plate is away from the WiFi router.
Provide a small, independent code sample that can be used to reproduce the issue.
Format the code like this:

{"comment":" ----------- Light Button ------------"}
{"page":1,"id":2,"obj":"btn","x":5,"y":40,"w":73,"h":73,"toggle":true,"text":"\uE335","text_font":40,"align":1,"shadow_color":"#000000","shadow_width": 16,"shadow_ofs_y":2, "shadow_ofs_x":2}
{"page":1,"id":3,"obj":"slider","x":94,"y":65,"w":126,"h":20, "min":0,"max":255, "opacity": 255,"shadow_color":"#000000","shadow_width": 16,"shadow_ofs_y":2, "shadow_ofs_x":2}
{"page":1,"id":4,"obj":"btn","x":5,"y":40,"w":230,"h":73,"toggle":false,"text":"\uE335","text_font":40,"align":1,"hidden":true, "click":false,"shadow_color":"#000000","shadow_width": 16,"shadow_ofs_y":2, "shadow_ofs_x":2}
      - obj: "p1b2" #light toggle button
        properties:
          "val": '{{ 1 if states("light.b1_lights") == "on" else 0 }}'
          "text": '{{ "\uE6E8" if is_state("light.b1_lights", "on") else "\uE335" | e }}'
        event:
          "up":
            - service: light.toggle
              data_template:
                brightness: '{{ states("input_number.b1_lights") }}'
              target:
                entity_id: light.b1_lights
      - obj: "p1b3" #slider
        properties:
          "val": '{{ states("input_number.b1_lights") }}'
          "opacity": '{{ "255" if is_state("light.b1_lights", "on") else "150" | e }}'
        event:
          "up":
            - service: input_number.set_value
              target:
                entity_id: input_number.b1_lights
              data_template:
                value: "{{ val }}"
            - service: light.turn_on
              data_template:
                brightness: "{{ val }}"
              target:
                entity_id: light.b1_lights
      - obj: "p1b4" #HIDER
        properties:
          "hidden": '{{ true if states("light.b1_lights") == "on" else false }}'
          "click": '{{ false if states("light.b1_lights") == "on" else true }}'
        event:
          "up":
            - service: light.toggle
              data_template:
                brightness: '{{ states("input_number.b1_lights") }}'
              target:
                entity_id: light.b1_lights

Telnet Logs:
Logs.txt

Expected behavior

Lights to not flicker and to turn on.

Noting that the use of GROUPID will remove this issue (I will start to update my jsonl pages), unfortunately until the last brightness is passed through (issue:99) the lights turn on at full brightness which is not a great solution for production use cases.

Screenshots or video

20210831_075526_1.mp4

Feature request: A few more config options

Just like Antiburn, please expose a few more configuration entities to HA:

  • page number as input_number (box mode, min/max set to 0/12)
  • long idle as input_number (box mode, 0/3600)
  • short idle as input_number (box mode, 0/3600)
  • reboot as switch

Idles for example, would make life a little easier in things like this, when we want to dynamically change the idle modes based on day/night/lightsensor/etc.

Missing and obsolete events

Version of the custom_component

0.5.0 😃

Configuration

n/a

Describe the bug

hold and release events are missing from the HASP_EVENTS list:

HASP_EVENT = "event"
HASP_EVENT_ON = "on"
HASP_EVENT_OFF = "off"
HASP_EVENT_DOWN = "down"
HASP_EVENT_UP = "up"
HASP_EVENT_SHORT = "short"
HASP_EVENT_LONG = "long"
HASP_EVENT_CHANGED = "changed"
HASP_EVENT_RELEASE = "release"
HASP_EVENTS = (
    HASP_EVENT_ON,
    HASP_EVENT_OFF,
    HASP_EVENT_DOWN,
    HASP_EVENT_UP,
    HASP_EVENT_SHORT,
    HASP_EVENT_LONG,
    HASP_EVENT_CHANGED,
)

Debug log

2021-04-18 03:41:37 WARNING (MainThread) [custom_components.openhasp] Could not handle event '{"event":"hold"}' on 'hasp/lanbon123/state/p1b7'
2021-04-18 03:41:38 WARNING (MainThread) [custom_components.openhasp] Could not handle event '{"event":"release"}' on 'hasp/lanbon123/state/p1b7'

Note

HASP_EVENT_SHORT = "short" doesn't exist anymore and can be removed from the schema.

Moodlight colors are forgotten between restarts of HA and plate

Version of the custom_component

0.6.0 main f597d75

Configuration

N/A

Describe the bug

Problem #12 (comment) still exists on Lanbons and current CC versions:

  • turn on moodlight from HA entity (the one created by this component)
  • select a nice color and brightnesd, and test by turning the moodlight on and off repeatedly from HA - everything's fine at this point
  • turn the moodlight OFF
  • restart HA and reboot or power-cycle plate in the same time
  • try turning on moodlight: color/brightness forgotten + error below

The real world case is very simple: a power outage can restart plates and HA in the same time.

Debug log


2021-05-31 13:36:09 ERROR (MainThread) [homeassistant.components.websocket_api.http.connection] [140523982527840] color_hs_to_RGB() argument after * must be an iterable, not NoneType
Traceback (most recent call last):
  File "/usr/src/homeassistant/homeassistant/components/websocket_api/commands.py", line 167, in handle_call_service
    await hass.services.async_call(
  File "/usr/src/homeassistant/homeassistant/core.py", line 1481, in async_call
    task.result()
  File "/usr/src/homeassistant/homeassistant/core.py", line 1516, in _execute_service
    await handler.job.target(service_call)
  File "/usr/src/homeassistant/homeassistant/helpers/entity_component.py", line 213, in handle_service
    await self.hass.helpers.service.entity_service_call(
  File "/usr/src/homeassistant/homeassistant/helpers/service.py", line 658, in entity_service_call
    future.result()  # pop exception if have
  File "/usr/src/homeassistant/homeassistant/helpers/entity.py", line 726, in async_request_call
    await coro
  File "/usr/src/homeassistant/homeassistant/helpers/service.py", line 695, in _handle_entity_call
    await result
  File "/usr/src/homeassistant/homeassistant/components/light/__init__.py", line 376, in async_handle_light_on_service
    await light.async_turn_on(**params)
  File "/config/custom_components/openhasp/light.py", line 507, in async_turn_on
    color_util.color_hs_to_RGB(*self._hs),
TypeError: color_hs_to_RGB() argument after * must be an iterable, not NoneType

Add a version check

Is your feature request related to a problem? Please describe.

To improve clarity, we could implement a warning message when the CC version get out-of-sync with the firmware version of a plate.

Describe the solution you'd like

Can the CC check the HASP version in statusupdate at start?
Could it warn about incompatible plate versions? i.e. different major.minor version

Describe alternatives you've considered

Keeping the plate and CC versions in sync can be tough and currently it isn't obvious to the user.
Since the plates can be any version and the HA CC is central, all plates should be checked to be in line with the current CC version.

Additional context

n/a

Feature request: wrapper service for any command

Is your feature request related to a problem? Please describe.
openHASP supports a handful of commands. Some of them would be useful in HA automations, like setting dim values or change theme based on day/night, etc.

Instead of having services in HA translated to each command, we could use one single service which could wrap them all in one.

Describe the solution you'd like
A universal service which would accept 2 or 3 parameters:

  • command topic (if the firmware accepts commands on other topics also, like config)
  • keyword
  • parameter(s)
    - service:  openhasp.command
      target:
        entity_id: openhasp.plate35
      data:
        command: 'config'
        keyword: 'gui'
        parameters: '{"idle2":0}'

If the config or any other commands except command would be deprecated, only the keyword and parameters would suffice.

Describe alternatives you've considered
Sending commands directly to the plate is currently possible outside the component like this example:

    - service: mqtt.publish
      data:
        topic: hasp/plate35/config/gui
        payload: '{"idle2":0}'

Instead of this, it would be a lot better to wrap this inside the component like above, as they can be used with automations and blueprints more consistently. You can reference to a plate universally using it's entity_id, instead of having to keep separately track of MQTT topics belonging to that plate.

Additional context
Extra benefit is that commands list can freely change on the firmware side, the component doesn't have to implement new services for them if they are requested, changed or added.

Page number entity

Version of the custom_component

917615d

Configuration

N/A

Describe the bug

After this fix: #88
Number entity experiences the following symptoms:

  • After reloading the integrattion the entity remains unavailable. To fix, need to restart plate.
  • Restarting the plate doesn't go back to the page it was before restart, instead, jumps to page 1. This happens even if integration is not reloaded (just change to any other page and restart the plate, after connecting back, it will show page 1 and number will update to 1). Earlier the plate restored the page it was on, before reboot, which was very convenient.

Debug log

N/A

Service to update all data when back online / ha restart

After reboot of hasp-lvgl, current data is lost.
However, on MQTT availability state can be tracked, so a simple automation which could check state from Unavailable to Available could push all the related data to reflect the state.

load_pages service doesn't load the file correctly

This is my config file for Lanbon L8 and hasp-lvgl 0.4.0: pages_v0.jsonl

If I load it using the service:

service: hasp_lvgl.load_pages
data:
  path: /config/hasp-lvgl/pages_v0.jsonl
target:
  entity_id: hasp_lvgl.lanbon_teszt

Result is:
kép

If I upload it through the web page of the plate and reboot it, everything is fine.
Tried removing the comments, blank lines etc. no difference.

switch.plate_antiburn unavailable

Not sure why it's not showing as "unavailable", maybe because I'm running the latest HA (2021.12.3)

Didn't even realise this switch was implemented, very keen to try it out but it's not working currently.

Hardware: Lanbon L8-HD.

Reloading integration deletes entities friendly names

Version of the custom_component

0.6.4

Configuration

Not relevant as it's independent from config.

Describe the bug

Steps to reproduce:

  • Install a plate having GPIOs configured. Switches will be imported in HA accordingly. For examle, Lanbon L8 will have switch entities like light.plate_konyha_light_12, light.plate_konyha_light_14, etc.
  • In HA Lovelace click on any of these entities and set a name for them. Any name like Light Bedroom Left
  • Go to Configuration > Devices and Services > (your plate) > 3-dots menu > Reload
  • Check the entities you've set name for. It will be missing, Reload function deleted the name.

Debug log


2022-01-23 21:33:53 WARNING (MainThread) [homeassistant.helpers.service] Unable to find referenced entities openhasp.plate_konyha
2022-01-23 21:33:56 WARNING (MainThread) [homeassistant.helpers.service] Unable to find referenced entities openhasp.plate_konyha

Detected code that uses str (config) for entity category

Hi to all, after the last update of Home Assistant Core 2022.1

the custom integration generate an error on Log:

"Detected code that uses str (config) for entity category. This is deprecated and will stop working in Home Assistant 2022.4, it should be updated to use EntityCategory instead. Please report this issue."

With previous core versione 2021 it's all perfect

wakeup service idle parameter

Thank you for this new feature!

One suggestion: for hasp_lvgl.wakeup parameter to set idle level before actual wake. Currently it wakes to idle off, which wakes to brightness 100%, which burns the eyes at night. wakeup with parameter for idle: short would wake it with brightness corresponding to that idle level so no eyes burned out 😄
one could choose with a template to which idle level they want to wake, could be dependant on environment sensors day/night, covers position etc

Create cover control with feedback

Cover control with 3 buttons in hasp-lvgl:
kép
It's made of 3 buttons with "toggle":false. But, there's no feedback on the state of the cover, as the buttons only trigger with event.

Same in Lovelace:
kép
Here the extra icon shows if it's moving or not and displays closed or opened icon.

The goal would be to have this kind of information hasp-lvgl too. For example support toggled buttons and keep it pressed while the cover moves up or down. Also a way to show if it's opened or closed on the middle button somehow (percentage is available in HA state of the cover).

Error in new HA 2021.8.1

Version of the custom_component

0.6 - current

Configuration

not relevant

Describe the bug

Since release of HA 2021.8.1, log gets filled continuously with the errors below.

Debug log

2021-08-05 12:59:17 ERROR (MainThread) [homeassistant] Error doing job: Task exception was never retrieved
Traceback (most recent call last):
  File "/usr/src/homeassistant/homeassistant/util/logging.py", line 140, in async_wrapper
    await async_func(*args)
  File "/usr/src/homeassistant/homeassistant/components/mqtt/discovery.py", line 287, in async_integration_message_received
    result = await hass.config_entries.flow.async_init(
  File "/usr/src/homeassistant/homeassistant/data_entry_flow.py", line 153, in async_init
    flow, result = await task
  File "/usr/src/homeassistant/homeassistant/data_entry_flow.py", line 179, in _async_init
    result = await self._async_handle_step(flow, flow.init_step, data, init_done)
  File "/usr/src/homeassistant/homeassistant/data_entry_flow.py", line 260, in _async_handle_step
    result: FlowResult = await getattr(flow, method)(user_input)
  File "/config/custom_components/openhasp/config_flow.py", line 85, in async_step_mqtt
    _discovered = json.loads(discovery_info.payload)
AttributeError: 'dict' object has no attribute 'payload'

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "/usr/src/homeassistant/homeassistant/util/logging.py", line 142, in async_wrapper
    log_exception(format_err, *args)
  File "/usr/src/homeassistant/homeassistant/util/logging.py", line 104, in log_exception
    friendly_msg = format_err(*args)
  File "/usr/src/homeassistant/homeassistant/components/mqtt/__init__.py", line 373, in <lambda>
    f"Exception in {msg_callback.__name__} when handling msg on "
AttributeError: 'functools.partial' object has no attribute '__name__'

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.