Premise How to assign serial code to object (W800)

I figured out a way to have premise take an input from an w800RF and then have it trigger an action. What i'd like to do is take the logic behind the data and assign it to an object. For example, if premise reads the code 123 from the com port (ie the W800), I want that code to be assigned to motion sensor detection. This way i can use the occupancy function and trigger actions off of the object change in status instead of hardcoding all actions I want to occur. Hope this makes sense and hope that someone can help.

I'll be happy to share my work around as soon as I can confirm it works correctly with objects/classes.

ACB

I think I understand what you want to do. You are currently able to detect and interpret received commands from the W800. In the detection code, you specify precisely what the command should trigger ... but you realize that this creates a driver that has a very narrow focus and cannot be re-used without re-coding it.

The key idea in a Premise driver, and quite different from other HA programs, is that the driver updates the status of its internal "driver objects". Your W800 driver must contain a Motion Detector object. When the driver receives a 'motion detector #45 has triggered' command it looks for a Motion Detector object,whose ID is #45 (or whatever the address format is) and fires its Triggered property.

There's a lot more that can be written on this topic but I recommend you look at how I handled Zones in my ELK M1 driver. I created a Zone class that inherits from the SecurityZone class. SecurityZone is Premise class that handles Motion Detectors, Door Contacts, etc. When the ELK M1 driver receives a 'Zone 1, Area 1 has triggered', it uses the GetObjectsByTypeAndProperty command to find the matching Zone object and set its Triggered property.

I mentioned this in another thread, a Premise driver is a more sophisticated animal compared to drivers found in other HA programs. Each driver has its own user-interface, a treeview, that displays the operating state of the physical device(s). The end-user can actually watch the driver in action, without writing a line of code. In many other programs, the driver is really just an API ... a set of functions you use in your code to monitor and control the device.

Unfortunately, nothing is for free and all of this power must be created by the driver's developer (i.e. you). In my experience, with the M1 driver, interpreting the M1's commands was the easy part. The challenge was to figure out where to put the information ... the driver needed a framework thar mimics the 'appearance' and operation of a real M1. That's why I posted the 'skeleton' for a W800 ... it contains many of the classes you'll need to handle motion detectors, RF buttons, keypads, etc. Study the MR26A driver, that's your goal.

Any further progress on this?
Thanks
-Ben