Reading tempemperature over ethernet

[Michał Ćmiel]

Hi,

I'm trying accessing a serial device as if it were physically connected to my PCs' COM port

To achieve this I'm using MikroTik board to convert signal from one wire bus to ethernet. Connection between PC and MikroTik is working fine. On my PC I'm using socat to create tunnel:

[root@localhost ~]# socat PTY,link=/dev/ttyS01 TCP:192.168.15.254:4321

But digitemp won't work:

[root@localhost ~]# digitemp_DS9097 -i -s /dev/ttyS01 -a
DigiTemp v3.5.0 Copyright 1996-2007 by Brian C. Lane
GNU Public License v2.0 - http://www.digitemp.com
owAcquire: failed to set attributes: Invalid argument
Error 24: Failed to initialize system resource

Permissions has been corrected and looks same as in physical rs232

[root@localhost ~]# ls -la /dev/ttyS01
lrwxrwxrwx. 1 root root 10 11-22 14:57 /dev/ttyS01 -> /dev/pts/2
[root@localhost ~]# ls -la /dev/pts/2; ls -la /dev/ttyS1
crw-rw----. 1 root dialout 136, 2 11-22 14:57 /dev/pts/2
crw-rw----. 1 root dialout 4, 65 11-22 13:45 /dev/ttyS1

PC<--------->MikroTik<>RS232<---------------->sensor DS1820

         lan                                   one wire

Have someone tried this configuration ?

[Brian C. Lane]

On Sun, Nov 22, 2015 at 06:12:15AM -0800, Michał Ćmiel wrote:
> Hi,
>
> I'm trying accessing a serial device as if it were physically connected to
> my PCs' COM port
>
> To achieve this I'm using MikroTik board to convert signal from one wire
> bus to ethernet. Connection between PC and MikroTik is working fine. On my
> PC I'm using socat to create tunnel:
>
> [root@localhost ~]# socat PTY,link=/dev/ttyS01 TCP:192.168.15.254:4321
>
> But digitemp won't work:
>
> [root@localhost ~]# digitemp_DS9097 -i -s /dev/ttyS01 -a

9097 is a pretty basic adapter, it uses timing of the bits to simulate
the 1-wire timing. I'm pretty sure even if you could get digitemp to
talk to it that it wouldn't work.

You might be able to get a DS9097U to work, or an iButtonLink.

The 1-wire library expects the serial port to have all of the normal
control lines available, eg. DTR, and that may be why it is totally
failing.

--
http://www.brianlane.com

[Dale Reagan]

Hmm, not sure I follow (and I'm not familiar with the Mikrotik device), but it sounds like:

- you have remote Linux system with TTY (guessing USB device) working with Digitemp

- you are using a Windows PC locally?

- you want to remotely connect to the same device (run Digitemp on your PC) OR

- you want to remotely control/run Digitemp from your PC?

--- generally speaking the 'host OS' is going to limit/lock access to one process for a given device - unless it is possible to configure the device for 'sharing' in some manner; the error shown above suggests (to me) that you cannot share access to the device - Digitemp probably wants 'exclusive' access; this is separate from the idea that the Digitemp program will 'share access' - also probably not likely

--- if you really want to remotely *control/run Digitemp* then you could certainly 'script' or command line sequence (ssh to remote server, call Digitemp, save/capture data, etc.)

--- if you really want to remotely *control the hardware*, and use it as a 'local device' (again, guessing USB), you might consider searching for some of the 'USB over TCP' solutions - the perhaps you could run Digitemp on your PC and 'attach' to the remote device

--- of course, another approach would be to write your own 1-wire w/TCP solution... :)   I.e. create a 1-wire daemon that is network accessible

Not sure if this is helpful, but perhaps a different approach may get you to a good end point...

:)

Dale

--
You received this message because you are subscribed to the Google Groups "DigiTemp" group.
To unsubscribe from this group and stop receiving emails from it, send an email to digitemp+u...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--

= = = = = = = = = = = = = = = = = = = =
Dale E. Reagan       | (912) 920-9299
Photographer / Consultant    | Da...@DaleReagan.Com
http://www.dalereagan.com/
PO Box 15336, Savannah, Ga 31416  USA

[etd...@yahoo.com]

I use an HA7Net 1-wire busmaster to read 1-wire sensors at a remote location.  The HA7Net has 3 jacks for 1-wire busses and works quite well.  Mine is reading 3 temperature sensors and 1 humidity sensor.  Th only problem with it is that it is not compatible with digitemp software.  You get your readings by sending an html string to the HA7Net with the sensor serial number.  I use wget to retrieve the html code and then parse the mess to get the reading I am after.  This is just a suggestion. 

