A Wide Variety of free 1-wire slaves arriving soon. What do you need?

[wyleu]

A bus alive heartbeat would be great.
Every ten seconds or so a brief flash would be fantastic to tell you one-wire is alive. Obviously it would require a bit of code at the head end (unless someone can think of something better , data present or summat like that).
How many in/outs could be managed ? If you need one sensor for on/off you probably need others. Using relays or the scummy NEON and LDR trick we could track pump on/offs and such like and in the sort of systems we're involved in there's normally at least two pumps around.

What's the expected maximum switch rate? ( One of the things I'll unleash  my synths on, very good for mucking around with frequency, amplitude and pulse width. ). Your talking about monitoring power meters, but there's also flow sensors.

I've got a database model of components but it's in need of a bl**dy good rewrite and this is the sort of thing that would fit with that really well. The problem for one-wire systems is there's no description above the level of the components themselves. A pump with a St Barnabus's Bone on it would become a higher level component and could allow system descriptions to work at an much more easily configurable level.

That makes for systems that can easily respond, The tank temperature is 10 degrees below the array temperature, is the pump on? If not trigger an alarm. Add a simple pressure sensor to a StBB and you could detect system pressure loss cheaply. Has the system stagnated and vented?  ( I tried this with a insulating fitting in the high point of the rig and looking for conduction across it. If there was water present the circuit was complete )

As you see lots of ideas, but once again well done for doing this, it's excellent work.

[ericw]

The Write to Scratchpad routine is implemented, with One Wire Viewer being able to change the resolution for test purposes. It would be fairly trivial to get it to work a LED.
However bear in mind that the initial aim was to create something that unsophisticated users could use with off-the-self software to give additional functionality.
Once you start customising the software at the master end, a lot of restrictions are removed and many more things become feasible.

One of the aims of the post was to solicit information about what functions would be useful.

[StBarnabas]

Wyleu

calling this a StB sensor is misleading as Eric has done all the hard work of getting the timings right.  To get the PIC to mimic a slave   needed very careful analysis with a logic analyser (PIC masters are much easier). The adding of addition features is much easier as these can be debugged easily in  MPLAB.
 
The current software just runs around a loop awaiting interrupts and is doing nothing probably 95% of the time. The PIC runs at 2 MIPS and could switch at  1MHz for a single output if doing nothing else. It would be easy to configure the PIC with 5 switches if that would be useful, or 4 switches with an indicator LED.

Sean

[wyleu]

Might relay inputs or opto isolation be useful/sensible? You could quickly run into some interesting issues with CPC and Earthing.

[ericw]

If you want a bus alive detector all you need to do is monitor the bus for the presence of a reset pulse followed by a presence pulse and arrange for it to indicate a failure after a fixed period of time - however remember that when used for data logging the bus is inactive for long periods of time between samples. It would seem to more sensible to do this at the master end where you in control of the sampling times.

