Driver starting point/template for IP lighting connectivity

🚧 Developers
1

I know I've chatted a bit about this before on here, but I'm looking for a specific recommendation on an existing driver that I can use as a starting point. This is for a LiteTouch centralized lighting control system. All lights are wired back to dimmer or relay modules in the basement, and all rooms have keypads in them ranging from 1 button to 9 buttons. Each light has an ID, in the form of "02-3", where "02" is the relay or dimmer module number, and "3" would be the output on that module. Modules have either 6 or 8 outputs on them.

I need a parent device that takes the following inputs:

  • Dimmers - a list of dimmer ID's (e.g. "01-1, 01-2, 02-4")
  • Relays - a list of relay ID's (e.g. "03-1, 03-2, 03-3")
  • IP address - the IP of my ip->serial gateway attached to the LiteTouch controller
  • Port - the TCP port on the serial gateway needed to connect.

The reason I have to specify the dimmer and relay module ID's specifically is because this is an older lighting controller that doesn't have a command I can use to discover configured devices and whether they are a relay or a dimmer.

I need the parent to automatically create the child devices as switches (for the ID's specified in the "Relays" field), and dimmers (for the ID's specified in the Dimmers field). And, ideally if this list was modified it would delete or add the child devices as needed.

Are there any drivers out there now that are similar to this? I know I'll have to write the rest of the logic to support the proprietary protocol used for sending commands and polling, but that's fine since I've already written it once in LUA on the Vera platform. Having something as a starting point that already takes IP/port and a list of device ID's would be really helpful though. Someone once mentioned a specific lighting driver that might be good, but I cannot find that post anymore.

Also, the other thing is polling... Right now on the Vera, I poll the list of relays and dimmers in a circular queue one per second under normal operation. If I make a change to the device through the Vera, I insert that device ID at the top of my circular queue to ensure that the command succeeded, and then it continues on where it left off. If I blast the polling queries all at once, the results come back in a random order from the controller and then get assigned to the wrong device in the Vera. Early 90's technology and slow embedded hardware. The whole thing is run by a PIC chip. So I have to be slow about it. How is this going to affect the load/performance of the Hubitat if I do the same "one per second" polling?

For those who are interested, here is the driver I wrote for the Vera so you can see what it does. This version is direct to a serial port since I can plug a usb->serial converter into the vera.

This file is the one with the actual code in it:

2

Any suggestions?

3

You might look at the app/drivers in "GitHub - DaveGut/Hubitat-blebox: blebox Integration for Hubitat". Particularly the switchBoxD driver that is a multi-output IP device. Commands are different, but the basic idea is the same:

  • Application parses each main device into the four child devices and installs them.
  • The child devices send commands to the box to command the individual channels.
  • You could also put comms in the app and have the app send the command to the box.

Hard to fully see without the actual device in-hand on how it will actually work.

4

You might also search the Smartthings community to see if someone has created a LiteTouch driver/app.

5

I didn't see anything for smartthings. I'm guessing most people with LiteTouch have the money to put in 6 figures on a Control4 or Creston system.

6

So I'm looking at the developer documentation, can anyone tell me which methods I should be using for these lighting loads? I'm guessing "Switch" for relays and "SwitchLevel" for dimmers.

The developer documentation is pretty light.

Also, the telnet interface requires an options field. What should be in this? I'm connecting to the serial port on the lighting controller using a 4 port Wiznet ethernet->serial thing that I had laying around. I could switch this to a pi zero w running socat as a daemon, but I already have this thing running and installed.

7

When you set up the system, I assume that you will create a separate device for each end point (the switched item) such as light, bulb, fan, etc. The capability then refers to what these end devices are. This is used by Rule Machines and apps to be able to hook to devices and once known, know what commands are available to the application.

Each capability exposes a series of commands and attributes. The commands will be methods in your code and the attributes need to match the definition so the applications can queue off the data.

8

Are you going to try and do this with a driver that will interface directly with the system? Or are you going to try to do it with an App and virtual devices? You could do either but that decision will greatly affect which direction you take.

9

I was going to do a driver because I thought that was what I needed. If I can do it with an app, that's fine. What are the tradeoffs for each?

Is there ANY documentation describing the differences?

10

The difference between an app and a driver? That's kind of a fundamental principle of the hubitat architecture. If you don't really have a handle on that, you're going to have a heck of a time developing either one of them.

1 Like
11

So where is the documentation on it? All I can tell at this point is that there is some overlap, amd what I am trying to do can be done either way.

12

Drivers control devices directly and app control multiple devices. Devices cannot talk directly to one another, that is handled by an app.

1 Like
13

@signal15
Take a look at @ogiewon's code, it implements a Composite-Device, which is a model that should work for what you're doing.

Here's the specific codebase:

Specifically, the *parent*.groovy files, for the Drivers of the Parent Devices, and the child-{switch|dimmer-switch}.groovy files for the Child Devices

Yours will likely be a little different, since I imagine you'll need to use Protocol.TELNET instead of HTTP-based requests this code appears to be using.

To initialize the Telnet connection, the doc is scant, so best to look at things like the Alarm Panel Drivers (eg. DSC).

For mine, I use something like the following, as my panel expect line-delimited data, terminated by a CR.

   telnetConnect([termChars:[13]], ip, (int)port, null, null)

This is akin to the old <settings>/<protocol> section of a Vera Plugin's I_*.xml file.

The main difference you'll find is that the Child Devices typically need a specialized Child Driver file (like the above) in order to "send" actuation events (eg. "on" or "off") up to the parent to be handled (in your MiOP/Vera, that part was automatic)

Hope this helps..

1 Like
14

@guessed, thank you! This helps a ton. Yes, if I continue to use the Wiznet or a Pi with socat, I'll need to use the TelnetConnect thing. I have also considered using a Pi and writing a REST API using flask so other things could talk to it/control it and it wasn't just a slave to the Hubitat. However, I'll probably just use the telnetConnect thing and implement the serial protocol directly in the driver.

1 Like