[keypunch]

Hello,

I cannot speak for those that have made modifications to the DigiTemp source code nor the author of the original code.  I can only speak from the perspective of one that has done some extensive of modifications to the DigiTemp code for my own specific personal needs and alot more modifications yet to still do.  This means I have some understanding of the DigiTemp code.

Digitemp is design is to communicate with a 1-Wire Bus Master.  The 1-Wire Bus MAter then communicates wo the 1-Wire Lan sensors and/or 1-wire switches that are connected to the 1-Wire Lan.  This is the design of DigiTemp and for that matter code designed to communicate with a 1-Wire Bus Master to the 1-Wire Lan.

The HA7Net is in essence a device that has a 1-Wire Bus Master in it.  I do not know if the 1-Wire Bus Master is a Dallas/Maxim chip, a custom design chip, and/or custom firmware at a lower level than the higher level custom HTTP based interface and command set the HA7Net has.  I did some searching before this reply to see if I could find out if the HA7Net happens to use a Dallas/Maxim 1-Wire Bus Master chip.  I was not able to find out nor find anthing to enable me to deduce.  The HA7Net replaces what programs similar to DigiTemp that communicate to the 1-Wire Lan and sensors using a the 1-wire Bus Master using the software of the Ha7Net, the Ha7Net (web oriented) interface and commands to talk to the software of the HA7Net.

For DigiTemp to talk to the HA7Net any code required to do so woudl be all new code and not use any, or next to none, of the existing DigiTemp code.  This is because the HA7Net has a completely difference "conversation" than DigiTemp (or similar programs to DigiTemp).  This would therefore mean that it would be more appropriate to create a program/scripts to automate and simplify the commands (HTTP, wget, et al) commands as that is in essence what would need to be added to DigiTemp if it were to be added.  I would be of the opinion that such code would not be added to DigiTemp.

If someone was to suggest Serial Over IP as a solution without getting into the implications from a hardware and software perspective to support Serial Over IP to in therory using DigiTemp or similar software to access the remote sensors I would suggest the theory is just theory.  There are various timing matters that need to be followed for the 1-Wire Lan and Bus Master.  The lack of control over IP packets timing would more than upset this timing requirement.

Are there other possible solutions including ones that would allow the use of DigiTemp for your remote sensor needs?  I would suggest the answer is likely.  Woudl they include still using the HA7Net?  I would suggest not likely.

I am not the expert in this matter or DigiTemp.  That means I could be wrong about what I have stated.  If I am I am more than happy to be corrected or enlightened.  I am simply stating the best that I know.  This is about ideas, thoughts and learning.  My comments are made in that context and approach.  Hopefully I have not made too many typo errors.  IF I happened to of and it is is not possible to deduce my typo error or seems oppsite to waht I likley meant please do feel free to ask for me to clarify/correct.


John L. Males
Toronto, Ontario
Canada
27 November 2015 02:18

[etd...@yahoo.com]

I use an HA7Net to read temperatures and humidity from Hobby-Boards sensors placed in a shed of mine.  Getting the readings from the HA7Net was not an easy proposition.  I created 2 shell scripts: one for temperature and one for humidity and they were not easy to write.  I am also using digitemp software in shell scripts to read temperatures from sensors placed around the house.  The combination of the digitemp and the HA7Net is working well for me.

For what is worth, I have made a prototype PCI board that I have inserted in a PCI slot inside my server.  Two cat5 cables come out of the back of server which are daisy chained into the 1-wire dongle.  The PCI board has 3 temperature sensors attached.  One is for the internal temperature of the server.  The other 2 are for taking the temperature of the air leaving the CPU heatsinks.  In this way, the server can monitor its own internal temperatures and warn me if any one of the 3 gets too high.

I am just saying that if there is not a means of doing serial over ethernet then the HA7Net is a viable alternative.  Unfortunately, digitemp cannot obtain readings from the HA7Net directly.

On Sunday, November 22, 2015 at 11:31:28 AM UTC-5, Michał Ćmiel wrote:

[keypunch]

Hello,

Sorry I have had a number of very unexpected matters that have caused a delay in my reply.

I understand the challenges of scipting.  Often what seems a simple requirement has a number of finer and tedious elements that need to be worked out.

You have spent time and thought in the solution you currently have.  It would appear you need the Digitemp for local and the HA7Net for a distance.  I suspect the serial to ethernet configration you tried either has a subtle issue or there are timing issues important to the One Wire Protocol that are skewed due to the Serial/Ethernet conversion.  I am not sure at all, just a possible thought.

