USB boiler connection.

[Dave Plowman (News)]

OK. Senior moment.

I swallowed hard about paying roughly 350. I build my own desktops to my spec.

[John Rumm]

The vallient boilers I was looking at while back had PC diagnostic software - possibly USB (although may have been serial).

For general control etc, USB would be less desirable due to the difficulty of extending the range on it, serial or ethernet would be better.

[Dave Plowman (News)]

I realise that but I think we're at cross purposes. I don't want or need to be able to access the controls from any distance or indeed regularly. Would just like to simplify the operation of those I do when I need to. For example changing the clock setting twice a year.

And pretty well every laptop has a USB port. My programmer has multi-function push buttons and at my age I simply can't remember what the sequence is without reading the instructions. Same as with many other such things. And I bet I'm not alone in this.

[John Rumm]

Yup, I realised that was your main requirement. However, from an engineering point of view, if you are going to implement something like this you may as well make all the options possible - basic controls, stats, low level config and diagnostics etc.

Many of the boilers are moving to data bus system for interfacing their primary controls, and there are some standards emerging. So the possibility of adding remote such as you would like is getting more rather than less likely.

I know what you mean - some of these things are less than intuitive!

[Dave Plowman (News)]

Possibly. But of course each maker would make damn sure the software wasn't freely available. I was thinking of a simple but universal thing. Like the basic diagnostic ports on all cars. By law.

Mine already has a buss for zone controllers. It doesn't use a D9 socket but is TW&E so might well be standard serial.

Thing is I have no problem with the most complicated menus on TVs etc - just things with tiny screens and buttons scattered at random.

[Theo Markettos]

Boiler programming is like programming a 1980s video recorder. Video recorders have become easier to control, boiler programming hasn't.

But I'm a bit worried by the security implications of 'network' boilers. I've already seen a boiler where the programmer crashes, leaving the heating jammed on. But what happens if there was a boiler 'virus', that made all the boilers of that type run continuously? The national gas supplies might run short rather fast. Or people might expire from heat exhaustion. Or indeed hypothermia, if the virus manages to (say) reflash the controller to be inoperable. If a few hundred thousand boilers went down at once, that would be big trouble.

So a simple serial or USB socket on the side of the boiler might be an idea, but people putting IP stacks and ethernet connections near boilers needs to be thought about rather carefully.

Theo

[Rod]

Reminds me of the refrigerator in the 'canteen' at work. Still has a label proudly claiming it is Y2K compatible...

But I sure do hope I don't have to manage Symantec on boilers...

[Tim Watts]

On Sun, 24 Jan 2010 17:21:19 +0000, Rod wibbled:

Don't worry - if it's big and ugly enough to sport a full-on embedded OS, there's a much greater chance of it being Linux than Windows-embedded.

If it is Linux, look out on theregister.co.uk or slashdot for someone's project to rebuild and tweak the OS...

If it's not linux, it's then likely to be something *like* VxWorks.

Then, next, if it's a very lightweight 8 bit microcontroller (think PIC, AVR) then it won't be any of the above, and most definately not windows :) This is the category *I* would expect a boiler to fall into, but Geoff would know for sure.

Having a full-on OS is handy if you need to run a pretty screen and a web interface and do lots of other things in a multitasking way. If however, all you have is a bunch of sensors, a few control outputs and some poor sod tapping morse code at you through 3 buttons with a minimal display, an 8bit jobbie is cheaper adn more likely to be reliable and not really much harder to program.

[John Rumm]

Indeed. And even if it does support sophisticated network management you can bet the number of installs where it is used will be few and far between, and of those very few will be exposing any of that control to the internet one would hope.

However, you could see the attraction of being able to switch your heating on from your mobile when you are returning home sooner than expected, or being able to check its still running when on holls during a cold snap.

Most of the embedded systems I have developed over the years have not used any OS as such - just a basic scheduler, message passing, and timing mechanisms developed for the project in hand. That includes some large military systems with over 80 CPUs spread about various bits of kit.

The time an off the shelf OS becomes really handy is when you need to support standard (and complex) protocol stacks like TCP/IP, Bluetooth, GSM/GPRS/UMTS etc - then its not usually worth the development cost of rolling your own.

[geoff]

In message , Tim Watts writes

Would he ?

Don't forget boiler pcbs have evolved along with everything else.

A lot of it now is not really accessible, but still fairly primitive

[Jules]

It is frustrating. For some devices, I sometimes idly ponder the idea of doing a hardware equivalent of 'screen scraping' - replacing pushbuttons with (or paralleling with) with relays, such that I could use a digital I/O board to "electronically press buttons" in the necessary sequence.

ISTR there used to be all sorts of parallel "lots of I/O channels" boards around - doubtless these days RS232/Ethernet/USB ones exist.

cheers

Jules

[Adrian C]

Particulary those that are sold as business PC's rather than consumer.

[Tim Watts]

On Sun, 24 Jan 2010 19:48:16 +0000, geoff wibbled:

:)

I assumed you'd notice something microprocessory on your PCBs? Or do you not see those, because you don't recon them (yet)?

