I suggest the integration offer a means of dynamically changing the port and UPE file name (the HACS integration exposes this functionality with an Options button).
Otherwise, this can happen:
To change the file name or port, you uninstall and reinstall the UPB integration.
Upon re-installation, a new device_id is assigned.
As a consequence, any existing Device Automations are broken.
upb.scene_activate was removed in favor of scene.activate. i.e.: use what exists and donāt create extra services.
Good point on scene_* vs link_* consistency. I have no preference on either name. Perhaps see what other integrations are doing with naming and follow that example?
Now Iām confused. Where is that service documented?
If I look in sceneās services.yaml, I see scene.turn_on but no mention of scene.activate:
Is it a new scene service that will appear in the 0.110 release?
FWIW, my vote is for standardizing on the term scene (i.e. upb.scene_changed) but, if others strongly disagree and in the interests of avoiding a breaking change, I can live with the existing upb.link_changed.
Ah, OK! It interesting to learn that the term used internally actually does a better job of describing the action (scene is activated, not āturned onā).
If you want, I can compose a few examples (including one that uses scene.turn_on) for inclusion in the docs.
FYI, in the documentationās description of Events, thereās a typo on the last line. It misspells the word transition.
rate : The rate for link to transition to the new level. rate is -1 for the default transiton rate.
Here are the promised examples. Please review them to ensure they comply with the new events and services (I donāt currently have the means of testing the latest version of the integration). Iāve taken the liberty of renaming link_changed to scene_changed.
#automation:
- alias: 'Specific scene activated'
description: 'Trigger when scene 9 on network 42 is activated'
trigger:
platform: event
event_type: upb.scene_changed
event_data:
command: activated
address: '42_9'
action:
service: persistent_notification.create
data_template:
message: 'Scene 9 on network 42 was just activated: {{trigger.event.data.command}}, {{trigger.event.data.address}}'
title: 'Scene Activated'
#script:
all_lights_on:
alias: 'All Lights On'
description: 'Activate two UPB scenes named interior_lights and exterior_lights'
sequence:
- service: scene.turn_on
entity_id:
- scene.interior_lights
- scene.exterior_lights
all_lights_off:
alias: 'All Lights Off'
description: 'Deactivate two UPB scenes named interior_lights and exterior_lights'
sequence:
- service: upb.scene_deactivate
entity_id:
- scene.interior_lights
- scene.exterior_lights
kitchen_fade_on:
alias: 'Kitchen Fade to On'
description: 'Turn on kitchen light to 75% over a period of 10 seconds'
sequence:
- service: upb.light_fade_start
data:
entity_id: light.kitchen
brightness_pct: 75
rate: 10
Should the docs also mention the use of homeassistant.update_entity?
Excellent. I suggest that you create the doc PR. I will change the code. We will need to reference each others PRs in our PR. Here is how you will be able to find mine: https://github.com/home-assistant/core/pulls?q=is%3Apr+author%3Agwww (it includes all PRs by me, not just open). If you reference my github handle in your PR (@gwww) I will receive a notification.
Iām going to need help with that. I donāt know where to begin.
For existing documentation, the page contains a link to āEdit this pageā which starts you off on the process. In this case, the documentation is in your PR and I donāt know how to amend it. I see a pencil icon; I canāt click it but hovering over it indicates āYou must be on a branch to make or propose changes to this fileā.
Do I simply create a new PR, copy-paste your documentation, modify it, then submit it?
I have a GitHub account, Iām signed it, and the linked instructions describe the pencil icon that I reported I am unable to click in your PR.
Iām a complete novice with GitHub but I think I need to make a local copy of your repository and then edit that? git pull or git clone or something like that??
Ah-hah! No! I was clicking on the original documentation link you shared several posts ago. I can click on the pencil icon in the latest link you posted. However, now Iāve run out of time and will have to revisit it later this evening.
Gives response(this is only a decode of the first 16 register bytes but adding the others is basically the same and I have the full register map from upstart):
Iāve uploaded the library code here, itās super rough right now and will need to undergo some major refactoring rounds but Iāve got enough of the basics working that it should be fairly straight forward(although somewhat time consuming) to fill out the missing features at this point.
@gwww I looked at basing this off of your library codebase and while I used it as a reference for some of the encoding/decoding the protocol handler is quite a bit different due to mine operating exclusively in pulse mode instead of message mode. Mine also provides a await def abstraction over protocol commands such as register requests which allows for a much easier to follow control flow and cleaner home-assistant integration.
I wasnāt able to work on it last night and this morning the latest link you posted no longer allows me to edit the document (pencil icon is grayed-out):
Is the modifiable version of the document now in another ātreeā? How can I find it?
OK, thank. Just to confirm, after editing it Iāll need to create a PR afterwards. In that PR I need to reference your GitHub moniker so youāll be notified. Is that correct?
Done: PR 13445. My first ever so itās undoubtedly flawed in some way.
My comment was prescient. The merge was blocked because, according to the bot, I targeted the wrong branch. Now itās blocked and Iām requested to change the branch to current and rebase it if necessary. I have no idea what that means let alone how to do it. Iāll need your assistance once again.
Give the comment on the code PR, I suggest we back off the event name change for now. Just submit the new docs that increase their quality and we can revisit the naming at a later time.