UPB lighting

[bjhiltbrand (Brett Hiltbrand)]

@123

The best fit for the Relay Switch is not light (as it’s currently being modelled) but a switch . There is a fan but the Relay Switch doesn’t qualify because fan supports speed and direction.

Yeah, I see your point, and can agree with you there.

@gwww

It’s unlikely that the entity type would ever be selected from something in the name of the device.

I figured as much. I don’t really like the idea that much myself. I know my Hubitat integration tries to figure out devices types by name, which is why I brought it up.

@gwww

However, a light is treated just like a switch (by the UPB integration) when the device reports that it is not dimmable.

That is correct, with the exception that it is still presented to Home Assistant, and subsequently Google, as a light. For the most part, this is desirable. For instance, I have a couple UPB switches that are not set to dimmable because the loads they control are not dimmable (My garage and laundry room lights are all long fluorescent tube lights). Those are obviously still lights, and should be treated as such. But, if you have a UPB device that is controlling a load that is anything other than a light (ceiling fans or an outlet, for example), they should present to Home Assistant and other downstream systems (like Google Home and Alexa) as a switch.

I would say we could check the model when importing devices to determine if it should be a switch or a light in Home Assistant, except that the model that I’m using for my ceiling fans (the HAI 40A00-1 15A Relay Switch) is also being used to control the non-dimmable loads I mentioned before (my garage lights).

@gwww

I’m not understanding what is broken with Google Home, but I don’t use the Google Home integration with my setup. It sounds like a config problem to me as each UPB entity is able to be individually controlled.

When I setup the Google Home integration, I simply exposed the light, switch, and fan domains (without specifically setting individual entities to expose). That made my configuration much more simple, without needing to micro-manage each device. However, that created the issue we have here.

The living room lights group (which Google creates by default) includes the fan switch. That means that when I ask Google to turn the living room lights on or off, it also includes the fan in that command. This may or may not be desirable, depending on the situation.

I will say that I have this sorted for my circumstances for now, though, as I decided to spend a couple hours last night and individually map out every entity that I wanted exposed to Google, instead of just the domains wholesale. This was way more work than I liked, but the benefit far outweighs the trouble of setting it up, in that I have so much more granular control over what goes to Google.

So, while I have it working now, I think it may still be wise to look into implementing a switch option in the plugin. Thank you all so much for everything.

[gwww (Glenn Waters)]

Thank you for the explanation! I understand now.

Modelling non-dimmable things as switches is probably a good thing. I don’t think that fundamentally fixes the problem you are trying to solve since really you are looking for a way to group things together based on some criteria. The best criteria you have today is the entity type.

The challenge with modelling some devices as switches is that UPB devices are configurable to be dimmable (model as light) and non-dimmable (model as switch). What happens when the configuration of the device changes?

Enough pontificating — this isn’t the biggest problem to solve right now (at least for me). I’m back to working on the ElkM1 integration… there are features missing there and bugs that need some attention.

And, welcome to the community @bjhiltbrand! Nice to have another voice thinking about how to make all this stuff better!

[bjhiltbrand (Brett Hiltbrand)]

Yeah, I think at the end of the day, modelling non-dimmable devices as switches is a good idea, while I (and anyone else) can transform devices and only expose specific devices in the configuration.yaml file for use with services like Google. I think that presents the best of both worlds.

I do have one other question… in OpenHAB, I was able to interact with links directly (both to turn on and off those links). I used a switch item to allow me to activate and deactivate a scene, like this:

Switch	UPB_Scene_All_Lights_Off	"Scene - All Lights Off"	["Switchable"] channel="upb:link:Scene_All_Lights_Off:brightness"}

This switch item was a virtual switch, and I set it’s beginning state to what I needed it to start as when OpenHAB started and used a rule to reset it’s state once toggled, like so:

rule "UPB Scene Startup Handler"
when
    System started
then
    createTimer(now.plusSeconds(30)) [ 
        postUpdate(UPB_Scene_All_Lights_Off, ON)
    ]
end

rule "Update All Lights Off Scene"
when
    Item UPB_Scene_All_Lights_Off changed
