HouseBot

Hello HBies...
After a very teoretical discussion about how to handle "real world" devices and I/O devices/control devices i realize that one way to solve this would be to have the possible to mirror/replicate/map properties in the same db.. (add a property to a device that is only a copy/replica of a property in another device.)
This would give the possibility to:
- Set up devices for Controldevices with control specific parameters and feedback. one io module with several I/O ports can later be mapped to real world devices as they are connected.
- Real world devices can be named realworld names..
- Possibility to setup "composit devices"... a real world device can have a collection of properties from different hardware I/Os.

This is very "obvious" when starting to add "bus-based I/O nodes" with many I/Os connected to many different "real world devices".

on top of this it would be nice to have the possibility to filter a "view" with only realworld devices. I am in tha naive view of after configuring electrical/control and I/O devices a user should only have to deal with realworld devices for GUI and tasks....

I hope i Xplain this in a way so its possible to understand even for nonswedish people
kind regs Anders

I am having some difficulty in understanding what you mean because all of what you describe is just what HouseBot is very good in doing already. I must misunderstand you I guess.

Its probably a very fuzzy swedish decription that is the problem

I try to take a more hands-on example...

I am trying to use nodes on a bus, these nodes have separate I/O pins and separate nodes/modules for analog and binary I/Os.

it looks like a logical way would be to set up devices for these nodes with attributes like node adress, location and node specific errormessages and a property for each I/O pin etc...

(either the bus driver would be handled by a interface or updated thru an external control.. and either be a interface or a separeted device with bus specific properties ex. errormessages baud rate , com port etc)

and now comes the twist when i connect for example a lamp to a I/O pin it would be very nice to make a new device named after the lamp and just with the I/O pin its connected to as "mirrored propety".
this way i can configure nodes as i connect them with all node propeties at one device.
And when i do tasks and GUI i can use realworld device names.. the lamp... instead of the device/IOpin.

and the possibility to do "composite" devices would be in example to collect a analog value and a digital pin from two diffrent nodes to one device. this would be just to do a null device and collect mirror properties in that device...

this is mostly a aim to find a logical way to map and manage realworld devices and still keep the possibility to keep devices for HW nodes/modules.
this apply well to 1-wire devices, serial bus devices (DGH, omegabus or advantech ADAM modules) and i guess IP based nodes.

In some way this is possible to do with tasks but it ends up with lots of tasks...

and with full respect of the kernel of HB an my lack of knowledge of it, i guess it would mayby be possible to use the replicated device functionality...

still talking in tongues ? ... kind regs Anders

I guess what you describe is the way the X10 stuff already works. Each X10 device gets its own device name with a set of properties that go with the device. If you are into the SDK and are able to code in C++ you should be able to do this yourself. I guess HouseBot is not the bottleneck here. Creating something generic is very hard unless you go with what's already there like the generic serial device in combination with a serial device that holds a received data property and a wildcarded send data property, a script device to handle to sending and receiving parts of the nodes / modules and one or more NULL devices that handle the properties. I have many devices connected to my HouseBot setup this way and they all work very well and act realtime on both the sending and receiving part. HB doesn't have device drivers for most of my systems except for the X10 and USB UIRT and I am still able to interface it all to the same level a device driver would go. Just think about it. HouseBot is a piece of software that can be used in many creative ways where only your skills are the limiting factor.
Obviously I still might not understand what you are saying.
Maybe Scott can pitch in;)

Let see if I understand you correct. You would like to have at least two ways to describe and administrate your HB system, one hardware way (busses, nodes, io pins etc.) and one user (or wife) way (front door, alarm system, outside temp etc.) ? I think one of the the problems is that a device can only have one name. Today you have to decide before you start to build your system if you devices should be named like "bus3_node4_pin5" or "car_heater" (yes, i live in sweden to ). Both ways have their advantages but there will be a mess if you mix them. When a system starts to grow and you got lot of devices you must be able to administrate them from a "hardware" point of view when you add a new sensor or when a node on a network has broken. But on the other hand, when I want to add a new task or edit a script, I'm more interested to think i terms of "garage lamp" or "sauna temperature".

One way to, partly, solve this could be a possibility to have several names (or one name and one or more alias) of a device. I should also be possible to sort on any of the names in the device list.