In terms of inputs then its no problem to isolate them with relays, optoisolators or neon/ldr's the inputs to the PIC are high impedance Schmidt triggers.
I would have thought that a dual input chip might be useful but for more channels that it would be better to distribute sensors around the bus - if you dynamically change the romid LogTemp will plot two curves (I don't know whether doing this screws up the search algorithm of other software. I found that One Wire Viewer does not like it)

In order to have more than one chip on the network you need to have a unique id's so you can incorporate unused inputs into the rom id to do this.
It then becomes a tradeoff between number of inputs and number of id's, unless you use a bigger PIC.

[wyleu]

It's one of those fault finding things, In the Musical world it's really handy to have a MIDI connector with a LED across the data line for just showing the presence of data. With one-wire you can spend an awful lot of time running back and forward from one end of the cable to the other, checking if it's all still working.
Now obviously once it's all in you tend to forget about it until it ain't working, and then you go throu' exactly the same backwards and forwards chase plus you can't remember what any of it does.
To go into a pump room and see a blink of a light would be reassuring at the very minimum, especially if we ever get into a situation where it moves from simple monitoring to something a bit more critical.
Even if it may seem over involved for a simple switch/sense unit it would establish a base line of functionality above simple sensing and would certainly reassure the casual user.

Obviously I have no way (other than getting my PIC development environment out of the cardboard box it's been in for a while now) of making this happen but I've spent a fair bit of time sitting in attics scratching my head whilst staring at sensors and RJ45 sockets wondering if they're wired properly and wether or not that wire actually goes where the label says. To know that the bus is doing something sensible is a great reassurance.

KISS would seem to be the name of the game here and the hardware will go throu' many iterations as the needs change, if we could lay down some basic functionality at a higher level than is offered at the moment, then this sort of thing could become considerably more ubiquitous.
I'm certain of the importance of it, I'm also reasonably convinced that it is much better to produce our own requirements rather than have them imposed from outside. Idon't doubt Honeywell and Eon have some fairly well developed solutions but I don't think there will be much opportunity for tinkering if it's left to them.

[ericw]

I see your point, at the expense of using a pin I could easily add a LED output that was toggled every time the chip was read/selected.

[StBarnabas]

Hope to test the power meter tomorrow. This will be of more interest to some of you.
Wyleu if you think of a spec for a switch we will try to accommodate  it - 4 channels with a flashing LED. Should all 4 channels be inputs? 

[wyleu]

I'd use 4 inputs if I had them. It would probably cover 80% of usages.

 Dry contacts would probably work, but proper isolation would always be a concern. A related concern would be what sort of box does it all go in?
 The easiest solution I've found is a standard one gang surface mounting box with a double RJ-45 faceplate on it. Doing it that way allows you to just patch cables throu' the device. The led could easily surface mount on the faceplate. Sadly the shatter plastic that these sort of components is a pain in the proverbial but it does work.

[KLD]

Would you then bring the actual sensor (reflective opto thingy for gas meter, etc) out on a short lead? What would be a save method of connecting to,( ie. monitoring) mains voltage devices? Are there optical connectors we could use?

Klaus

[wyleu]

http://www.navitron.org.uk/forum/index.php/topic,6127.75.html had a fair bit of chat about mains sensing.

[ericw]

My feeling is that you should have simple individual sensors, one per input to be sensed, and route the bus around rather than trying to route sensors to a more central point. I do see a dual input to sense say pump on and heat dump could be useful.

Sticking with the original concept of a pseudo DS18B20 to run with standard off the shelf software you have to have a different romid for each input. While its easy enough to dynamically change the romid, it may well spook the search algorithm used in the master software which probably isn't designed to handle it.  More work and testing probably needs to be done to see if its possible to get it working with the common software packages

As you have to have a unique romid to add more than one chip to a network you would need to be able to select more than one id, the only way to do this for the average user is to have jumpers on input pins. So you have a trade off between the number of inputs and the number of chips you want to add. 4 inputs (plus a flashing output) would use up all the 683 pins so you could only use 1 of these chips per network

The peripheral components required are minimal, a connection to the sensor, 1 resistor per input (the internal pull up may be suitable), plus an optional LED and resistor, and some means of connecting it to the 1 wire bus - there is a thread sometime ago discussing this, so it will fit on a small bit of stripboard or simple PCB.

The mechanical arrangement is up to the user, you could for instance put a photosensor on the board and stick the whole lot on the front of the meter or mount the sensor on flying leads.

In terms of mains sensing I use a LDR face to face with a wire ended panel mount neon indicator (you can get IP67 ones) held together with heatshrink as a 'hobby grade' solution. 

[wyleu]

The problem with sensor per input is the connection overhead. If there is any sort of standard connection for all this stuff it's 8p8c ( The wrongly named RJ45) using twisted pair cat 5/6 cable. Now this is quite a bulky connector and you need two per device. If your routing in confined spaces you can almost guarantee that when you want connectors on opposite sides they will be adjacent and when you want them to be adjacent you get them on opposite sides. It can get quite involved and since it's plumbing/electrics you can find yourself removing components like pumps. Now if you have attached wires and sensors then you end up with quite a rats nest around components you are changing. It does get slightly neater if you can take short sense wire/s back to one common point rather than having to arrange 2 connector plastic boxes on pumps or such like.

Realistically I image you don't have any desire to produce CE approved IP rated boxes, this is a hobbyists project ( please correct me if I'm wrong) and as such a certain skill with the soldering iron is assumed, but if a simple box can be assumed ( one gang box and two connector face plate would be my preferred method) then a high level of physical protection can be provided. This is a wet environment after all and althou' it's low voltage it's still full of conductors.


The issue of device ID, as you say, could be resolved with these pins and perhaps a compromise of 2 pins for sense and 2 pins for address, unless some scummy tying of the LED output pin back to an input might provide a third state. ON/OFF/LED connected so you could get three addresses with 3 inputs or 6 addressed with 2 inputs? Please tell me if this is a lunatic suggestion or something viable.

[KLD]

For a two sensor module (say monitoring two pump states): Would it make sense to not report the states of the individual pumps back to the master (this requires two IDs), but instead do the initial logic on the PIC and report 4 signal level (for instance 0 0 reports 0°C, 1 0 reports 10°C, 0 1 looks like 20°C, and 1 1 looks like 30°C). Then you need only one ID, but obviuosly loose flexibility in what the module can do. Although, the principle could be extended to eg. one on-off sensor and one temp sensor, etc. How many bits do we have for the output state?

Klaus

[StBarnabas]

List
Here is a test of the energy meter. Essentially it count up the number of light pulses within a 36 second window and converting them to “pseudo temperatures” at 10 degrees per kW. Eric has written the PIC code. What I have been doing is writing the code for an LED flasher which pulses initially every 3.6s – equivalent to 1kW and then ramps up gradually to 8kW (0.45s duration between pulses) before dropping down to 500W 7.2s pulse duration). And then repeats the cycle. I am using a phototransistor with a 50k approximate resistor in series as the photodetecter, but a PIN diode or LDR should work equally as well. (PIC code for the flasher available just PM me.)

The test speaks for itself. It takes a minute or so to settle on 10 degrees and then ramps up to 80 degrees and then drops to 5 degrees.
A few jumpers might also be useful to increase or decrease the meters sensitivity, alternately it could change range dynamically but there would need to be a way of signalling this.

The main cost here was the photodetector came to nearly £2.00 in total!

Will try to address a number of excellent points made by others if I have a bit more time this evening..