Absolute "minimalist" CBUS system

I'm contemplating the prospect of using CBUS hardware as an avenue to connect the TCP/IP world to the RS232 or IR world. What I have in mind is using CBUS to help the iPad talk to serial or IR controllable devices. So what comprises the most minimalist CBUS "system"? Can it comprise just a 5500CN and a 5034NIRT (to control IR devices), or a 5500CN and 5500PC (to control serial devices)? Obviously there will be an iPad app required, and I have access to considerable programming horsepower there, I'm just contemplating the intricacies of using CBUS hardware to achieve the required outcome.

 

There's a wealth of IP <-> RS232 and IP<->Infrared devices.. I'm not sure that C-Bus would be an appropriate choice for the job.

Duncan.

 

What I want to do is get iPad to do volume control of my IR controllable pre-amp. I have the CBUS hardware in place already (C-GATE>CNI>CBUS>5034NIRT>pre-amp) but I'm trying to get the application more universal to make it worthwhile for the app programmer to take on the job i.e. to put a CBUS module in as part of their app.

 

I use a Wiser to do what I think you are trying to do ... I have 3 MOXA 5150 RS232/RS485 to IP convertors on my IP network, one for my Pentair ComPool 38xx Pool/Spa control (protocol a royal pain to manage in Wiser Logic), one connected to a Paradox Evo 48 alarm system (that also controls the garage doors and entry doors in my home, protocol a bit of a pain to manage in Wiser logic), and one for my Daikin VRV AC system (via CoolMaster 1000D, hardware arrived 2 days ago and I haven't started on the code yet, but it looks more straightforward than the other two). I also control my Yamaha RX-V3900 AV receiver via IP (so can mute the volume in the cinema, bellow "Dinner's ready" and the kids can hear me The Wiser effectively is a CBus Group to IP interface ... Note that I have only the single IP server port free on Wiser to use now though ... the 4 client ports are all in use ...

There are three advantages of doing things this way 1) you get a Wiser interface in 5 minutes to all your devices (but it looks and acts a bit crummy because the Wiser UI is intentionally very generic) 2) you get decent looking interface on a CTouch in about an hour of fiddling about placing buttons 3) you get a fully custom interface in a few hours be connecting directly to one of the other three ports on the MOXA directly from, for example, PHP code running on, for example, an Apache web server, running on, for example, a cheap Linux box sitting on the same IP network.

Robust programming in the large on Wiser is pretty tricky ... Pascal is probably not the best language chioce in the world for this type of programming, and a few design choices that have been made on this particular implementation make it even worse, but it is possible and it does work reliably (Clipsal guys, this is not a criticism, I can guess why you've done things the way you have, but error handling, reusable modular code and your version of Pascal just isn't possible).

There are also Moxa boxes that are programmable (from memory they have an ARM in them and run Linux, so you should be able to build anything you like with those).

If you choose to go down this route drop me a line and I can set you up with a few code snippets that will side step a few issues that I ran into getting all this to work ...

 

Understood. I guess one way Wiser could improve this is if it had a greater selection of widgets (like a pool/spa widget, garage door widget, simpler AC widget, etc) or if Wiser supported widgets with user specifiable images for on/off/intermediate states. I don't know if this is possible, just thinking out aloud.

Out of curiosity, which language would you consider a good choice?

 

Is the C-Gate manual the only CBUS documentation an iPad developer will require to make the iPad talk to CBUS through C-Gate? I want the iPad to tell CBUS to get a 5034NIRT to send "volume up", "volume down" and "mute toggle" over IR.

 

Yes, I suggested this a while back http://www.cbusforums.com/forums/showpost.php?p=27299&postcount=9

IMHO you want both user defined icons for states, and a way of grouping those icons in a screen size independent way, a lot like you can on a CTouch

Anything with better IO handling ... always been a Pascal shortfall.
As soon as you have a serial or IP port open, you know you have a protocol to adhere to. If it is based on simple strings with known terminators then CIS Pascal is just enough. As soon as it is not ASCII strings (e.g. a bit stream) of random length (e.g. a header byte tells you how much data to read) then the current logic engine language is a bit of pain to use. For example, there is no way to read 1 byte from an input stream, you can only read all the bytes, so the programmer has to do his own second tier IO buffering. Also there is no way to see how many bytes are in the input buffer. I saw in another thread someone wanting to wait a short amount of time for a second byte to arrive in a IO stream, one presumes they really want blocking IO of defined lengths too.

