Creating a general gateway

[mtsinc]

This seems like a common enough need, but I haven't seen anything to address it.

Basically, I've got a gateway device (connects as a tty) which concentrates and formats data from a variable number of remote sensors with varying capabilities.

For best results, then, I'd like to define each remote via a Python plugin, but have each of those plugins register with a gateway plugin so that the gateway could dispatch to the appropriate remote plugin as data came in.

An existing approximation to this would be the RFLink facility. But RFLink knows about the specific abilities of the devices it supports, so it can automatically generate a device. My devices are too dumb to self-identify and too flexible to assume or deduce specific options. Plus RFLink cheats. It's hard-wired into the Domoticz core, so there's no Python example code to plunder. On top of which, the Python infrastructure seems to hermetically separate each plugin, making it that much harder for two different plugins to collaborate.

Is there any hope for me?

[StasDemydiuk]

Had very similar challenge with gateway for different zigbee devices. Here is my plugin https://github.com/stas-demydiuk/domoti ... qtt-plugin. It is not what you are asking for but maybe might help as temporary solution.

[mtsinc]

Thanks!

Every little bit helps.

I notice that an AWFUL lot of postings in this forum have the word "gateway" in them. Really seems like there should be a standard interface for them.

[Dnpwwo]

@mtsinc,

The native gateways are also "hermetically separate" (great phrase BTW) which is why the plugin framework was designed that way to match. If hardware drivers collborate or update devices they don't control then the hardware support will not be very generic is reuse will be minimal.

The native gateways (that I know of) all 'cheat' by having some kind of hard coded logic or data look up in config to map sensors to their capabilites.

If you can't create a mapping because your devices aren't smart enough, you could just create a generic device and let the user change the device type to what it really is (via the Web UI). The plugin should be notified via onDeviceModified and you could format the data going into nValue and sValue depending on the type during an onMessage callback.

[mtsinc]

Actually, there are all sorts of cases in the wider world where there are generic gateways dealing with multiple peripherals.

Probably one of the best knows is the "Windows Printer Device Driver". What people call the "Driver" here is actually a translator. Its primary purpose is to convert generic Windows graphic API calls into device-specific command sequences. It's not a true driver, though, since it doesn't (usually) have the ability to issue actual I/O commands. Instead, it is paired with an OS-level driver for parallel, serial, or more recently USB or network driver. The separation of concerns is complete enough that the same translator works with any driver. That's different from Domoticz where if you have a given sensor but it can attach via different interfaces, you have to re-invent the sensor for each interface.

The devices of immediate interest to me can contain from 1-4 digital switches plus optional temperature/humidty sensing, each of which the user would like to treat the same way as you would individual motion sensor switches, for example. The remote device itself has no way to sense how many switch units are actually installed on it, since it's a dumb spst-style switch and an "off" switch is the same thing electrically as a switch not installed. So the normal amenities where Domoticz sensors install and configure themselves are not possible. It would require each remote to be individually and manually configured (except for the thermal/humidity sensors, which can be auto-detected).

But these devices cannot be attached directly to a PC or network. They're wireless and transmitting to a receiver attached to a USB device which is in turn attached to a ttyUSB device. Since the same ttyUSB serves all remote devices, that is a problem since only one Python plugin can have the tty open at a time and you can't just have them all poll that device since the receiver is a conduit, not a store-and-forward.

I don't see how the Web UI can help that, and for that matter, I'm unclear if by "web UI" you mean the relatively brain-dead one that the hardware configuration page uses (I insult it because there are no checkbox or radio button control options, just variants of dropddown) - or if you're referring to the sort of thing that the RFLink gateway uses. And if the latter, how to use it, since there's no clear documentation on the topic I know of.

The closest thing I can figure to a solution here would be to define a gateway that spawned named pipes or loopback network connections and have the Domoticz "hardware" devices corresponding to the remotes rummage through the OS to find and connect. That displeases me because while it's certainly in the spirit of hermetic separation, it's also extra overhead and design complexity.