then
    if (UPB_Scene_All_Lights_Off.state == OFF || UPB_Scene_All_Lights_Off.state == NULL) {
        postUpdate(UPB_Scene_Theater_Room_On_Off, OFF)
    } else if (UPB_Scene_All_Lights_Off.state == ON) {
        postUpdate(UPB_Scene_Theater_Room_On_Off, ON)
    }
    Thread.sleep(5000)
    postUpdate(UPB_Scene_All_Lights_Off, ON)
end

However, it appears that the links that are imported from the .upe file using Home Assistant are creating scenes, and if I understand correctly, scenes can only be activated? Is this true? I haven’t found a way to deactivate a scene yet.

Take the link/scene above, for instance… It’s designed to turn off all lights in the house with a double tap on a UPB switch, or the press of a scene controller button, or a command to a Google Home. However, since Home Assistant only activates the scene, when I tell Google to process the scene (I’ve tried saying “deactivate the All Lights Off scene”), it only ever turns all the lights ON.

Any help would be appreciated here, as this is one of my most used UPB links and I would like to retain that functionality. Thank you for everyone’s input! You guys are awesome!

[gwww (Glenn Waters)]

The docs should answer your questions. https://www.home-assistant.io/integrations/upb/

[123 (Taras)]

@bjhiltbrand

I haven’t found a way to deactivate a scene yet.

upb.scene_deactivate

[bjhiltbrand (Brett Hiltbrand)]

I read the docs, but I guess it just didn’t click that I needed to create a script in Home Assistant to do what I wanted to do. I had tried to do that, but all I saw was the option to “Activate Scene”. I realize now that the option I needed to choose was “Call Service”.

You guys rock! Thanks so much for your help!

[123 (Taras)]

@jameshilliard

the cypress_m8 driver will be auto-loaded when the device is plugged in, this driver will then create the /dev/ttyUSB0 serial style interface that we want for use by home-assistant

I just had the opportunity to test this today. I plugged a USB version of the Simply Automated CIM into a freshly updated Ubuntu 18.04.5 laptop and it appeared as /dev/ttyUSB0. Here’s the relevant bit from dmesg:

[162345.244332] usb 4-2: new low-speed USB device number 3 using uhci_hcd
[162345.442621] usb 4-2: New USB device found, idVendor=17dd, idProduct=5500
[162345.442629] usb 4-2: New USB device strings: Mfr=1, Product=2, SerialNumber=0
[162345.442634] usb 4-2: Product: USB to Serial
[162345.442639] usb 4-2: Manufacturer: Simply Automated Inc.
[162345.453852] cypress_m8 4-2:1.0: HID->COM RS232 Adapter converter detected
[162345.456594] usb 4-2: HID->COM RS232 Adapter converter now attached to ttyUSB0

File listing:

crw-rw---- 1 root dialout 188, 0 Oct  4 16:27 /dev/ttyUSB0

Everything looks good so I tried to use it with the UPB integration (Home Assistant Supervised 0.114.0) but it reported it couldn’t communicate with /dev/ttyUSB0.

@gwww I realize you’re currently focusing on ELK M1 but if you and James are up for it, I’m open to any suggestions as to how to go about collecting more information to identify the problem.

[jameshilliard]

Have you tried with a ser2net proxy instead of directly connecting home assistant?

Example config:

2101:raw:0:/dev/ttyUSB0:4800 8DATABITS NONE 1STOPBIT max-connections=100

[123 (Taras)]

Afraid not; I’ve never used ser2net. Thanks, I’ll look into it.

---

EDIT

So this is a serial to TCP server (allowing one network client to access a serial device connected to another network client). Home Assistant and the USB CIM are all on the same laptop yet a connection cannot be established. How does ser2net help with this? Is the idea that it acts as a middleman with a better ability to manage the connection?

[jameshilliard]

Well I was testing my library with ser2net so that I could run UPB library commands from a different system than the USB PIM, which I tested plugged into one of my embedded Linux systems which I had already set up for kernel driver development(was actually one I normally used for a separate work project that uses an up to date mainline kernel).

If it doesn’t work with home-assistant and ser2net try with my library using ser2net since that’s the setup I mostly tested with, it should also provide some debug logging that could be useful.

python3 -m upb.tools.dumpreg --host=127.0.0.1 --network=1 --device=5

[123 (Taras)]

I see. OK, given that I’ve never used it before, I’ll first have to configure and test it with a ‘known good’ arrangement before I use it to confirm comms with the USB CIM.