Even when the protocol is string based, Pascal's (even as extended by ClS) is pretty minimal. We sort of have C's printf in the form of format, but no scanf to parse a string into components (there's readln, but not from IO). It'd be nice if format, append & copy had siblings that returned a string so you could at least dodge so many temporary variables when string parsing ... Also Ord sign extends it char when it returns an integer, so ord(chr(hex 82)) is less than ord(char(hex 7e)) ... this bit me for a while in some crc code ...

Pascal doesn't have much in the way of error handling, and without goto ... I think I know why it's not implemented , it has none. No way to prematurely jump out of a loop (break) when an IO pipe disconnects for example ... throw and catch an exception anyone?

It would be really nice if you could call things like delay, exitmodule and friends from subroutines. Generate a run time error if they get called from the initialisation code, but affect the calling module if they are not. All my IO code has to check on the error status on every code loop and return the error code from functions to the main module so it can reset itself if it all goes to custard. If you could call exitmodule from a subroutine you can at least bail out to a known place (the start of the module next time round) to work out what went wrong.

Lastly, a function which takes a tag as an argument and returns the group number of that tag would allow generic functions to be called with the tag name as an argument (I'm surprised this isn't already there, but I couldn't find it if it is). One that does the reverse would be handy for said function to be able to print out a decent error message ... which I do down a second IP port by the way ... would be great if that was standardized too.

I hope this is viewed as constructive and not critical, as I've said before, I really like the Wiser and where it's positioned ... the few wee suggestions I've made above would just make protocol handling so much easier, robust, reusable and portable.

Dave

 

Thanks for the detailed feedback Dave.

Developing the logic engine has been a difficult balancing act. We are trying to implement something that is easy for a beginner to understand (hence the choice of Pascal) and which makes the most common tasks simple (hence many of the language extensions). The downside of this is that there has been less emphasis on making life easy for the experienced programmers who are wanting to do more sophisticated things.

This is the most common case, so we made it easy.

I have put this in our system as #19465

I have put this in our system as #19466

I have put this in our system as #19467.

I have put this in our system as #19468. I assume that this is in Wiser, not in PICED?

Adding a "break" procedure should be possible. I have put this in our system as #19469.

The current code structure makes delay inside a subroutine impossible, although I understand why it would be handy. Calling exitmodule might be possible, but also quite difficult. I have put this in our system as #19470.

We can already sort of call a friend by using e-mail. With some sort of SMS gateway you could text them directly.

See logic help file "C-Bus Tag Functions" topic. For Wiser, you will only be able to use the compile time versions of these because Wiser does not contain a copy of the C-Bus tag database.

See logic help file "C-Bus Tag Functions" topic. For Wiser, you will not be able to use these because Wiser does not contain a copy of the C-Bus tag database.

I am not sure what you mean by this.

We always value constructive feedback. I can't guarantee when these ideas will be addressed, but we will certainly have a good look at them.

 

I think you have achieved that Pascal is a good choice for your tradeoff, and if you augment it with library functions over time you'll be in good shape to handle the sort of home integration (as opposed to just home automation that the world is moving to. I'm getting very close to removing all my Saturn wall switches and putting Logic enabled touch screens in their place, because the interface to just so fast compared to the Wiser phone UI. If there was a Bluetooth and IR blaster & receiver in these IMHO you would rule the world. Actually thinking about it, don't the new Spectrums have RS232 and a logic engine? (== IR blaster)

Yes Wiser

Note that ExitModule gives an OK solution to the Throw/Catch ... the start of all my IP modules has this code

Code:

if NOT ClientSocketConnected(Socket) then begin
  repeat
    OpenClientSocket(Socket, IPAddress, Port);
    delay(1);
    WaitUntil(ClientSocketConnected(Socket) OR (ClientSocketError(Socket)<>0));
    until ClientSocketConnected(Socket);
  end;

So a subroutine that sees an error can throw an exception with ExitModule (using a global variable for more info if need be), and the code at the start of every module can catch that and get the world back into shape ... It's a relatively clean GoTo

Compile time is fine ... it seems slightly odd to me that tag tokens like "MyGroup" is not just an integer expressions evaluated at compile time in the same way that hex values are.

OK, understood.

There is not a standard way to get a decent sized error log out of the Wiser ... SystemIO strings are one way, but it'd be really nice to have writeln working, down TCPIP port so I can either a) telnet to it or b) have a window in PICED that displays the log. The nature of some bugs are that they occur after a few days, so a means to log a decent backtrace would be really handy. At the moment I just use one of the existing ports (which means turning off some other module), but it would be nice if I could just augment my code with writeln and watch the log as it runs ...