Generic IP Device

[roussell]

It would work like the Generic Serial Device, just over TCP or UDP - Kind of like a combination the GSD and the External control device... Specify a protocol and port and wait for commands to come in (HEX or ASCII) OR send commands (HEX, or ASCII) to a remote address/port. Give it the ability to add/edit/delete HB properties. I can think of a ton of uses for this right off the top of my head - control of/from other computers (non-windows included) control of networked devices like the ELK M1 or various set-top boxes (TiVo, Pinnacle, etc) Getting excited just thinking about it...

Terry

[ScottBot]

I've had something similar on my mind like this as well. My thought was just something simple that would connect and send an ASCII string. Nothing complicated like the command mappings needed for the GSD.

I was thinking of just something for controlling things via TCP using URLS (GET requests). The device could also retrieve the response data and put it in a property (for web page data).

What do you have in mind that would require hex/binary data to be sent over the connection?

[roussell]

What do you have in mind that would require hex/binary data to be sent over the connection?

Actually, nothing in particular, all of my other PCs and microcontrollers can send/receive ASCII data just fine over TCP. Before submitting, I went back and added HEX for others that might would have a need. If there doesn't seem to be a need for it then I'm fine with ASCII only.

I agree that the simpler, the better. For me; as long as I can get/set properties, and maybe create/edit/destroy properties as well then it would fulfill my needs just fine. I do like the URL option and being able to process http responses.

Another V3 question - Are you looking at incorporating any client-side (swremote) processing capabilities? I ask because I'm working on replacing my thermostat with temp sensors and login in HouseBot. On my control panel, I have the typical UP/DOWN buttons and a "setpoint" display. To correctly increment/decrement the setpoint - I fire a task when one of the up/down buttons are pressed that launches a script to raise/lower the setpoint by 1. It works fine, I'm I have been impressed with the response, but I hate having to send so much traffic over the wire if I don't have to. It would be nice to have simple math and conditional logic on the swremote so I could raise/lower the setpoint, then send the final number to the server.

Oohh yeah, that made me think of something else - Math functions (C++ Operators would rock) in tasks for properties/variables other than time and the ability to have multiple top-level branches - something like:

(This example uses the raise/lower problem above, which wouldn't be needed if client-side process was introduced, but it was the first example off the top of my head - Hopefully you'll get my meaning . There are tons of other uses for this)

All of this code would be in one task:

If ('HVAC Control.Setpoint Request' is Equal 'Raise1') Then
Math 'HVAC Control.Setpoint'++
Change 'HVAC Control.Setpoint Request' to ''
End If

If ('HVAC Control.Setpoint Request' is Equal 'Raise5') Then
Math 'HVAC Control.Setpoint'+=5
Change 'HVAC Control.Setpoint Request' to ''
End If

If ('HVAC Control.Setpoint Request' is Equal 'Lower1') Then
Math 'HVAC Control.Setpoint'--
Change 'HVAC Control.Setpoint Request' to ''
End If

If ('HVAC Control.Setpoint Request' is Equal 'Lower5') Then
Math 'HVAC Control.Setpoint'-=5
Change 'HVAC Control.Setpoint Request' to ''
End If

Something like that would allow me to eliminate external external script and consolidate two tasks into one. Alone, either the Math function or the login consolidation would be a great addition. Both together would be phenomenal.

I better stop now, I have more ideas but it might scare you if I keep going.

Thanks,
Terry

[ScottBot]

To correctly increment/decrement the setpoint - I fire a task when one of the up/down buttons are pressed that launches a script to raise/lower the setpoint by 1.

You can do Property value addition and subtraction now in the SWRemote. It's not as advanced as you may be suggesting, but it should suffice for most things. For example, to increment a numeric value by 1 from a Property Change button, set the New Value to +=1.

If you search for increment in the online help, it will explain it better than I am doing.

[roussell]

For example, to increment a numeric value by 1 from a Property Change button, set the New Value to +=1.

Wow, just when you thought you had RTFM enough:oops: ... That works great, thanks for the info Scott. Guess it's time to go RTFM again.

Terry

[Whistler]

I've had something similar on my mind like this as well. My thought was just something simple that would connect and send an ASCII string. Nothing complicated like the command mappings needed for the GSD.

I was thinking of just something for controlling things via TCP using URLS (GET requests). The device could also retrieve the response data and put it in a property (for web page data).

What do you have in mind that would require hex/binary data to be sent over the connection?

Hi ScottBot,

I'm new here and am considering to buy HouseBot for my Automation needs.

I'm currently in the construction phase of my house and will implement the Luxom Home Automation devices.
They have an Ethernet and RS232 module to communicate with the BUS (both use serial like commands), but since I'm already going for the ehternet device it would be useless to also buy an RS232 device just for connecting my 'HouseBot'-controlled touchscreen.

So i'm VERY interested in a TCP device supporting sending and recieving simple ASCII strings.

An example of how the Luxom protocol works...

*S,0,2,56;
* = Start Message
S = Command
0 = Network-ID
2,56 = Bus-adres
; = End Message

The following Commands are available:
T = Toggle
S = Set
C = Clear
A + Z = Analog (Data : %, °C, km/h,...)
P = Ping (Request Status)


