What are you using to send the Activate (20) with data (FFFF).
PU89100211FF20FFFF37 Send Activate Scene 17
^^^^
That’s precisely what I had reported in my previous post. I’m seeing 20FFFF when I press a button. In contrast, the Command Wizard doesn’t produce the FFFF with Activate and the documentation doesn’t mention it (and the UPB integration complies with the docs so it doesn’t append FFFF either).
Also seen with Deactivate (21) here:
PU8910020EFF21FFFF39 Send Deactivate Scene 14
^^^^
I have actually been testing your report for the past 30 minutes or so. What I’ve determined is that you can add the FFFF after the 20 (Activate) or any data you want, for example, 3208, but those characters are ignored when you send them with an Activate command. So, for instance, if you sent 87000207FF2032001F, the responding device ignores the 3200 after the 20 and the device responds as programmed in its Receive Components table.
That’s not the case with a GOTO command - it does respond to the extra characters. But, when coupled with an Activate, it ignores the extra data. This makes some sense - why allow the Activate command to do this when you have a GOTO command expressly intended for this?
I’ve seen this before in other controllers (including switches programmed as transmitters). I’m betting the programmer just took the easy way out, knowing that these optional characters are used for other commands, such as GOTO, and just sends them with all commands, in order to have one process for generating commands. I’ve almost always seen them sent as FFFF.
One way I’ve been sending that command is by using the UPB Explorer tool in Upstart.
Still playing with it, just to make sure I tested it properly, but I think it’s right.
OK, what interesting is that Premise’s UPB driver doesn’t simply ignore the FFFF but uses it as a signal to change how it behaves. Without the FFFF on Deactivate, it sets a light’s powerstate to off but not its brightness. That may be a bug or some sort of intended behavior. I can’t tell the difference and can’t ask the author because he/she is unknown.
I think the author may have chosen to read the whole thing (20FFFF) because that’s what was being seen “in the field” (as opposed to just 20 as shown in the documentation).
Finally got a bit more time to work on a UPB network scanner. One thing that may be useful for anyone who wants to create a TCP server from the serial port(for example so that it can be easily used from docker) can look at this example ser2net config which seems to work for me.
Just place it in /etc/ser2net/ser2net.yaml and run ser2net. You can then connect via port 2101 to whatever host you are running ser2net on.
@gwww I found another issue. It seems like it doesn’t co-mingle with other integrations nicely. One glaring thing is that config_check fails when the UPB component is enabled but strangely HASS still works when only UPB is configured. For example, this fails but HASS will actually start.
…but when I run it in production it all falls apart.
2020-02-01 09:50:41 ERROR (MainThread) [homeassistant.config] Invalid config for [upb]: expected a dictionary for dictionary value @ data['upb']. Got [OrderedDict([('url', 'serial:///dev/ttyS1:480
2020-02-01 09:50:41 ERROR (MainThread) [homeassistant.setup] Setup failed for upb: Invalid config.
Also, other integrations start throwing errors like …
File "/opt/python-venvs/hass/lib/python3.7/site-packages/homeassistant/helpers/entity_component.py", line 147, in async_setup_entry
raise ValueError("Config entry has already been setup!")
ValueError: Config entry has already been setup!
Now if the UPB integration can also listen to the event bus, then one can create an event to activate UPB link 2. This ability would obviate the need for scenes and custom services.
- alias: 'Transmit Link 2 Deactivate'
trigger:
<some kind of trigger>
action:
event: upb_link_deactivate
event_data:
link: 2
- alias: 'Transmit Link 4 Goto 50 at rate 4'
trigger:
<some kind of trigger>
action:
event: upb_link_goto
event_data:
link: 4
brightness_pct: 50
rate: 4
Although I don’t see any drawbacks to using events as a means to receiving UPB links, there is one if an event is used to transmit one. You don’t know which links do what unless they are exposed the way they currently are, namely as scenes.
Perhaps the compromise is to adopt a bit of both: retain the current scenes and custom services model (for sending commands to a link) and use events for receiving links.
More about receiving and creating events can be found here.
They do don’t they? As of now it appears to do a state change of the scene. A state change is an event with an event_type of state_change.
EDIT : Ahh. You want to listen for events too. I’m not sure which way is less confusing. No matter which way things go it’s going to be a bit odd because an event isn’t a scene and a scene isn’t a link. Nothing seems to correlate quite right
After playing around with this in pulse mode a bit more I think I’m going to create a UPB mitmproxy like module for the upb library to simplify tracing the logic of existing UPB applications like upstart by providing a listening TCP socket they can connect to which forwards commands to the UPB network while trying to decode the commands at the same time.
This should provide for a simple way to verify any commands generated by existing applications like upstart are appropriately replicated by home assistant. The idea is that we’ll then essentially have a wireshark like tracing utility but for UPB protocol decoding specifically.
I haven’t actually done it yet. I was going to install it the other day and ran into problems but when I was testing, I did see this (link below) on the event bus when activating a link from a physical switch. I’m not sure if you’ll see a state change (it always stays in “scening”) in hass because the state doesn’t change but you should be able to monitor for the event.
I looked at what you posted. Maybe I just don’t see it but how can you tell what happened other than something happened?
I see data.new_state.last_updated is different from data.old_state.last_updated. Something happened to scene.mode_wake_up_2 but I can’t tell what happened to it; it’s unclear (to me) if it was activated or deactivated.
You will see a state change. A new attribute called last_changed is a timestamp of the last change. That is sufficient to trigger a state change automation.
I think I agree with @123 that a bus event is required. Considering that now. Not sure if last_changed should stay or not.
Suggestion… Let’s create issues on github with feature requests, bugs, etc. That way we can keep issues in separate threads, things will not get lost as I know they will here. Open the issues on either the upb-lib or the hass-lib repos as you see fit. Either one will suffice for tracking.
I was reading some other threads dealing with events created by Deconz and ZHA integrations. For example, pushing a button on some flavor of Zigbee remote control will post an event that’s packed with details about what just happened.
It seems to me that this is a good way to express a UPB link’s activity. Was the link activated or deactivated? Was it used with a Goto to set the level and FadeRate? All of that (and more) can be reported by an event.
Good points. I never thought about knowing more details about the link. Not something I thought about using but sounds like you’re right that the data should be exposed to do it correctly.
I’m updating github as well. Good point gwww. I subscribed to 123’s issue.
OK, I get it. Your application only needs to know the link was transmitted (it doesn’t require details such as if the link was Activated/Deactivated or used with Goto or FadeStart/FadeStop).
In my case, the automation (in Premise) listens for activate/deactivate so it knows which action to perform (turn the associated X10 light on or off). All four of the UPB switch’s buttons are configured so that a single press sends activate and a double press sends deactivate.
I’m very interested in the current developments! Kudos @gwww !!!
I would like to do some testing, but my skills in HA development are weak. Could you aid me in setting this up?
I’m running HA installed manually on a Raspberry Pi. I have a serial PIM with a USB adapter. What would I need to do to get this going? I would assume I’d need to install the library:
You do not want to install upb-lib. You do want to install hass-upb. To do that grab the latest .zip file from here: https://github.com/gwww/hass-upb/releases. Unzip the downloaded file. In the unzipped content you’ll find a directory custom_components. Copy custom_components AND everything inside it to your config directory on your Raspberry PI. On your PI you should have a /config/custom_components/upb/<all the files from the upb unzipped directory>
Update your configuration.yaml as you have already indicated. Make sure your UPStart export file named upb.upe is in your /config directory on your Pi. Restart hass. Hopefully enjoy.
Thanks for the help! I forgot to mention, I did install the custom_components files. Should I uninstall upb_lib from my venv? I’m getting an error when I do a Check Config:
Invalid config for [upb]: [url] is an invalid option for [upb]. Check: upb->url. (See ?, line ?).
Yah, there’s some config issue I’m trying to figure out. Not sure what is going on but it is feeling like a core hass issue. So, YMMV. I get invalid config too, but hass runs just fine. So you could try it.
No need to uninstall upb_lib. hass installs it for you and if you have the wrong version hass will install the right one.
