Simple serial port

Unfortunately, you don't give enough detail about what this "device".py file is, how it's created, etc., so it's going to be hard to answer your question. If you're spawning a thread for each device, then you'll need to keep track of each of those thread processes in the main plugin.py file so that when an action is called (which happens on the plugin.py file) you can get the deviceId (pluginAction.deviceId in your action method) that the device wants to use then find the right device thread to send the command to.

Thanks Jay. I'm trying to set up a plugin for the Jandy pool system, and as such will likely only allow a single device (can't imagine folks having more than one pool/spa to control on a single instance of Indigo), so there will only be one thread. I will have to allow for different models of the Jandy, and will parse that using the deviceID as you suggest.

The action is getting back to the proper spot in the python.py and then device.py threads, but I'm having trouble storing the information created when opening the serial communication, using the conn = self.plugin.openSerial(dev.name, portName, 9600, timeout=1, writeTimeout=1) referenced above.

I tried adding it to the device properties, unsuccessfully.

Jim

[jay (support)]

I was confused by your use of "device".py and, more importantly, startCommThread (from the EasyDAQ example). Assuming you're creating an object similar to the EasyDaq object in the easydaq.py file, then when you create the instance of the object it needs to somehow save off the connection (or completely manage the connection itself). It's a bit hard to follow in the EasyDAQ plugin, but what happens there is that when you call startCommTread on the EasyDaq object, it creates another thread and passes the connection to it:

Code: Select all

commThread = threading.Thread(
target=functools.partial(self._commThread, conn, actions, dev, devProps)
)


So that new thread now has the connection object along with the device and props - all that's needed to process incoming messages and outgoing messages (through the Queue object). If you look at the _commThread method, that's what the new thread will run - it loops continuously getting new data and sending out commands from the actions queue.

A lot of that architecture is there because the plugin needs to support multiple devices.

If you're only allowing a single device, then maybe you should take a look at the Airfoil plugin rather than the EasyDAQ plugin. While the serial comm part of EasyDAQ provides useful examples, much of it's architecture is based on defining a device. You probably don't really want to do that. In the Airfoil plugin, you don't configure devices (since it can only talk to the local instance of Airfoil). I provide events and actions directly. The downside is that you don't get device states, but it's significantly less complex and you can provide events that would mimic state changes.

Just a thought...

[matt (support)]

You can try stuffing it into the plugin (self) itself like this:

Code: Select all

self.conn = self.plugin.openSerial(dev.name, portName, 9600, timeout=1, writeTimeout=1)

Then when you reference it from the actions you'll use self.conn (make sure it isn't None before using it). If you want to use Devices but the user should only be allowed to create a single Device of your plugin type, then you will want to enforce that in the code somehow. Putting the connection into the plugin as shown above might work okay in that situation, but it definitely won't work correctly if you have multiple devices each needing their own connection.

Jay and Matt,

Thanks - the version Matt suggested (self.conn = self.plugin.openSerial(dev.name, portName, ...) works and I think it will be more consistent with the intent of using separate .py threads for devices. While I will only allow a single choice of device, there will be various versions allowed, so I think this is the best way to manage.

BTW - I finally have actions working!! Getting close to something that can be shared.

Thanks,
Jim