End-user unit replacement

I need to give an end-user the ability to replace units, whilst limiting the "damage" he can do elsewhere.

Basically, take out a faulty unit, put in a good unit, have the code for the old unit transferred to the new unit. We can assume that the user will have the serial numbers for each unit, we can't assume that the "new" unit will actually be new (ie it may already be programmed and have a unit address, and the address may well conflict with others on the network).

He has no need to change the code in the unit other than as a direct replacement, indeed as far as possible I want to prevent that. (Ideally this would mean not giving him Toolkit. I'm happy at the C-gate CLI if that helps, and could write an end user tool if I knew how to do it at the CLI myself.)

Any suggestions?

 

It might be that I do not understand your question fully. But if you support the end-user's install, you would have the recent code and serial numbers, so you could program the new unit on your work-bench and hand it to the end user ready to plug-and-play.

 

You cannot program a unit at the CLI, you have to use Toolkit. Unless you program the unit for him, I can't see an easy way without having to explain unit conflict resolution, idetinify the right units etc...

 

Ah, common sense! Unfortunately we don't always get to apply it!

We do support the end user and we're regularly on site, however to fit around other engineers, access to affected areas, etc they'd like the ability to do the installations as suit them, not as fit in with site visits (or paying for extra visits, which is fair enough I guess). The nature of the site means there have been lots of changes and there are spare units floating around, so I don't get to ship a programmed replacement (which is what I would prefer to do).

I think I will see if there is a way we can start doing this (eg they ship spare units to us so we can ship them back programmed). But they have asked for a tool to do this, so I have to investigate.

 

I thought Toolkit basically programs the unit through the CLI? Or does it use another interface? Or is it just that the commands it uses via the CLI are not documented?

 

I can't answer beyond "you have to use Toolkit". Maybe someone from Clipsal can answer your more specific questions.

Disclosure: I used to work for Clipsal, but I don't feel it correct for me to discuss the unit programming aspects of C-Gate and Toolkit.

 

Re-program the new unit via the internet.

If there is a CNI on the network, open up the port in the router and then connect from your toolkit.

I have this at one isntall and small changes are a breeze. One phone call from the owners and I do not have to travel to their place to make changes.

The only drawback is that Toolkit only supports an IP address and not a named address. Use DynDNS or similar and you never need to know their IP, just their DDNS address.

Mick

 

Good idea, but this is the kind of site that they are unlikely to allow remote acess to. (If I go to site and need Internet access I have to use my laptop with a 3G mobile connection!)

I might suggest it as there are other uses for it - perhaps a dedicated DSL line that will be disconnected except when needed - but it's unlikely to be an option.

Putting a new CNI in, just for re-programming units (ie without a live network on it), might work though.

 

I hope someone can as I'd be very interested in this.

It might not be too hard to reverse engineer but Clipsal might not want me to do that (in which case I'd respect that), or it might just be undocumented and subject to frequent change.

I would have thought this would be relatively simple now that C-Gate has access to the application code, and I'd be surprised if Toolkit doesn't just tell C-Gate to program the unit (ie the intelliengence is in C-gate not Toolket)?

Like I said, if this is just the sort of thing Clipsal don't want people like me playing with just tell me and I'll back off!

 

You must use Toolkit for the re-programming of units. The only other options are Learn Mode (for those that only need standard functions), C-Bus V2 (for the nostalgic) or C-Bus V1 (for the semi-fossilised).

Let it be enough to say that Toolkit communicates with C-Gate in it's own special way and that this way is not open to the public. Try and reverse engineer it and you risk making a very big mess and you can kiss your warranty on units that don't work properly goodbye.

If the site won't allow an ethernet connection would they allow a phone line and a CBTI?

Another option is to teach the people on site how to use the Toolkit Reinstall feature. They just need to put the replacement unit at address 255 on the network, select the original unit in the database and click on the Reinstall button on the database. This will re-address the replacement unit to match the address of the original unit and then transfer the programming from the database into the replacement unit. This works regardless if the replacement unit has been previously programmed, it just needs to be put at address 255, and there's no need to open the unit UI.

 

I know that it can only be done with Toolkit. This is because making a wrong move with setting the memory addressing can make a unit permantly inoperable. The smarts in programming a unit is in both C-Gate and Toolkit which is why it is locked to toolkit. C-Gate provides a very raw interface to programming units and used by itself would most likley lead to woe and misery.

At the time of creating Toolkit and C-Gate it was necessary to make it work this way because of the huge amount of work involved and ensuring it was spead across all devlepment teams.

It has been discussed in the past about moving the "business logic" of programming back into C-Gate so a programming interface could be made available, allowing anyone to create there own commissioning tools, but this is a large undertaking and won't be happening soon.

In regards to remote reprogramming via a CNI, you should absolutely never expose a CNI directly on the Internet. You should use a router with VPN capabilities and VPN into the network that the CNI is on and then connect to the CNI once your remote machine has been established on the local network.

 

So that's a no then

I think they'd prefer to know how to program the units. I'm just trying to avoid that because Toolkit gives them a lot more capability than they need, and while I can probably make a living fixing their mistakes I'd rather they were only given the tools they needed.

The problem here being that the unit will not usually be addressed as 255, because these are usually units swapped out from somewhere else.

This is the biggest issue I face, to be honest. It means resolving address conflicts correctly, and I'm not sure I trust them that much!

As a side note: Why when Toolkit resolves conflicts does it not take into account serial numbers? If it sees 2 units at the same address, where one's serial number is stored in the project against that address, and the other is not, why does it not always correctly pick the one to move?

 

Fair enough, that's the answer I was looking for (not the one I wanted, but the one that makes it clear how things stand and why they're not about to change).

Consider this a vote for that one on the wishlist!

Agreed, that's the only way I would do it. In any case, regardless of the commonsense security issues, all the sites I work with have multiple networks and making a CNI directly accessible doesn't scale very well.

Thinking more about this, though, I would have to kill the site's application to give me access to the CNI, so that would also be a pretty strong "no".

 

New idea:

Assume I have C-Gate running and a head-end application running through it that I can't shut down.

1. Is there any way I can run Toolkit on a different project to talk to another CNI without breaking the above? If not, I can still set up a separate PC for this, so my next question is:
2. Is there an easy way to extract the programming for a single unit out of a large project to create a new project containing just that unit?

If I extract the details for a single unit and set up a new CNI (or PCI) just for programming replacement units, that would give me a lot of the isolation I'm looking for. By extracting the one unit's details the room for error will be pretty limited.

I can probably hack something at the XML level if necessary.

 

You cancertain have a second project running (on the same or different c-gate) talking to another cni/pci. However, even if this seconf project only had the one unit, it will need to scan the network and then find all the other units possibly being almost as confusing as if they used the already setup project.

 

You misunderstand my intention.

I get (ie sell!) the customer a new CNI or PCI and bus power supply, wired onto a board (a couple of feet of DIN rail screwed to some plywood would do). Therefore when it comes to programming a unit they connect it to this standalone network, run Toolkit with a project I create for them containing only the CNI/PCI and the unit they will be programming. No duplicate addresses, no other units in the code or on the network. Nice and easy to set the unit address and program it (or set the unit to 255 and reinstall).

The people doing this will have the necessary electrical skills to do this safely (they'll be installing it into the real network when they're done), it just simplifies the commissioning of that unit.

Since we're only talking about a single network it won't need a C-Gate licence, so a separate PC with just the tools needed will be best I think.

So the key point is the second one I raised: how best to extract the one unit being programed from the project and create a new project from it.

Doing this at a raw XML level is probably best (it means I can write some code to automate it) unless there's a good reason not to?

 

Why?

What are the chances of the system being "hacked". Have you got any real life experience if that is the case.

Lighting in a domestic is non-critical and hence even if it is hacked, the consequences are extremely low if something start playing around with the lights.

VPN is not always possible in a domestic either due tot he limited features of the router used.

Mick

 

From the sounds of things, this site sounds much more like a commercial/industrial one than domestic...

 

Certainly that would work. There are no such things as C-Gate licenses anymore so it wouldn't matter if there were 100 networks!

The easiest way to create a new project is to copy the existing project and delete all the unwanted units. (Don't recall if there is a project copy operation, either way you should be able to backup the project and restore under a different name).

 

Mick,

Ha ha ha, funny joke Mick. For a second I thought you were serious. But of course no one would believe for a second that doing that would be in any way professional or responsible.

You all most had me, needed to check to see if your email address was from Microsoft.