I would offer the following thoughts that you can try or may spawn other ideas by you or others.

Have you considered that given you have ethernet running to the HA7Net to use CAT5 to the location via One Wire Master like the the DS9097U, DS9490R or some other great One Wire Bus Masters that are available?  Then the entire sensor network can be one solution, Digiitemp, which appears to be your preference.

I do not know how long the Ethernet CAT5 running to where the HA7Net device is.  It seems like a possibility assuming the distance factor is all via ethernet cable already.  I would think using CAT5e cable would be even more capable of handling longer distances than the RJ11 network I have used for years that seems to defy the information available about RJ11 cabling for One Wire Networks.  Perhaps a test of one sensor on the far end of the CAT5e cable you run to the HA7Net would be an easy first test to see if the cable length via a One Wire Bus Master would work for your situation.

As an FYI I still am not quite there for a Cat5e One Wire Network.  I am much closer in the last few months, but still some physical design considerations I need to work out.  I have been using basic RJ11 cables from the Dollar Stores and only via Parasite Power.  I have an error on the One Wire Bus once every few days or several days between despite flat RJ11 wire on top of only Parasite power for the devices.  I have used 20 sensors on this same One Wire Network at same time for several days and for years at least 12 devices.  This with cable lenghts for the One Wire Network in the 50m+ range and at times I have had to use 85+mm of RJ11 wire with these Parasite powered sensors. I am unable to avoid in multiple areas to keep the RJ11 wire away from AC cords (often alot of them) and strong fields of Air Conditioner AC motors.  Still amazing considering what seems to be infomration to the contrary a RJ11 based One Wire Network would be so stable and for as many and long distances for RJ11 cable and in area of AC cables.  Not even intense thunderstorms seem to cause the RJ11 One Wire Network I have used for years.  The point being using CAT5 as the One Wire network should be able to acheive longer distances.  I have read of very long distances acheived.

Just some thought to consider and if any are helpful or lead to other ideas that is great.

John L. Males
Toronto, Ontario
Canada

06 Devember 2015 23:02

[etd...@yahoo.com]

Originally, the HA7Net was bought to be installed in my greenhouse.  Communication with it was achieved using a wireless access point and a wireless router.  This worked for a while (7 years); but, was not reliable.  Occasionally, the two D-link transceivers would lose touch (the greenhouse is about 60 feet from the house)..  Normally, this would not be a problem except that reading the temperature in the greenhouse was critical.  In the summer, the greenhouse could overheat and in the winter, the heater could malfunction.  In the summer, an X10 module controlling a window fan was turned on or off by my server depending on the temperature.  In the winter, I have a gas heater that works well except its pilot light could go out leaving the greenhouse in a desperate situation.  To prevent freezing, I have an X10 module controlling an electric heater depending on the temperature.  The software for the X10 modules is Heyu which is open source and works excellently.

Anyway, 2 years ago I installed 2 outdoor Cat5 cables to the greenhouse and took the wireless transceivers out of service.  Now, the communication between my server and the HA7Net has an RTA of 1.36 ms.  I never tried a serial/ethernet adapter as I already had the HA7Net before I installed the Cat 5.  

The HA7Net is very stable and has not given me any trouble in the 9 years I have had it.  It has a web interface that allows you to get temperature readings from all or only 1 sensor.  I say temperature as it cannot get readings from non-temperature sensors through its web interface.  I had to jump through so many hoops to get a humidity reading that it was unbelievable.

Here is some of the shell script for humidity that I wrote:

 #     Static string definition section

#

addr="D8000000A8B91526"

ipaddress="192.168.254.5"

addressdevice="http://$ipaddress/1Wire/AddressDevice.html"

AWKCMD="/bin/awk -f"

AWKROUNDER="/usr/share/awk/round.awk"

cutcmd="/bin/cut"

folder="/home/temperatures"

#folder="/var/log/heyu"

getlock="http://$ipaddress/1Wire/GetLock.html"

low_rh_file="$folder/greenhouserhmin.txt"

high_rh_file="$folder/greenhouserhmax.txt"

outfile="$folder/greenhouserh.txt"

readpages="http://$ipaddress/1Wire/ReadPages.html"

releaselock="http://$ipaddress/1Wire/ReleaseLock.html"

rmcmd="/bin/rm -f"

tmpfile="/tmp/tmp.txt"

wgetcmd="/usr/bin/wget -r --tries=10 -q -O $tmpfile"

writeblock="http://$ipaddress/1Wire/WriteBlock.html"

#

#================================================

