1-Wire Data Logger Ideas
- Thread starter ericvic
- Start date
mustangcoupe
Senior Member
Eric,
What exactly are you thinking of ... when I think of a data logger, I see a device which can run without wires and be plugged in to get the data off..... or are you thinking of taking your existing products and adding memory to it so it can hold alot of data until polled?
What exactly are you thinking of ... when I think of a data logger, I see a device which can run without wires and be plugged in to get the data off..... or are you thinking of taking your existing products and adding memory to it so it can hold alot of data until polled?
I was thinking it would be a controller that would be able to be used in real time and also have an unconnected mode that would be super low power and would collect data locally for some period of time and then the user would be able to retrieve the data.
But what I really want to do is to gather what users would be looking for in a 1-Wire data logger so I can design and build something that has the features people actually want.
Eric
But what I really want to do is to gather what users would be looking for in a 1-Wire data logger so I can design and build something that has the features people actually want.
Eric
Michael McSharry
Active Member
Different people will have different needs. I will describe a few scenarios to give some ideas.
My initial reaction is that a data logger will do much the same thing as a DS1921 where data will be collected based upon some criteria at some interval and triggers/notification can be setup when certain conditions are satisifed. The device will collect time-based samples with the intention that at some future time the data will be uploaded to a master database. In the case of the DS1921 only temperature is collected so the user-parameters are rather limited. For a general purpose data logger there will be many more types of data collected and some of the data types colleced at different rates.
The device is primarily intended for remote applications which means the interface will be IP-based so physical proximity is not a requirement. The unit will need to accept requests that as a minimum download data and clear memory for future recording. My thinking is an FTP type operation to minimize complexity for the logger's processor. It will need to provide a browser-based UI that can be used to characterize the 1-wire devices for which data is being collected and as a portal for maintenance.
A second viewpoint is the data logger that acts as a server. It will collect data into its database, accept queries for data for statistics or charting. Its data will be permanent rather than temporary as in the first concept. It will have a real-time interface from where data can be obtained as it is collected as well as one where historical data is retreived. It is not necessarily remote so interface options could be IP, USB or Firewire. Its UI is richer. In concept it would be similiar to xapmcs1wire/xapmcsDatabase running in a dedicated small form factor micro.
For my remote monitoring and data collection I employ a Temp05 to service the 1-wire bus protocol. The backside of the Temp05 is RS-232 which is connected to a EPS series IP/Serial device and the data is transmitted in real time over the internet to my Home Automation server that has a SQL database where the data is recorded. With this model the remote equipment is very dumb. The EPS is serviced by Telnet. The Temp05 is serviced using simple text commands.
Michael,
Boy I wish I had found some of your posts sooner. I have been pulling my hair out trying to get the Hobby-Boards master hub to work behind the same IP server (an EPS1).
I think I saw a another post from you someplace from a few years ago where you state this is not possible.
The maxim site, data sheets and App notes describe the DS2480 communications, but say nothing about the specific timeouts or other dependencies, aside from the generic mention that it derives its timing from the input (which I guess is what is killing me). I wish I could find this info (inter byte timeouts, reply timeouts, and whatever specific timing sequence/calibration the ds2480 needs).
I had seen some other posts for different serial-to-ip converters that suggest this would work if the timeouts were increased. I have tried this to no avail and tried lots of custom programs to try to find something that worked.
I can't really install a PC where I intended to install the H-B master hub.
Looks like you are successfully using a TEMP0x product. I looked at these initially but I also needed the multichannel hub capability, and the H-B seemed to be the best choice. Maybe I am SOL with the H-B HUB in this application.
Boy I wish I had found some of your posts sooner. I have been pulling my hair out trying to get the Hobby-Boards master hub to work behind the same IP server (an EPS1).
I think I saw a another post from you someplace from a few years ago where you state this is not possible.
The maxim site, data sheets and App notes describe the DS2480 communications, but say nothing about the specific timeouts or other dependencies, aside from the generic mention that it derives its timing from the input (which I guess is what is killing me). I wish I could find this info (inter byte timeouts, reply timeouts, and whatever specific timing sequence/calibration the ds2480 needs).
I had seen some other posts for different serial-to-ip converters that suggest this would work if the timeouts were increased. I have tried this to no avail and tried lots of custom programs to try to find something that worked.
I can't really install a PC where I intended to install the H-B master hub.
Looks like you are successfully using a TEMP0x product. I looked at these initially but I also needed the multichannel hub capability, and the H-B seemed to be the best choice. Maybe I am SOL with the H-B HUB in this application.
Michael McSharry
Active Member
When I first starting using the EPS I discovered that the RS232 voltage levels were in the low to mid 3V range and that caused a problem with some things. I worked with Warren at WGL to get the design of the Rain8 to support the lower voltage levels. I believe the W800 has the same power design as the Rain8, but in my case the voltage was high enough for the EPS. The CM11 and ADI Ocelot had no issues as well as anything else I connected except the DS9097U. I added external power to the DS9097U and it still would not work. When I looked at the timing for the 1-wire protocol I could see that there was no chance that I could sent a pulse out the bus and then be able to respond to the returned waveform when the response had to go through the servers in Hong Kong and who knows where else before it got back to my PC. Even when done locally on the LAN the timing could not be supported with the TCP/IP communications. I never looked into trying to adjust the default timing of the devices and resigned myself that this was the only thing in my HA setup that had to be tied directly to a computer. When working with ascii commands going through the EPS then things are fine, but when trying to push bits it is just beyond the design capabiltiy of TCP/IP.
EDS does provide a HA7Net that will give you remote access to a 1-wire network. If you need multiple branches then you can run multipe HA7Net. You could also teach the HA7Net how to manage a hub, but I suspect that would be a lot of effort. This could become expensive.
If all you are doing is temperature measurements then something like the Quasar 3145 will support 4 home-run channels of a single sensor and it has a RS232 for the EPS.
mustangcoupe
Senior Member
I would say an ethernet connection to access the data with an option to turn a simple web interface on/off. and if you have it in unattended mode, a chart and table in the web interface to see the historical data.
This is the 1-wire data logger that I am currently thinking of getting. http://www.welserver.com/
Hope this helps,
Kenny
Hope this helps,
Kenny
sda
Active Member
This looks like a handy device for some people, but its not for me.
I'm just throwing these comments out because they're somewhat relevant to the datalogger concept.
I scanned the website and the manual, but didn't see this info.
What if there's a bug in the software? Will updates be offered? Is it even field upgradeable?
Some people might like the idea of shipping their data off and have somebody else display it. I don't.
"Note: The WEL does NOT have any historic data storage on-board. So the WEL MUST be able to reach the outside Internet to post it's data to WELServer.com once a minute."
Uh, yeah. You're relying on a whole lot of things (ISPs, routers, fiber trunks, power companies, welserver.com, etc) to work that are way outside of your control.
How robust is the TCP stack? If it sends a packet and misses the ACK(nowledge) is it going to lock up for several minutes and lose data?
It said something about being able to post the data to other websites, even your own.
I gather from reading it uses a form POST, but no details on what its sending.
It doesn't use the HB cat5 cabling system. Should be possible to adapt.
$375 for the basic unit? Seems expensive. Yes it can log several things and handle some devices other than 1-wire. So can a PC with the right hardware and software. Used PC's are cheap. Even new PC's are cheap. Saw an ad from Dell for a Vostro 200 - dual core, 1GB memory, 160GB disk, and a 20" LCD monitor for $399.
Data logger:
The data logger should just collect the data and hold it for client retrieval.
Enough onboard memory to store a days worth of readings.
This would cover most extended client and power outages (if the logger is on a UPS).
Both serial and ethernet interfaces.
Integrated hub.
Real time clock for timestamping the data.
Internal software must be upgradeable.
Onboard web server for configuration and status only.
It shouldn't be doing graphing or anything else because that's best handled elsewhere.
Don't go to a lot of trouble adding friendliness to the data like assigning names to devices.
Just send the device address back and let the client figure it out.
The serial port should implement the same functions (configuration, status, data retrieval) as the web server.
There should be a "low level" protocol to enable a client to talk to the logger via the web server.
The low level stuff is return to the client in plain text instead of HTML.
Some examples:
http://datalogger/status.htm
and the datalogger will display the status in HTML format.
http://datalogger/status.txt
and the datalogger will return the status in simple ASCII format.
http://datalogger/config.txt?delete=(deviceaddress)
and the datalogger will delete the device and return success/fail
http://datalogger/data.txt?device=(deviceaddress)
and the data logger will return data for the specific device.
When retrieving data, the client should be able to tell the logger to send data received
after a specific date time. If the client last retrived data on 7/1/2008 at 5am, then the
client would ask the datalogger for all data after that:
http://datalogger/data.txt?device=(devicea...er=200807010500
Use autodiscovery so if devices are added it'll pick them up without having to configure them.
Maybe once every hour or on demand.
Once a device is discovered, keep reporting it until its manually deleted from the configuration.
This lets the client know there's a problem if there's a malfunctioning device.
Configurable sampling interval and logging interval by device.
Some devices you might want to sample and log every minute or less.
Some devices you might want to sample every minute and log the average every 5 minutes.
If there are devices on the same bus that require output, such as the LCD display, then the bus will need to be shared with another controller (if that's possible) OR pass through commands need to be implemented.
Low cost.
Great idea Eric,
Not sure your logger is software or a hardware device or both?
Since my serial port is being used, a USB device would be great.
All I would like to see is the communication process with each device and exactly what is taking place (in plain english)
I guess I need more info as to exactly what your logger is?
Not sure your logger is software or a hardware device or both?
Since my serial port is being used, a USB device would be great.
All I would like to see is the communication process with each device and exactly what is taking place (in plain english)
I guess I need more info as to exactly what your logger is?
SDA,
Great comments.
EL34,
The logger isn't really anything yet, that is why I am looking for input of what the users would be looking for. But it will be an embedded controller with hardware and software and it will most likely communicate with a PC through Ethernet.
Eric
Great comments.
EL34,
The logger isn't really anything yet, that is why I am looking for input of what the users would be looking for. But it will be an embedded controller with hardware and software and it will most likely communicate with a PC through Ethernet.
Eric
politics123
Active Member
My wish list:
Should have error correction for readings (eg: statistical correction of outlier figures)
Serial interface (aka: ELK!!!) would be a real nice touch. Specifically, I'd like to view temperatures on the keypad or write an automation rule based on a temperature or counter
It should support FTP uploads (welserver is a great example of what I want to have, at a lower price-point)
It should support a variety of sensors
It should support counters rolling over 65k
Ideally, it would allow us to "zero" a counter hourly, daily, weekly, monthly, etc (eg: weekly rainfall)
One of the software tools allows a "virtual" sensor, which is a mathematical operation on one or more real sensors (eg: my solar HW setup, I have a virtual sensor called "temperature gain" which is the difference in the water going to the roof and the water coming back from the roof)
Perhaps some sort of "alarm" that we can use? (eg: if temperature ABC is < 32 degrees F, send string to serial port. I could then use this to drive an ELK rule)
I do my data logging in software and use SNMP to access the sensor data, so for me an ethernet connection with an IP address that can be polled for SNMP is a requirement.
I currently use one of these:
http://www.hw-group.com/products/poseidon/...on_1250_en.html
I currently use one of these:
http://www.hw-group.com/products/poseidon/...on_1250_en.html
skyewright
Member
Perhaps a bit late to comment on this, but...
If you are interested in an already in use logging protocol, you might like to take a look at:
http://www.meteohub.de/joomla/index.php?op...9&Itemid=29
I currently log weather data from OS sensors using Meteohub running on an NSLU2. I analyse and publish the data using WeatherDisplay. That protocol is what WD uses to pull the data from Meteohub - both for 'live data' and for catchup when WD is restarted after a break.
For various reasons I'm starting to see the appeal of the 1-wire system over something pre-packaged like OS. It would be a very interesting develoment indeed if there were a 1-wire data logger.
Where do you see your data logger fitting into the system?
Part of the 1-wire network?
On the computer side of the 1-wire-to-serial/hub/master interface?
As a sort of super hub/master module?
Regards, David
Pretty much all that sda said goes for me too.
If you are interested in an already in use logging protocol, you might like to take a look at:
http://www.meteohub.de/joomla/index.php?op...9&Itemid=29
I currently log weather data from OS sensors using Meteohub running on an NSLU2. I analyse and publish the data using WeatherDisplay. That protocol is what WD uses to pull the data from Meteohub - both for 'live data' and for catchup when WD is restarted after a break.
For various reasons I'm starting to see the appeal of the 1-wire system over something pre-packaged like OS. It would be a very interesting develoment indeed if there were a 1-wire data logger.
Where do you see your data logger fitting into the system?
Part of the 1-wire network?
On the computer side of the 1-wire-to-serial/hub/master interface?
As a sort of super hub/master module?
Regards, David