An even better solution would be, as wallebalboa writes, a new type of property that mirrors an excisting property (in another device) but with a different name (in some way similar to replication). With that property and a null device properly named I could create what he call a "real world" device (as a programmer I would call it a virtual device) and hide all the technical stuff of that IO. I could also create composite or higher level devices e.g. a device named "Garage" that consist of a front door, a back door, temperature and a water valve properties that orginate from different hardware devices. This property would also open up, in a way, for non programers to create there own devices.

I guess you have to be from Sweden to get all this

Makes a bit more sense now however you can still achieve all of this with the already provided null, script and hardware devices.

Example:

Hardware device puts the state of the garagedoor into the receiveddata property. Script Device handles this receiveddata property and puts 'realworld' labels into Null device properties like Open and Closed. If you then want to have more devices that all have the status of this garagedoor, you just add some extra SetPropertyValues in the script that address the extra Null devices that hold the garagedoor status. Mirroring is done from a script and it will never get any more flexible than that.

Of course you could do it the way you suggest, i have tried. But when the number of devices increases it will very hard to maintain such a system. At my last count I had approx. 70 "hardware" devices in my system, then i would need (at least) 70+ script files just to copy data back and forth to my 70+ "realword" devices. When you change/move/add a device or the system starts to misbehave there will an extra layer you have to deal with besides all the other tasks and script files that take care of the "intelligence" of the system.

Correct of course!

Why so many different hardware devices?
I got one tranceiver hardware device and one ELK M1 alarm device and one X10 device and those three devices handle all of the sensors and control I got around. Curtains, lights and appliences, garagedoor, doorbell, temperature sensors, PIRs etc etc. Only three devices all controlled through three script devices and three null devices for display purposes in the swremote.
Why see a single node as a separate hardware device??

Good question
I use OneWire bus with digital, analog, counters and temperatur IO, I have wireless switches (similar to X10) and dimmers, i use Advantech IO PCI cards (input, output and counters) and I am looking into using the Omegabus with theirs whole range of different IO modules. Many of these IO's need some kind of setup (digital may need active=high or active=low, input or output settings, counters may need prescale or start value settings and so on) witch are different for each hardware IO point. To be able to deal with this from HB every hardware IO is a device with varying numbers of properties (depending of type of IO). But for my "rule machine" (tasks and scripts) there are only (mostly) one property for each device that is relevant. That's the reason it would be nice to have the possiblity to crate "realword" devices witch duplicates (some properties) my IO devices

Hi,

I understand the problem very good. I solved that in a different way. I use the HB with WAGO-nodes (http://www.wago.com). I've created a hardware interface for the nodes. Then I've created a couple of basic devices (lamp,switch,tempsensor, etc. and some variants of them). This stuff is done with the SDK for plugins. Some programming knowledge is needed of course. But I can imagine that the idea behind of my solution could be transferred probably to other hardware systems.
So I can assign a device to one (or when needed to more) I/O pins of the nodes. The devices itself have an additional property which is the I/O pin adress of the particular node it talks to. I call the devices after the "real world" (corridor lamp, wall lamp, wall lamp switch etc.)

Great ... now we getting on track Your WAGO solution sounds optimal! Are you willing to share your source so we can modify/learn/reuse to our modules? are you using TCP or any industrial bus? (I have been looking in to the Beckhoff solution my self ... but it ends up too costly...)

This is probably the best way to structure the device/interface of HB.
"Real world devices" = HB devices = things that you control (with familiar names ex. lamps and doors).
Interfaces = stuff that we control freaks put there to control things (ex. a WAGO node or a general relay card.)
However I now and then end up wanting to setup a null device for a "control device" too. Typically when its not reasonable to wright interface/device code.. For example when the property values just comes into HB from external control, general serial device or scripts. then its just nice to set up a null device for the hardware and it would be nice to mirror the data to a null device of the "realworld devices".
It could also sometimes be nice to set up "composit devices" or "super devices" with properties mirrored from different "control hardware" without setting up scripts or tasks to update the properties.

We are just trying to setup a good data model for configuration and daily changing of tasks to grow with.
Ideally i would just deal with "realworld devices" and no "control devices" in tasks and GUI after the hardware configuration is done.

the wish would be a propertytype wich had the selection of a "replication" property.
I will go on wishing, its soon christmas... :)

kind regs Anders

Of course, I can share my sources with others. If anybody interested in it please email me. The WAGO nodes are not that common I think. Thats why it may be interesting for freaks.
It works using UDP protocol which carries a Modbus-protocol.

peter