Any pointers that will help me decide on going for HouseBot are more than welcome

[ScottBot]

Whistler,

Welcome! I wish I had a better answer for you, but there is no native support in HouseBot to do it right now. It's not that complicated of a plugin to write, but I've just never got to it.

One suggestion would be to find a way to do it in VBScript and use the script device. I don't think VBScript supports sockets directly, but there may be some 3rd party controls that would work. I'm not a script expert.

Another option would be to use the Execute Command device and calling some program to do it and pass the data on the command line to the program. Curl might work, but I'm not sure.

[Whistler]

Hi Scottbot,

Although not the answer I was hoping to get, thanks for your reply.

A side question:
I have a lot of experience in C++ programming (+10years) and did also some IP socket programming in the past.
This of course would be my first attempt with writing a plugin for HouseBot.

Is the Generic Serial Device written as a plugin and if so could the code be shared so I would have a base to start from?
This migh result in a Generic IP Device that can be shared among anyone in need for it.

Thanks in advance for your reply.

[ScottBot]

Is the Generic Serial Device written as a plugin and if so could the code be shared so I would have a base to start from?
This migh result in a Generic IP Device that can be shared among anyone in need for it.

If you download the SDKs there are sample plugins that you can use to get an idea and framework for a new plugin. The Generic Serial Device is a plugin (as are all hardware interfaces and devices in HouseBot... so anything they do you can do with the SDK), however the source is not open.

Some design options are:

• Just write a Device plugin to do EXACTLY what you need it to do. It could be written to have the specific properties and commands needed to control and get status from equipment.
• Write a generic Device plugin that just takes a 'Command' property that will get sent when changed, and maybe has a 'Received' property that displays the received data (might be tricky for binary data... maybe show in hex or make an option to show in hex).
• Write a generic IP Hardware Interface that defines commands and a Device that maps to them like the Generic Serial Device stuff. Although this may be the most flexible, it may be overkill. Using a Hardware Interface is generally the right approach if there is actual hardware involved. They manage the synchronization to the hardware resources and can abstract the functionality so if you change to another piece of hardware from another mfg, all you need is the new Interface plugin and everything else stays configured.

Hope this makes sense.

[Whistler]

Hi ScottBot,

Thanks for the reply.
I'll think and give it a go to write a Generic IP Plugin myself... it shouldn't be that hard.
Now only find the time

[maze42]

Have you found any time to work on the Generic IP plugin?

[Whistler]

Unfortunatly I haven't found the time yet... the priority was getting the houseconstruction finished. It is not finished yet, but we live there already and I'm looking into starting the GenericIP device.

Any ideas about features this device might need?

I was already thinking in the line of supporting both TCP and UDP and an option to let the device be configured to act as an IP gateway. The IP gateway would allow 'other' TCP/IP programs use the same channel of the device to communicate with the actual automation device.

Any ideas are more than welcome

[CouchPotatoe]

Again , although not the ideal solution you could use the xAP HouseBot plugin (about to exit beta into release version). It is designed to allow you to easily network all your automation devices over Ethernet . UDP (rather than TCP) is used because it allows for broadcast implementation allowing all devices control , and status tracking of all other devices without any 'ownership' bottlenecks.

You would effectively write a small PC application that converted the TCP (or RS232) lighting protocol commands to xAP - and these are automatically recognised and controllable by HouseBot as devices/properties using the xAP plugin. The BSC (Basic Status and Control) schema within xAP handles binary, level and text based devices and so can be readily applied to lighting control. For lighting there is already Dynalite , X10, DMX, HomeEasy, UPB, IDRANet and C-Bus implementations available . A fuller 'lighting' schema adds things like ramp rates, ramp times , scenes etc should you want more functionality.

Here is an example of a xAP message so you can see how simple , and human readable it is... It shows a bedside light on at 1/4 brightness A similar message is used to control lights with a class=xAPBSC.cmd and the addition of a target= parameter.

xap-header
{
v=13
hop=1
uid=FF.7761:07
class=xAPBSC.event
source= ACME.Lighting.apartment:BedsideLamp
}
output.state
{
State=ON
Level= 64/255
}

Because the lights all become network resources you could have other devices or applications directly controlling them - for example there are xAP embedded hardware devices with switch inputs that could control the light directly. This allows fallback functionality should a PC application fail.

xAP is really easy to code for too - the protocol is simple, expandable, human readable - and 'free'. There are code examples and libraries in many languages as well as Active X and .Net frameworks. This allows anyone with basic script/programming abilities to now include their own favourite devices within HouseBot without tackling the plugin SDK.

From your perspective - I realise it is one more step in the command chain (TCP <> UDP/xAP) , and I'm sure some others would prefer a direct /flexible generic TCP plugin ... but it's a lot less work and creates a very capable HA model with all your devices becoming network accessible in a standard way. xAP is effectively a glue layer to enable many disparate things to all work together . Many other devices like AV systems, mp3 players, 1-wire etc, CallerID, weather, news, email, security, hardware OSD etc are already implemented on xAP

Kevin

http://www.xapautomation.org