#     Integer definition section

#

lockid=1

#

#    Function to grep tmpfile for Resultdata

#

greptmpfile ()

{

tempstring=$( cat $tmpfile | grep ResultData_0 )

case $1 in

1)

# echo "$tempstring"

;;

esac

return

}

#================================================

#    And, away we go!!!!

#

tmpstring=$( $wgetcmd $getlock )

lockstring=$( cat $tmpfile | grep LockID_0 )

lockstring=$( echo $lockstring | awk 'BEGIN{ FS="VALUE=" } { print $2 }' )

lockstring=$( echo $lockstring | sed '/</s///g' )

lockstring=$( echo $lockstring | sed '/>/s///g' )

lockstring=$( echo $lockstring | awk 'BEGIN{ FS="/" } { print $1 }' )

lockid=$( echo $lockstring | sed '/"/s///g' )

#

endstring="&Address=$addr&LockID=$lockid"

url="$wgetcmd $writeblock"

#

tempstring=$( $url?Data=4E0008$endstring )

greptmpfile $debugflag

tempstring=$( $url?Data=4800$endstring )

greptmpfile $debugflag

tempstring=$( $url?Data=44$endstring )

greptmpfile $debugflag

tempstring=$( $url?Data=B4$endstring )

greptmpfile $debugflag

tempstring=$( $url?Data=B800$endstring )

greptmpfile $debugflag

tempstring=$( $url?Data=BE00FFFFFFFFFFFFFFFFFF$endstring )

greptmpfile $debugflag

#

b=$( echo $tempstring | awk 'BEGIN{ FS="><" } { print $1 $2 $3 }' )

c=($b)

#

tempstring=$( echo ${c[5]} | sed '/=/s///g' )

tempstring=$( echo $tempstring | sed '/VALUE/s///g' )

tempstring=$( echo $tempstring | sed '/"/s///g' )

#

echo $tempstring > $tmpfile

The above is only part of the code.  I had to get the spec sheet for the humidity sensor in order to know which registers I needed to access for voltages, etc.  Still, I am not certain if the script is reading the correct humidity or not.  There are not too many standard kits for humidity that I know of.

This is just my 2 cents worth.

On Sunday, November 22, 2015 at 11:31:28 AM UTC-5, Michał Ćmiel wrote:

[keypunch]

I had a hunch that you had wireless before the ethernet cable and you changed for the reasons you noted.  You confirmed that hunch I had.

I am amazed the HA7Net has lasted as long as has simply due to what I assume is higher then average level of humidity in the greenhouse compared to a office/home environment. 

Did you ever consider using a wet bulb thermometer instead of using a digital humidity sensor?  I ask for two reasons.  First are you aware the humidity sensor itself is light sensitive which I am l;ead to believe can lead to sensor aging.  Again that seems to suggest the sensor will no longer work.  I am not certain of this, but seems the light sensitive aspect is not as well known as perhaps should be.  The second reason is given the HA7Net is geared to temperature sensors for its web interface a wet bulb temperature sensor is just another temperature sensor.  The math to calculate humidity would be straight forward. I assume not all the hoops and scripting you had to do to obtain a humidity reading from the HA7Net to do so would be needed for a wet bulb temperature sensor.

I have been running a wet bulb for humidity and comparing it to the digital readings of simple tabletop devices that read temperature, humidity, barometric pressure, date/time, et al.  So far there seems to be about a 15% difference where the wet/dry bulb is the higher all the time.  I have checked the tables of the wet/dry bulb sensors and thay are basically the same values as the math for the sling version of wet/dry bulb and I have tried fanning the wet/dry bulb I have and seems to not narror the 15% difference to the digital sensors (I have a few and all are reading about the same RH% so not a tolerance issue of sensors inside these).  I still have not figured out the reason for the 15% diference of wet/dry bulb vs the digital sensor versions (none are one wire devices).  Still I have a preference for wet/dry bulb myself.  Just a thought for you to consider.  I did alot of research and seems doing wet/dry bulb humidiy with no fan or such is for all intents the same as with a fan or compared to the sling type manner to take a humidity reading.