Just out of interest - what is the preferred control logic on a typical modern module? One fat custom chip or raw logic (eg 74xx TTL / 4xxx CMOS) or something else (I don't discount bunch of relays and a few transistors as an option)?

If it's anything like the electronics in my VW and SWMBO's car, I think I prefer relays!

You mean it's in a sealed tin can? Or just not deemed serviceable so no diagrams are provided?

Just curious - the few boilers I'm familiar with have generally had a simple gas valve with a thermocouple input + demand signal and a separate spark generator (massive transformer in the case of the 50 year old oil burner I remember).

Cheers

Tim

[Andy Dingley]

PICs are obsolete for this sort of task. An Arduino does analogue and USB (or serial) very easily, and there are plenty of other cheap boards that will do 10BaseT if you wish. Bluetooth is still a pain, Zigbee's easier if you're already using it.

If you open source the work, I can think of two, maybe three others in need. It might make batch PCBs worthwhile.

[Tim Watts]

On Sun, 24 Jan 2010 18:39:04 +0000, John Rumm wibbled:

Totally. If it were me, I'd go for keeping the boiler module simple, with a PIC/AVR/etc exposing a serial connection (which doubles as the engineering interface). Then sell the Internet webby box for suitable markup as a plug in option and that doesn't need such massive reliability and could be a little baby linux box. Could be an AVR with ethernut or something but I'm not sure I'd fancy that exposed direct to all the sh*te flying around on the internet. Good use of linux - free solid webserver, free firewalling and excellent IP4/6 support - and can still do all that on a cheap CPU.

If you need predictability of timings and less random stuff going wibble at you in an untimely manner it's the way to go.

Or you're lazy and the customers will stomach the cost of a box with a chunkier CPU/RAM/Flash in it :)

OTOH low development costs might imply "Here's linux, slap some perl scripts in and it's a product" :) I guess it depends where the software vs hardware balance lies and if wasting a bit of CPU is relevant or not.

My last job, I built an entire appliance (we'll we marketed it as an appliance as in plug-and-go, but it was in fact a 2U server) out of CentOS, Apache, Postgresql and perl. Perl handled muliplexing IP servers, binary de/encoding and database interfacing. I was quite up front - I said: "We'll do it in perl until it works, then recode anything in C that can't cope with the load" - this was due to it being highly experiemental in the prototyping stage so quickness of development and tweaking was important.

As it happened (secretley I wasn't actually surprised) we didn't need to shift anything out of perl. The database was the choke point - everything else combined took 1% of the CPU. Fortunately, I like writing modular perl with proper libraries and test harnesses so it wasn't a big ugly mess that some script hackery can be (*boast* cough).

[Onetap]

Interesting post (well I thought so, but I'm a sad git) here re the diagnostic software for Vaillant boilers;

do the vrDIALOG diagnostic software for =A368 ish, but it seems they also offer vrNETDIOALOG software which enables the boiler to be controlled over the internet, although not yet available in the UK.

[geoff]

In message , Tim Watts writes

Yes, but they're nor unprotected devices with open source programs available

You can only really look at inputs and outputs

While it might be possible to reverse engineer such a beast, given the dozens of different ones, it's just not economically worthwhile

We're not an academic establishment - inputs create outputs ... or not

If we did reverse engineer and re-program devices, you can imagine how long it would take the manufacturers to jump on us

Luckily processor faults are not that common, although they are becoming increasingly so

You're possibly under that misunderstanding that there might be any forethought or cohesive planning

I think that they use whatever the student who designed that particular pcb used in his project

Diagrams ?

We have the pcb, the interconnection diagram in the manual, and, if lucky, a functional description

the rest is up to us

[Tim Watts]

On Sun, 24 Jan 2010 14:15:17 -0800, Andy Dingley wibbled:

Agree. PICs still get shoved into plenty of new build electronics, but often because the designer likes PICs and has a massive code library at the ready. I was lucky - I only got into this stuff a few years back, so I weighed AVRs and PICs and decided I liked AVRs.

[which is AVR Mega based for anyone who doesn't know]

I've not used Arduinos (happy slapping AVRs onto boards) but they do look a nice piece of work. Very modular. Not a bad price if you need something that can fairly easily do ethernet or USB.

Worth remembering though that AVR ATMegas/Tinys are well available in DIL packages for less than a pound (8 pin) to a few pounds (14, 16, 28 and 40 pin) and require potentially *no* support circuitry whatsoever until you get to the IO requirements (be it opto-isolated inputs, relay outputs or USB/Ethernet/Serial) so the good old days of hacking up something on veroboard is still very much a practical proposition. Running a programmed chip can be as simple as slap a battery on it and watch it go.

A fancy programmer like the STK500 (I have) isn't massively expensive and there are lots of cheap make do chip programmers available as well, so it is a hobby anyone who can hack some C can get into. Atmel do a very nice free development IDE (AVRStudio) with built in emulator so you can hack code and debug it without even touching a real chip at first. For the linux/BSD boys, GCC targets the AVR too and produces AFAICS sensible code

- in fact AVRStudio supports GCC.

[Bob Eager]

Even my son's school robotics club have moved from PICs to Arduinos!

[Tim Watts]

On Sun, 24 Jan 2010 22:41:26 +0000, geoff wibbled:

That much I guessed. I really meant I assumed you'd have a feel for whether AVRs, PICs or some heavy processor was in vogue.

:)

:(

Silly me. I was thinking people thought about shit. But then you reminded me we reside on Planet Earth.

I know that student. We have one. Do it in perl, I said (we were academic and did think about shit). He argued well in favour of python. But he did do it in perl as requested. Until we found the lump of embedded python hidden deep down that perl called to do the interesting stuff. Good lad though, works for Google now...

No, I suspected that...

I wonder if they bother to set the fuse bits to prevent dumping the flash out...