- Network Objects - software and module functionality
- Cortex Logic Objects - pure software
- Device Objects - external hardware devices
In my previous post I talked about objects and categorised them as:
Now there is actually a feature of some network objects that is quite nifty, but conflicts with the categorisation above.
If you recall, I described network objects as representing a combination of software functionality and Idranet module functions. However, it is also possible to use some network objects without having associated hardware modules.
For example, you can instantiate a light level module (ALS) from the Tools > Design Network > Add Cortex Logic Object > Light Level Module. I'm going to add this to my garden. Note that this is different to how we might normally add a module by physically connecting a real module to the Idranet and powering it up and allowing the auto-discovery to work it's magic.
I've given it an unused address and note that it is not network enabled. Now, here's the trick, if I go to the new object's connection dialog and scroll down to the bottom ...
you can see an input analogue connection called Alternative Light Level source. I can connect this to the light level output from a real light level sensor, my Garden Light Level object. The new object will now use the output from the real module as if it were it's own.
So we can open up the behaviour dialog for the new object and configure a different set of light and dark thresholds compared to the real garden light level object:
Note that the light level graph is the same, except the new object has data gaps caused by me experimenting with something else that caused me to stop and start the network a lot. In other words, the network has to be running for the data transfer to take place.
What's the significance of this? For light level objects I think this can be very useful, because the dark and very bright thresholds have special significance in the light object. One way you might use this is to have a second object with a different set of thresholds influencing lights on a different side of your house, where perhaps the light is significantly different than where your outside sensor is positioned.
Temperature and humidity objects also have the alternate data source connection, so you can play the same trick with them. However, those objects don't have first level processing with special meaning and you can define an arbitrary number of thresholds in one object. Having said that, I'm sure I'll find a good reason to use it almost as soon as I post this.
I call these objects that are pretending to be physical modules virtual objects.
At this point you might be thinking, why isn't the software processing (thresholding logic) in a separate object from the physical module handling stuff, so that you don't need these "tricks", with the potential confusion of hardware related configuration in an object that has no hardware module associated with it? My guess is that the additional connection was added later on to allow the creation of these virtual objects for situations like the example I have given above. At that point there would have been the choice between implementing this scheme with alternate data sources or a new set of objects, with compatibility issues between databases and potential confusion for users.
But there is also the possibility that the configuration information in the behaviour panel for an object with an associated module may one day be used for automatic creation of Reflex programs, as has been introduced with Light objects. With another layer of hierarchy you could imagine a database with one sensor module object feeding a hundred thresholding objects, somethign that might be completely legitimate in the context of a Cortex program, but would, however, exceed the number of thresholds that can be represented in a reflex program. There would then need to be a method to indicate which configurations to "favour" for Reflex generation.
TrackBack URL: http://www.gumbrell.com/cgi-bin/mt4/mt-tb.cgi/79