Beyond the humidity is there any other non-temperature sensor you wish to have in the greenhouse that might pose more scripting challenges with the HA7Net?  Maybe if so thinking of a SBC like a RPi or the many other similar types of devices would make sense.  Lower poser use, less moving parts, you could customize to your hearts content, add a display to see the readings and maybe not need to run a server for the temperature control and logging.  Another posibility is a Thin Client retasked from Windoes to Linux.  I use the latter especially with all the USB ports, having a RTC that many SBCs seem to lack, uses little power, no moving parts (did I say that already!).  A SBC like a RPi woild be able to control the fan and heaters in the greenhouse directly without the server having to do so I am hoping, perhaps via many of the fine realy devices for one wire still available or even via a USB version if need be.  Maybe not at the immediate moment, but as a backup plan in case the current system has problems, if it ever does (seems to be stable in terms of the greenhouse environment).  One reason for suggesting is it sounds like the server is doing part of the control for the green house fan and heater that could all be done at the greenhouse and not need a server to do so.  Perhaps I am making some assumptions in the configuration you have so well thought out and carefully ensured works well.  Just some thoughts in case you have not considered, but you do think things through well.

One very important comment about the bit of code you posted about how you accomplish the challenges to secure a humidity reading from the HA7Net.  Exeptional way you approach how you code.  I do not see this as often in coding practice of most source code of any language.  A coding practice approach that should be used all the time in my opinion.  So wonderful to see someone else code in such a manner.

As always I hope my comments are helpful or may sprout (pun intended) other ideas.


Regards,

John L. Males
Toronto, Ontario
Canada

12 December 2015 13:09

[etd...@yahoo.com]

I have not been keeping tracks on the greenhouse humidity until lately.  There is a dial gauge that is part of a thermometer in the greenhouse; but, it is not that accurate as it is a cheap unit. The humidity sensor is in a hobby boards plastic case so it is protected to some degree from direct light.  