Just need to find something ‘known good’ I can test.

[jameshilliard]

You should be able to use ser2net in the exact same way with the USB PIM as you would with a USB-RS232 converter and serial PIM.

[123 (Taras)]

I skipped the ‘green run’ and went directly for the ‘all up’ test.

Short version:
It works. Which begs the question, why didn’t it work when the the UPB integration attempted to connect directly to /dev/ttyUSB0? Let me know if there’s any data you want me to collect to shed more light on this anomaly.

---

Long version:
I installed ser2net on the laptop with the connected USB CIM (my test system).

sudo apt install ser2net

I appended the configuration line you provided to /etc/ser2net.conf

2101:raw:0:/dev/ttyUSB0:4800 8DATABITS NONE 1STOPBIT max-connections=100

Saved the file and restarted the service using:

sudo systemctl restart ser2net

Using another machine running Home Assistant Supervised 0.115.5 (my production system), I configured the UPB integration to use TCP and entered the test system’s IP address.

After clicking Submit, it successfully connected to the test system’s USB CIM and listed all devices (from the upb.upe file). I changed the brightness of one light and confirmed it received the command.

[bbrendon]

@jameshilliard

Have you tried with a ser2net proxy instead of directly connecting home assistant?

I use it to connect Upstart since my PIM is plugged into my linux server. Life saver.

[jameshilliard]

There’s a few likely causes, either the serial port options are not being set up correctly by home-assistant(the USB PIM could be more sensitive to configured serial port options than normal USB to serial converters as it uses an internal converter chip different from what’s used with most normal USB to RS232 serial converters), or the serial device is not being properly exposed to the home-assistant application. Using ser2net effectively bypasses both of those issues which is why I recommended using it to test.

[123 (Taras)]

I stopped and uninstalled ser2net from the test system. Then I supplied the UPB integration with this:

/dev/ttyUSB0:4800

hoping it would help but it still failed to connect.

It would appear that /dev/ttyUSB0 isn’t presenting itself precisely the same way the UPB integration expects a serial port to behave.

ser2net appears to compensate for whatever is the deficiency that is preventing the UPB integration to establish a connection.

[jameshilliard]

That doesn’t look like it would work, ser2net uses its own custom config format for setting serial port options, you can’t use the ser2net config as is with the UPB integration.

These should be the relevant serial options from ser2net, they are not in the format expected by home-assistant however so you will have to adapt them to the home-assistant code.

4800 8DATABITS NONE 1STOPBIT

[123 (Taras)]

My previous post described what I did without ser2net (I uninstalled it). Although the UPB integration defaults to 4800 baud, I thought I’d try specifying it anyway (as described in the dialog box) to see if it made a difference. It doesn’t; it still cannot connect to the local /dev/ttyUSB0. That’s why I said it’s probably not presenting itself like a true serial port (otherwise the UPB integration would connect with ease). In contrast, ser2net has no trouble talking to /dev/ttyUSB0 (and serving as a middleman for networked clients).

There’s some subtle difference that allows ser2net to communicate via /dev/ttyUSB0 (to the USB CIM) as opposed to how the python serial library (used by the UPB integration) is attempting to communicate with it. What that might be is beyond my pay grade.

[jameshilliard]

@123

it’s probably not presenting itself like a true serial port (otherwise the UPB integration would connect with ease)

It’s pretty much presented the same as any other USB to serial adapter, ser2net would not work otherwise.

@123

There’s some subtle difference that allows ser2net to communicate via /dev/ttyUSB0 (to the USB CIM) as opposed to how the python serial library (used by the UPB integration) is attempting to communicate with it.

Probably just one of the settings other than baud rate is different, could also be delayed initialization or something like that dropping commands(ser2net would likely not have this issue since it doesn’t actually generate commands itself), I’ll try and test directly with python when I get some time, I’ve been pretty busy with work lately though and don’t have my development environment set up at the moment.

[123 (Taras)]

FWIW, I plugged the USB CIM into an RPI3 running Home Assistant OS (0.115.5) and HassOS 4.13 (latest) doesn’t recognize it as a serial device. It is reported as /dev/usb/hiddev0. Whatever version of buildroot HassOS is currently based on, doesn’t include your patch.