I have used a sling psychrometer in the past as part of my job. (I am a retired pharmaceutical chemist and have had to calibrate instruments used in chambers testing sample stability at various temperatures and 90% humidity).  The wet/dry bulb thermometers are the most accurate as I have used them as references.  I have used a humidity calibration kit that consisted of 3 jars with various reagents in them.  One jar had a layer of water on the bottom for 100% humidity.  Another jar had a desiccant in it for 0% humidity and another jar had a chemical (i don't remember what) that gave a humidity of maybe 50%.  I inserted my electrical probe into each jar and calibrated the instrument to match what the jar's humidity was.  Humidity is not an easy thing to calibrate fpr.  

I cannot think of another temperature sensor for the greenhouse outside of the 1-wire one.  There is a sensor that I remember from my past that could be connected to an ethernet LAN and had sensors; but, I cannot remember its name now.  I was interested in it as Nagios (www.nagios.org) is running on my server and it could poll the sensor and post the readings on the Nagios web page.  

My current server has been running almost non-stop for 4 years and has not had a hardware failure yet.  I have 2-500Gb HDD's running in Raid 1 so I have some redundancy.  I plan on adding a third drive to act as a hot spare.  Besides Nagios, the server is running Festival for voice announcements of important events and heyu for controlling X10 modules, wall switches and window/door sensors.  In the future, I plan on implementing round robin databases to keep a history of temperatures readings.  The round robin software can create a bar graph of readings over a time span.  The bar graphs could be displayed on a web site if I wanted to learn HTML (lol).

Thank you for approving of my coding.  I have coded in Fortran 4X, Basic-plus-2 and DOS batch files so writing shell scripts is not that big a leap for me. (It also helps to have a Linux programming reference to refer to).  I try to code in a structured way as it is the preferred manner in the industry.  I have never had a college course in programming so what I have learned is what I have picked up.  

I have about 10 years of IT support experience under my belt.  I have worked with Netware 4, 5.1 and 6, Windows servers and Linux.  I hold A+, Network+, Server+ and Linux+ certifications.

On Sunday, November 22, 2015 at 11:31:28 AM UTC-5, Michał Ćmiel wrote:

[keypunch]

Great you have the Hobby Boards humidity sensor in a Hobby Boards case.

Clearly you know about humidity as a result of your job you are now retired from.

My suggestion of wet/dry bulb for humidity was in the scope of one wire.  I was not implying outside the scope of one wire knowing the challenges you have with non-temperature sensors with the HA7Net.  My suggestion was implying the use a another temperature sensor that would have a wick about the temperature sensor that would have part of the wick in a well of (distilled) water and thereby give the evaporation temperature via the one wire temperature sensor.  The dry bulb temperature I am assuming you already have and have for some years in the greenhouse that then the humidity could be calculated using the formulas for doing so.  This is how I know the wet/dry bulb humidity seems to run about 15% above the three standalone digital tabletop devices I have.  I am not sure if it is due to the fabric I am using for a wick.  I have tried different types of fabric and they all give the same wet bulb temperature.  This suggests to me the 15% difference is not likely due to the fabric I use for the wet bulb wick to the one wire temperature sensor serving as the wet bulb temperature.

Your server is well thought out.  I would agree that adding a third Raid 0 drive is helpful.  My suggestion of a Thin Client type of device as the server was in part for reduced power demand that translates to longer run time on a UPS that I assume you may have or considering.  A NAS would then be possibility the next largest power use from the UPS.  Some NAS units have as low as 15-19W use when in full power mode.  My Thin Clinet device retasked to Linux draws only 15W with 5 USB devices, KVM, keyboard, mouse and monitor.  The monitor is not on the UPS.  I am almost complete a 2 month project to build a custom Linux that is Flash and SSD friendly.  That means no OS related wear at all to the Flash or SSD device and extremely low wear (near zero, ie. linear) to the Flash/SSD device for the output that gives near design lifespan of the Flash/SSD device.  All the data (over 110,000/per day) is logged and kept.  The raw data is imported into a SQL database I have designed where I can run a number of standard as well as ad hoc queries from.  It also allows me to export custom data when there is a need of.  The SQL data holds other information about the one wire network, sensor data, et al.

Self taught and no courses or university/college degree is needed to know how to code well and write good code in my opinion.  In some cases I think "education" in such areas is such that the code written can be much worse as attempts are made to write in some very fancy manner to take advantage of some unique language or or otherwise such that what is being done is near impossible to figure out later.  There is not much point writing code the author or anyone else cannot figure out or are prone to making major errors in coding to fix or enhance a piece of code.

My backgound started with assembler taking compilers (Fortran especially) and the OS apart at the binary level and making major changes to the OS (what is now called the kernel), all of the system utilities and my first assembler program was to replace the IBM way of a Sysgen (load and configure the OS, compilers, system, et al from scratch) with new binary format and all the functionality of the IBM way in 30 minutes and not nearly 4 hours the IBM way. This while in high school.  We had a real IBM computer with false floor, air conditioned room and alarm system to the actual computer room.   I still use Fortran to this day as many key programs I will write are faster and take less time to code in Fortran than C.  Of course nothing is as fast as writing in assembler.  Assembler is only for special types of programming requirements.  My first Fortran program was with Fortran 66 that printed a bridge truss design and all of the load factors on each beam of the bridge truss, shear/compression factors and selected the material requirements for and the bolting/welding requirements.  That was when I was in high school.  I also wrote hardware diagnostics programs for Defense Canada while I was in high school in assember for a non-IBM machine that had a completely different assembler I needed to learn with the hardware design and internal machine design than the IBM machine in high school.  In a week from knowing nothing about this Defense Canada machine I had written 3 hardware diagnostic programs in the assembler of that machine.  Only two of these machines existed in the world.  The other one was at Harvard.  One of the roles I had was with a company Novel lowned.  Ray Norda visisted us and was very impressed with what we do and the product we maintained.  While at the company Novell actually called us to have us find a serious Novell Netware bug that so far only occurred with a VP Netware system rather than have the Netware engineers look into the problem.  I was one of the team of three assigned to look into the problem.  My role was to design test cases to manifest the problem. This means I know a little bit about coding and coding practices.  I am bot bragging.   Clearly you have done very well in not only learning on your own, but in your manner of how to abstract code that is easy to maintain by design.  The latter requires a different level of abstraction and willingness to take time and effort up front to save the time and effort down the road in fixes and changes one makes to code.  This knowing the success level of doing so will be higher with a lower possibility of related bugs from the code changes.  Structured coding my be an industry preference, but I can assue you there are many "definitions" of structured coding and oftentimes some of the basics are often not followed in the name of time pressures due to various factors.  There are other factors involved that affect the coding style I will not get into.  So again it is so refreshing to see coding as you have at the level and approach you have.  Not as common as I would like to see I can assue you.

I have no certifications.  I may be "certifiable"!  The latter is a given for me!

Just to recap the wet/dry bulb humidity suggestion I was making for you to consider if it may be ease the challenges with the HA7Net only designed for temperature sensors.  The suggestion was made in context of using a digital temperature sensor that can be used with the HA7Net with greater ease as  a wet bulb temperature sensor.


Regards,

John L. Males
12 December 2015 23:54
Toronto, Ontario
Canada

[etd...@yahoo.com]

The best material for a wick for the wet bulb thermometer would be cotton.  Also, I would use distilled water to wet it.  Normal tap water contains too many minerals which over time will diminish the water absorbancy of the cotton.  

I have the temperature and humidity sensors in the greenhouse so that I can monitor both sensors from my PC in the house.  Also, my server can run shell scripts to control fans and heaters.  

I run a terminal window on my desktop and telnet into my server.  At the telnet window, I run "heyu monitor" which shows all the X10 traffic that is posted by the heyu task as it receives it on the X10 network.  The network in this case is the 110 volt powerline.  My shell script for temperature in the greenhouse posts its results into the heyu log which is then displayed by the "heyu monitor".  In this way, I can see what the environment is like "out there".  FYI: I raise orchids as a hobby.

My server is one that I built to my specs.  The chassis has lockable wheels on it making it easy to move about.  There are total of 10-5.5" bays in the front giving plenty of expansion room should I need it. The MB is an Intel SE7501BR2 with dual 2.4 GHtz. Xeon processors (I know it is old.).  Each CPU is dual core.  The Linux that is running on it thinks that there are 4 CPU's and balances tasks between them.  When I first started up the server, I knew right away that I would need to replace the fans.  There are 2 fans in the back of the chassis and 2 fans on the MB's CPU's for cooling.  All 4 fans were noisy and had sleeve bearings.  I replaced the 2 CPU fans with Stealth fans made by Vantec.  I replaced the 2 chassis fans with fans made by Noctua.  The server is now whisper quiet and the 4 fans have ball bearings which should give a long life.  I saved the original fans "just in case".  The 2-500 GB HDD's are run off a Sata II controller.  Unfortunately, the controller can only do Raid 1.  I do not have a UPS yet.  

My server is running Samba.   This allows my old Win98 PC to login and have a mapped drive letter to a shared folder.  My Linux desktop logs into the server by samba and has a shared folder that is the same as the Won98 PC has.  In this way, I can transfer files between the 2 PC's using the server as an intermediary.  

I admire that you can code in assembly.  The only thing that I can think of that would be harder is machine language which is really getting down to "brass tacks" IYKWIM.  I started to build my own PC until the IBM PC's came out when I dropped the idea.

My first experience with PC's were the IBM XT's and AT's that I was asked to support when I worked at Cornell.  I had 0 knowledge and had to climb the "learning curve" in a hurry.  From there, I was asked to install a Netware 286 server for the department.  Netware 286 had to be compiled to create an executable that could then be installed into the server PC.  Memory for it was limited to what the 80286 processor could address.  Needles to say, 286 worked quite well and was fast.  But then again, I was dealing with XT and AT PC's which were not blistering fast back then.

On Sunday, November 22, 2015 at 11:31:28 AM UTC-5, Michał Ćmiel wrote:

[keypunch]

I am using distilled water and a cotton wick for my wet bulb DS18B20 sensor.  I tried what is about the 5th different type of wick fabric last night.  The well for the distilled water of the wet bulb is 6 inches long and 1 inch ID.  The hole is such that very little dust or other matter can drift into the water well.

I used a spare DS18B20 sensor last night in what has been many attempts and tests with different types of wick fabrics.  The two wet bulb DS18B20 sensors were side by side to compare their wet bulb temperatures.  Still the same 3.9C difference to the dry bulb.  The 3.9C difference based on dry bulb temperature means a RH of 67% using chart and by the math.  I played with the barometric presser value in the math, but it did not make that much difference to even offset the 17% difference or so to the three standalone desk type devices that display RH and temperature agmonst other things.  The wet bulb temperatures need to be at a difference of 7-8C to match the RH of the three digital desktop standalone units.  Fanning the wet/dry DS18B20 sensors made little difference to the difference in their temperatures and for that matter little difference in their absolute temperature compared to almost still standing air.  The three standalone desk top units are all within 5% of each other at about 47% being the mean value of the three.  Can all three digital RH sensors be off about 17%?  Frankly I really cannot see a RH of 67% for this time of year here.  Granted it is still more than mild for "winter" still, but I really cannot see nor feel the RH is 67%.  That said you and many others do say wet/dry bulb RH is more acccurate.  If so I find it odd three electronic RH of very different companies and designs (likely same electronic RH sensor inside all) all so close to each in reading to be so much different than the wet/dry bulb result.

I favour small and low power devices for the Linux monitoring and control.  It makes it so much easier to sustain longer up times with a UPS and many more choices in what approach one uses for UPS, i.e. solar and battery.  It also takes up less space and with no moving parts tends to be very robost as well as a very small footprint.  Again a personal choice I have in such matters.  NAS and file systems/servers for other purposes have their place as well for sure.  I could attach a NAS for the  embedded device, but I do not think it makes sense for me at least and what I am able to accomplish with the custom OS/distribution and alot of other unique custom design elements I have designed/coded.  My suggestion for a small footprint like SBC in the greenhouse was so all the greenhouse control is in the greenhouse.  Being able to telnet to it and see, manually override, et al would still all be available and assumed to be possible from the house location that makes perfect sense.  That way a similar SBC could run in the house for the house related sensors and control and possibility enable less of a need for a server in 24/7/365 operation and more when there is a need.  The SBC systems could easily have web based elements to be able to view the status of the sensors via any computer of smart phone.  Again these are just ideas and thoughts from someone that tends to use smaller for as much as I can as it is likely I have been this way all my life in such approaches.

As a technical note if you are doing Raid 1 via a controller card in the computer and not via Linux software Raid I would suggest you consider via Linux software Raid.  There is better interchangeability and recovery of data using software based Raid than hardware based Raid.  It is better to disable the hardware Raid of a card and use software Raid, at least where Linux and BSDs are concerned.

I was very versed with machine language as well.  Coding in assember makes much more sense for programs.  Machine language was for all the times, of many, I needed to access the system console in single step or single instruction and modify registers, memory and/or write machine code on the fly for a variery of reasons.  The machine where I started this all on for the first 7 years had bit switches for each area of input or inquiry one made to the machine.  Not hex switches like later machines had.  Frankly it was easier to use bit switches as machine op codes, modifiers and such did not always not often fall on a hex/4bit boundary.  So it was easier in fact to write machine code on fly using bit and not hex based switches.  For the time I was in IBM mainframes I often would write on the fly custom machine code in the scratch memory area of controllers or the devices to test that a repair was done correctly or to ensure the devices and CPU were functioning correctly.  I often did this once a week as preventive and as often as needed when hardware.  None of the System Engineers knew how to do this much to my surprise, not had a clue what I was doing.  They all trusted me as I had proved myself in many aspects of hardware as well as software despite having no education of any sort then or to date.  My goal was to ensure systems would run smoothly and with the least failures unexpected.  This applied to my software interests as well.  Basically if something was not working correctly or I felt it could be done better I learn what I needed on my own to figure it out and acheive it.  That is how I started in high school and why I leanred assember as that was what was needed to fix and improve the system software, OS, Kernel and compilers.  That has been the core of my IT perspective for my entire time I worked in IT.  I had a uncanny ability to being able to find bugs that were not known or reported without anyone knowing how to duplicate/isolate the issue so the engineers could fix a problem.  If an engineer cannot see the problem it is very difficult for them to find the fix for it.  That is how I get started in IT and have been to date.  Ditto when a unique hydraulic platform was under frequent repair many times a year  I figured out the issue and solution that the company had not been able to for years.

Again I am not bragging, just a sense of what I am about.  My sense as well my sugestions and thoughts presented for you in kind.  I believe though the specifics are different you are similar in your approach, thinking and what you have done on the job as well as in other areas of hobby or interests and those you help.  All great qualities for sure.

And yes I more than recall the days long before the IBM PC and the micro boards that were available to build machines.  The Sinclair Z80 many hobbists liked to use, et al.  I also recall the days of building flip flop adders and subtractorsfrom descrete electronic parts and  fixing the fine wiring of iron core memory.  Then ICs were only for IBM and NASA, very expensive and custom made.


Regards,

John L. Males
13 December 2015 14:06
Toronto, Ontario
Canada

[etd...@yahoo.com]

One thing I would do is to check the calibration on all the thermometers.  Freeze some distilled water, break the cubes up to make chips and place the chips in an insulated container.  The container could be as simple as a foam cup.  Insert each thermometer into the ice/water mixture and check to see if they read 0C/32F.  Do this only if each thermometer can go down below freezing.  A steam point could be done; but, you would need to know the barometric pressure and correct the boiling point.  Record the error (if any) and use it to correct the readings that the thermometers give you at or near room temperature.  (Beside humidity, I use to calibrate thermometers to ASTM standards.)

I looked into software raid and decided it was too complicated for me.  The hardware raid works for me right now.  

I tried to install Amanda for tape backup and ran into a brick wall.  The version I was trying to use would not label the tapes thus making the program useless.  I posted the problem on the Zmanda forum and did not get a satisfactory answer.  Perhaps a solution is to upgrade my Linux from 14 to 22.  I tried 14 to 16 and it worked very well.  When I tried 16 to 18 another roadblock popped up.  My monitor would not work and gave me an error that the monitor could not display what was coming into the VGA port.  I will try changing from the MB's VGA port to an addin video card that can do DVI sometime in the future.

On Sunday, November 22, 2015 at 11:31:28 AM UTC-5, Michał Ćmiel wrote: