Summary: owserver daemon returns value "-0.065" for all sensor parameters (temp, humidity, humidex, etc.) on a known-good EDS ENV-TH (EDS0065) temp/humidity sensor.
Background:
I have a working owserver 3.1p5 setup on Ubuntu 16.04.4 LTS, x86
32-bit. (Intel Core Solo CPU.) Compiled w/ default ./configure options on the server host.
owserver gathers sensor data via TCP socket from an EDS OWSERVER-ENET-2 hardware busmaster device. I have about 15 DS18B20 sensors all working fine with this setup, for about 3
months continuously.
I then bought an EDS ENV-TH (combined temp/humidity sensor), model
identifier EDS0065. This is listed as fully-supported by OWFS /
owserver.
After connecting the device to my hardware bus-master, I checked the
bus-master's built-in web page and can see that the ENV-TH sensor is
returning correct readings.
When I then try using OWFS owhttp to read data from the bus-master
device, I also get valid HTML files, and in the web browser when I drill
down to "/7E.062E00001000/EDS0065/", I see tables with correct listings
for sensor data.
So, I think the sensor and the bus-master are working fine.
When I then try to connect using OWFS owserver, (after killing owhttp of
course, and being certain no other OWFS processes are running,) and then
try to use owread to access the sensor data, I get the same output
regardless of which parameter I check. This output never changes:
Why is owserver returning "-0.0625" for all sensor readings, all the
time? (The actual values should be say, 15 for temperature and 50 to 60
for relative humidity.)
The only thing I can think of so far is perhaps a bug in an underlying
library within Ubuntu 16.04.4 LTS, or perhaps something related to
compiling & executing on a 32-bit CPU?
Appreciate help on this problem.
Here is my /etc/owfs.conf file for good measure:
#################################### SOURCES ######
#####
###### With this setup, any client (but owserver) uses owserver on the
###### local machine...
##### server: server = localhost:4304
##### #
###### ...and owserver uses the real hardware, by default fake devices
###### This part must be changed on real installation
###### erver: FAKE = DS18S20,DS2405
##### #
###### owserver tcp address
###### erver: server = 192.168.1.145:8080
##### enet
##### #
##################################### OWFS ##########################
##### #
##### mountpoint = /mnt/1wire
##### allow_other
##### #
################################### OWHTTPD #########################
##### http: port = 2121
#####
################################### OWFTPD ##########################
##### ftp: port = 2120
#####
################################### OWSERVER ########################
##### server: port = localhost:4304
Last edit: Gilbert Osmond 2017-03-10
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
>
> ######################## SOURCES ########################
> #
> # With this setup, any client (but owserver) uses owserver on the
> # local machine...
> server: server = localhost:4304
>
No, it doesn't.
This … is a loop. You advise owserver to talk to itself to get data. It has to read
!server: server = localhost:4304
> > # owserver tcp address
> enet
>
This means *every component of owfs* should directly talk to an enet server, too. It should read
server: enet
instead.
> ######################### OWFS ##########################
> mountpoint = /mnt/1wire
> allow_other
>
Not using the owfs binary, you don't need this.
> ####################### OWHTTPD #########################
> http: port = 2121
>
Ok. But this is the default setting, so you don't need this.
> ####################### OWFTPD ##########################
> ftp: port = 2120
>
Not using the owftpd binary, you don't need this.
> ####################### OWSERVER ########################
> server: port = localhost:4304
>
Ok. But this is the default setting, so you don't need this.
Last edit: Jan Kandziora 2017-03-05
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
For good measure & since it wasn't hard to do, I went ahead & implemented all your suggested changes to my owfs.conf. The behavior overall & the specific problem with the sensor ID 7E.062Exxxxxx remains unchanged.
######################## SOURCES ########################
#
# With this setup, any client (but owserver) uses owserver on the
# local machine...
!server: server = localhost:4304
#
# owserver tcp address
server: enet
######################### OWFS ##########################
#
#mountpoint = /mnt/1wire
#allow_other
#
####################### OWHTTPD #########################
#
#http: port = 2121
#
####################### OWFTPD ##########################
#
#ftp: port = 2120
#
####################### OWSERVER ########################
#
#server: port = localhost:4304
Sorry for the excess communications.
On further research, I have eliminated a native bug within OWFS owserver as the cause.
The problem is that my 3rd party application "OpenHAB" (a home automation package that runs in java) is forming requests for this particular sensor in a way that permanently confuses OWFS owserver.
Sequence of operations:
• Clean reboot of system.
• Start up owserver manually from command line.
• Query the 7E.062E00001000/EDS0065 sensor.
• Receive expected, good values.
• Start up OpenHAB home automation software with OneWire binding module.
• OpenHAB successfully queries all the DS18B20 sensors, BUT, as soon as it quries the 7E.062xxx EDS0065 sensor, owserver appears to "get confused" and thenceforward all it will return is "-0.0625" -- even when queried outside with the owread shell too.
As soon as I quit OpenHAB & stop the queries from OpenHAB, then restart owserver, this sensor reads normally.
So, this is a complicated & nasty liittle bug somewhere in the interaction between OpenHAB and owserver, or possibly even between OpenHAB and the OWSERVER-ENET-2 hardware busmaster device.
is this something you are willing to help me pursue, i.e. using network packet captures? I would not expect that but I would appreciate it.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Sure we can help you. Could you post two owserver logs of the identical owread -s localhost:4304 /uncached7E.062E00001000/EDS0065/temperature operation, one in the ok and one in the stuck fashion? That would help a lot.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
OK -- the next 2 posts upcoming contain 2 different sequences:
FIRST, the WORKING sequence, where a freshly-started owserver daemon responds with normal, valid data for the new EDS0065 humidity sensor.
SECOND, the BROKEN sequence, where the OpenHAB software's OneWire binding (TCP socket client) queries owserver shortly after OpenHAB starts up. owserver responds with the static "bad" value, which then causes owserver to return the "bad" value regardless of client (i.e. from OpenHAB binding, OR from "owread",) and regardless of caching or even parameter name.
I am not sure if it's the enumeration request, or the specific deviceID request, that seems to break owserver.
owserver continues to return normal, valid values for all other sensors, even after the corrupting request.
It's possible the problem is not in owserver, but at the top of the data stream, i.e. possibly a bug in the OWSERVER-ENET-2 hardware busmaster device from Embedded Data Systems (?)
OpenHAB then loads a "binding" (protocol interpreter) for OneWire which uses a TCP socket to query owserver on localhost:4304.
This OneWire binding software has been working fine for months with ~15 DS18B20 1Wire sensor definitions, and owserver 3.1p4 (and now 3.1p5, recently.)
But the first time the OneWire binding queries the new EDS0065 Temp/Humidity sensor, owserver responds with bad data, and moreover, owserver
continues to return static, invalid data for that sensor, both to OpenHAB and when using "owread" from the command line, until owserver is killed and restarted.
(Then "owread" will return correct values, up until the next time OpenHAB makes a corrupting query again.)
The bad response value is "31.8875" (which is the Fahreheit equivalent of -0.625 C.) It is an invalid value, and once corrupted it never changes until owserver is restarted.
The OneWire binding query packets log -- note, this includes both the initial enumeration query (OpenHAB binding requesting a list of devices,) and then a specific query for device ID: 7E.062E00001000
I applied the patch & re-compiled. I am not experienced at patching so I hope it worked out. If the patch did not work, pls. give more explicit instructions about how to apply the patch, i.e. what directory to be in, and what "patch" command to use.
Good output debug log in this post, Bad / broken output log in the next post. I am not re-posting the tcpflow packet logs as I assume those would not change & can be referred to above if needed.
GOOD OUTPUT, from command: owread -s localhost:4304 /uncached/7E.062E00001000/EDS0065/temperature
owserver DEBUG LOG
Mar918:16:521850OpenHABOWFS[13243]:DEBUG:ow_tcp_read.c:(63)attempt24bytesTime:10.000000secondsMar918:16:521850OpenHABOWFS[13243]:DEBUG:ow_tcp_read.c:(113)read:24-0=24Mar918:16:521850OpenHABOWFS[13243]:DEBUG:from_client.c:(66)FromClientpayload=46size=65536type=2sg=0x10Aoffset=0Mar918:16:521850OpenHABOWFS[13243]:DEBUG:from_client.c:(74)FromClient(noservermessage)payload=46size=65536type=2controlflags=0x10Aoffset=0Mar918:16:521850OpenHABOWFS[13243]:DEBUG:ow_tcp_read.c:(63)attempt46bytesTime:10.000000secondsMar918:16:521850OpenHABOWFS[13243]:DEBUG:ow_tcp_read.c:(113)read:46-0=46Mar918:16:521850OpenHABOWFS[13243]:DEBUG:handler.c:(153)STARThandler/uncached/7E.062E00001000/EDS0065/temperatureMar918:16:521850OpenHABOWFS[13243]:CALL:data.c:(103)DataHandler:parsepath=/uncached/7E.062E00001000/EDS0065/temperatureMar918:16:521850OpenHABOWFS[13243]:DEBUG:ow_parseobject.c:(163)/uncached/7E.062E00001000/EDS0065/temperatureMar918:16:521850OpenHABOWFS[13243]:CALL:ow_parsename.c:(104)path=[/uncached/7E.062E00001000/EDS0065/temperature]Mar918:16:521850OpenHABOWFS[13243]:DEBUG:ow_regex.c:(74)RegExexpression<^bus\.([[:digit:]]+)/?>compiledto0xb77ad400Mar918:16:521850OpenHABOWFS[13243]:DEBUG:ow_regex.c:(74)RegExexpression<^settings/?>compiledto0xb77ad3e0Mar918:16:521850OpenHABOWFS[13243]:DEBUG:ow_regex.c:(74)RegExexpression<^statistics/?>compiledto0xb77ad3c0Mar918:16:521850OpenHABOWFS[13243]:DEBUG:ow_regex.c:(74)RegExexpression<^structure/?>compiledto0xb77ad3a0Mar918:16:521850OpenHABOWFS[13243]:DEBUG:ow_regex.c:(74)RegExexpression<^system/?>compiledto0xb77ad380Mar918:16:521850OpenHABOWFS[13243]:DEBUG:ow_regex.c:(74)RegExexpression<^interface/?>compiledto0xb77ad360Mar918:16:521850OpenHABOWFS[13243]:DEBUG:ow_regex.c:(74)RegExexpression<^text/?>compiledto0xb77ad340Mar918:16:521850OpenHABOWFS[13243]:DEBUG:ow_regex.c:(74)RegExexpression<^json/?>compiledto0xb77ad320Mar918:16:521850OpenHABOWFS[13243]:DEBUG:ow_regex.c:(74)RegExexpression<^uncached/?>compiledto0xb77ad300Mar918:16:521850OpenHABOWFS[13243]:DEBUG:ow_regex.c:(74)RegExexpression<^unaliased/?>compiledto0xb77ad2e0Mar918:16:521850OpenHABOWFS[13243]:DEBUG:ow_regex.c:(154)NotfoundMar918:16:521850OpenHABOWFS[13243]:DEBUG:ow_regex.c:(154)NotfoundMar918:16:521850OpenHABOWFS[13243]:DEBUG:ow_regex.c:(74)RegExexpression<^alarm?>compiledto0xb77ad1e0Mar918:16:521850OpenHABOWFS[13243]:DEBUG:ow_regex.c:(74)RegExexpression<^simultaneous/?>compiledto0xb77ad2a0Mar918:16:521850OpenHABOWFS[13243]:DEBUG:ow_regex.c:(74)RegExexpression<^thermostat/?>compiledto0xb77ad280Mar918:16:521850OpenHABOWFS[13243]:DEBUG:ow_regex.c:(74)RegExexpression<^text/?>compiledto0xb77ad260Mar918:16:521850OpenHABOWFS[13243]:DEBUG:ow_regex.c:(74)RegExexpression<^json/?>compiledto0xb77ad240Mar918:16:521850OpenHABOWFS[13243]:DEBUG:ow_regex.c:(74)RegExexpression<^uncached/?>compiledto0xb77ad220Mar918:16:521850OpenHABOWFS[13243]:DEBUG:ow_regex.c:(74)RegExexpression<^unaliased/?>compiledto0xb77ad200Mar918:16:521850OpenHABOWFS[13243]:DEBUG:ow_regex.c:(74)RegExexpression<^([[:xdigit:]]{2})\.?([[:xdigit:]]{12})\.?([[:xdigit:]]{2}){0,1}$>compiledto0xb77ad420Mar918:16:521850OpenHABOWFS[13243]:DEBUG:ow_regex.c:(201)0:0->15found<><7E.062E00001000><>Mar918:16:521850OpenHABOWFS[13243]:DEBUG:ow_regex.c:(201)1:0->2found<><7E><.062E00001000>Mar918:16:521850OpenHABOWFS[13243]:DEBUG:ow_regex.c:(201)2:3->15found<7E.><062E00001000><>Mar918:16:521850OpenHABOWFS[13243]:DEBUG:ow_cache.c:(912)Lookingfordevice7E062E00001000A8Mar918:16:521850OpenHABOWFS[13243]:DEBUG:ow_cache.c:(1070)Searchincachesn7E062E00001000A8pointer=0xb77ad628index=0size=4Mar918:16:521850OpenHABOWFS[13243]:DEBUG:ow_cache.c:(1106)ValuenotfoundincacheMar918:16:521850OpenHABOWFS[13243]:DETAIL:ow_presence.c:(80)Checkingpresenceof/uncached/7E.062E00001000/EDS0065/temperatureMar918:16:521850OpenHABOWFS[13243]:DEBUG:ow_transaction.c:(379)pack=RESETENDVERIFYMar918:16:521850OpenHABOWFS[13243]:DEBUG:ow_transaction.c:(254)ItemcannotbebundledMar918:16:521850OpenHABOWFS[13243]:DEBUG:ow_transaction.c:(274)ShipPackets=0Mar918:16:521850OpenHABOWFS[13243]:DEBUG:ow_select.c:(70)Selectingapath(anddevice)path=/uncached/7E.062E00001000/EDS0065/temperatureSN=7E062E00001000A8lastpath=0000000000000000Mar918:16:521850OpenHABOWFS[13243]:DEBUG:ow_select.c:(74)Useadapter-specificselectroutineMar918:16:521850OpenHABOWFS[13243]:DEBUG:ow_tcp_read.c:(63)attempt3bytesTime:0.6000000secondsMar918:16:521850OpenHABOWFS[13243]:DEBUG:ow_tcp_read.c:(113)read:3-0=3Mar918:16:521850OpenHABOWFS[13243]:DEBUG:ow_tcp_read.c:(63)attempt52bytesTime:0.6000000secondsMar918:16:521850OpenHABOWFS[13243]:DEBUG:ow_tcp_read.c:(113)read:52-0=52Mar918:16:521850OpenHABOWFS[13243]:DEBUG:ow_transaction.c:(222)verify=0Mar918:16:521850OpenHABOWFS[13243]:DEBUG:ow_transaction.c:(274)ShipPackets=0Mar918:16:521850OpenHABOWFS[13243]:DEBUG:ow_presence.c:(274)Presenceof7E062E00001000A8FOUNDonbus192.168.1.126:8080Mar918:16:521850OpenHABOWFS[13243]:DEBUG:ow_cache.c:(546)Addingdevicelocation7E062E00001000A8bus=3Mar918:16:521850OpenHABOWFS[13243]:DEBUG:ow_cache.c:(635)Addtocachesn7E062E00001000A8pointer=0xb77ad628index=0size=4Mar918:16:521850OpenHABOWFS[13243]:DEBUG:ow_transaction.c:(379)pack=RESETENDVERIFYMar918:16:521850OpenHABOWFS[13243]:DEBUG:ow_transaction.c:(254)ItemcannotbebundledMar918:16:521850OpenHABOWFS[13243]:DEBUG:ow_transaction.c:(274)ShipPackets=0Mar918:16:521850OpenHABOWFS[13243]:DEBUG:ow_select.c:(70)Selectingapath(anddevice)path=/uncached/7E.062E00001000/EDS0065/temperatureSN=7E062E00001000A8lastpath=0000000000000000Mar918:16:521850OpenHABOWFS[13243]:DEBUG:ow_select.c:(74)Useadapter-specificselectroutineMar918:16:521850OpenHABOWFS[13243]:DEBUG:ow_tcp_read.c:(63)attempt3bytesTime:0.6000000secondsMar918:16:521850OpenHABOWFS[13243]:DEBUG:ow_tcp_read.c:(113)read:3-0=3Mar918:16:521850OpenHABOWFS[13243]:DEBUG:ow_tcp_read.c:(63)attempt52bytesTime:0.6000000secondsMar918:16:521850OpenHABOWFS[13243]:DEBUG:ow_tcp_read.c:(113)read:52-0=52Mar918:16:521850OpenHABOWFS[13243]:DEBUG:ow_transaction.c:(222)verify=1Mar918:16:521850OpenHABOWFS[13243]:DEBUG:ow_presence.c:(272)Presenceof7E062E00001000A8NOTfoundonbus192.168.1.126:8080Mar918:16:521850OpenHABOWFS[13243]:DEBUG:ow_transaction.c:(379)pack=RESETENDVERIFYMar918:16:521850OpenHABOWFS[13243]:DEBUG:ow_transaction.c:(254)ItemcannotbebundledMar918:16:521850OpenHABOWFS[13243]:DEBUG:ow_transaction.c:(274)ShipPackets=0Mar918:16:521850OpenHABOWFS[13243]:DEBUG:ow_select.c:(70)Selectingapath(anddevice)path=/uncached/7E.062E00001000/EDS0065/temperatureSN=7E062E00001000A8lastpath=0000000000000000Mar918:16:521850OpenHABOWFS[13243]:DEBUG:ow_select.c:(74)Useadapter-specificselectroutineMar918:16:521850OpenHABOWFS[13243]:DEBUG:ow_tcp_read.c:(63)attempt3bytesTime:0.6000000secondsMar918:16:521850OpenHABOWFS[13243]:DEBUG:ow_tcp_read.c:(113)read:3-0=3Mar918:16:521850OpenHABOWFS[13243]:DEBUG:ow_tcp_read.c:(63)attempt52bytesTime:0.6000000secondsMar918:16:521850OpenHABOWFS[13243]:DEBUG:ow_tcp_read.c:(113)read:52-0=52Mar918:16:521850OpenHABOWFS[13243]:DEBUG:ow_transaction.c:(222)verify=1Mar918:16:521850OpenHABOWFS[13243]:DEBUG:ow_presence.c:(272)Presenceof7E062E00001000A8NOTfoundonbus192.168.1.126:8080Mar918:16:521850OpenHABOWFS[13243]:DEBUG:ow_cache.c:(546)Addingdevicelocation7E062E00001000A8bus=3Mar918:16:521850OpenHABOWFS[13243]:DEBUG:ow_cache.c:(635)Addtocachesn7E062E00001000A8pointer=0xb77ad628index=0size=4Mar918:16:521850OpenHABOWFS[13243]:DEBUG:ow_regex.c:(74)RegExexpression<\.>compiledto0xb77ad140Mar918:16:521850OpenHABOWFS[13243]:DEBUG:ow_regex.c:(74)RegExexpression<\.all$>compiledto0xb77ad120Mar918:16:521850OpenHABOWFS[13243]:DEBUG:ow_regex.c:(74)RegExexpression<\.byte$>compiledto0xb77ad100Mar918:16:521850OpenHABOWFS[13243]:DEBUG:ow_regex.c:(74)RegExexpression<\.[[:digit:]]+$>compiledto0xb77ad0e0Mar918:16:521850OpenHABOWFS[13243]:DEBUG:ow_regex.c:(74)RegExexpression<\.[[:alpha:]]$>compiledto0xb77ad0c0Mar918:16:521850OpenHABOWFS[13243]:DEBUG:ow_regex.c:(154)NotfoundMar918:16:521850OpenHABOWFS[13243]:DEBUG:ow_regex.c:(154)NotfoundMar918:16:521850OpenHABOWFS[13243]:CALL:data.c:(144)ReadmessageMar918:16:521850OpenHABOWFS[13243]:DEBUG:read.c:(55)ReadHandlerstartMar918:16:521850OpenHABOWFS[13243]:DEBUG:read.c:(61)ReadHandler:FromClientsm->payload=46sm->size=65536sm->offset=0Mar918:16:521850OpenHABOWFS[13243]:DEBUG:read.c:(79)ReadHandler:callFS_read_postparseon/uncached/7E.062E00001000/EDS0065/temperatureMar918:16:521850OpenHABOWFS[13243]:DEBUG:ow_read.c:(72)/uncached/7E.062E00001000/EDS0065/temperatureMar918:16:521850OpenHABOWFS[13243]:DEBUG:ow_read.c:(204)/uncached/7E.062E00001000/EDS0065/temperatureMar918:16:521850OpenHABOWFS[13243]:DEBUG:ow_read.c:(238)Abouttoread</uncached/7E.062E00001000/EDS0065/temperature>extension=0size=12offset=0Mar918:16:521850OpenHABOWFS[13243]:DEBUG:ow_read.c:(333)file_length=12offset=0size=12Mar918:16:521850OpenHABOWFS[13243]:DEBUG:ow_transaction.c:(311)pack=SELECTMar918:16:521850OpenHABOWFS[13243]:DEBUG:ow_transaction.c:(251)ItemaddedMar918:16:521850OpenHABOWFS[13243]:DEBUG:ow_transaction.c:(339)pack=MATCHMODIFYBLINDMar918:16:521850OpenHABOWFS[13243]:DEBUG:ow_transaction.c:(251)ItemaddedMar918:16:521850OpenHABOWFS[13243]:DEBUG:ow_transaction.c:(323)pack=READMar918:16:521850OpenHABOWFS[13243]:DEBUG:ow_transaction.c:(251)ItemaddedMar918:16:521850OpenHABOWFS[13243]:DEBUG:ow_transaction.c:(274)ShipPackets=3Mar918:16:521850OpenHABOWFS[13243]:DEBUG:ow_select.c:(70)Selectingapath(anddevice)path=/uncached/7E.062E00001000/EDS0065/temperatureSN=7E062E00001000A8lastpath=0000000000000000Mar918:16:521850OpenHABOWFS[13243]:DEBUG:ow_select.c:(74)Useadapter-specificselectroutineMar918:16:521850OpenHABOWFS[13243]:DEBUG:ow_tcp_read.c:(63)attempt3bytesTime:0.6000000secondsMar918:16:521850OpenHABOWFS[13243]:DEBUG:ow_tcp_read.c:(113)read:3-0=3Mar918:16:521850OpenHABOWFS[13243]:DEBUG:ow_tcp_read.c:(63)attempt3bytesTime:0.6000000secondsMar918:16:521850OpenHABOWFS[13243]:DEBUG:ow_tcp_read.c:(113)read:3-0=3Mar918:16:521850OpenHABOWFS[13243]:DEBUG:ow_tcp_read.c:(63)attempt12bytesTime:0.6000000secondsMar918:16:521850OpenHABOWFS[13243]:DEBUG:ow_tcp_read.c:(113)read:12-0=12Mar918:16:521850OpenHABOWFS[13243]:DEBUG:ow_transaction.c:(399)unpackingMar918:16:521850OpenHABOWFS[13243]:DEBUG:ow_transaction.c:(481)unpacking#0 NOP or SELECTMar918:16:521850OpenHABOWFS[13243]:DEBUG:ow_transaction.c:(417)unpacking#1 MATCHMar918:16:521850OpenHABOWFS[13243]:DEBUG:ow_transaction.c:(425)unpacking#2 READ MODIFYMar918:16:521850OpenHABOWFS[13243]:DEBUG:ow_read.c:(620)Read/uncached/7E.062E00001000/EDS0065/temperatureExtension0Givesresult0Mar918:16:521850OpenHABOWFS[13243]:DEBUG:ow_cache.c:(384)Addingdatafor/uncached/7E.062E00001000/EDS0065/temperatureMar918:16:521850OpenHABOWFS[13243]:DEBUG:ow_cache.c:(421)7E062E00001000A8size=8Mar918:16:521850OpenHABOWFS[13243]:DEBUG:ow_cache.c:(635)Addtocachesn7E062E00001000A8pointer=0xb77a4340index=0size=8Mar918:16:521850OpenHABOWFS[13243]:DEBUG:ow_read.c:(253)return=0Mar918:16:521850OpenHABOWFS[13243]:DEBUG:ow_parseoutput.c:(49)OWQ_parse_outputMar918:16:521850OpenHABOWFS[13243]:DEBUG:ow_parseoutput.c:(158)OWQ_parse_output_floatMar918:16:521850OpenHABOWFS[13243]:DEBUG:ow_parseoutput.c:(165)OWQ_parse_output_float,ft_temperature:21.3125Mar918:16:521850OpenHABOWFS[13243]:DEBUG:ow_read.c:(263)Afterreadisperformed(bytesorerror12)Mar918:16:521850OpenHABOWFS[13243]:DEBUG:ow_read.c:(226)/uncached/7E.062E00001000/EDS0065/temperaturereturns12Mar918:16:521850OpenHABOWFS[13243]:DEBUG:ow_read.c:(103)/uncached/7E.062E00001000/EDS0065/temperaturereturn12Mar918:16:521850OpenHABOWFS[13243]:DEBUG:read.c:(81)ReadHandler:FS_read_postparsereadon/uncached/7E.062E00001000/EDS0065/temperaturereturn=12Mar918:16:521850OpenHABOWFS[13243]:DEBUG:read.c:(89)ReadHandler:FS_read_postparseoksize=12Mar918:16:521850OpenHABOWFS[13243]:DEBUG:read.c:(100)ReadHandler:ToClientcm->payload=12cm->size=12cm->offset=0Mar918:16:521850OpenHABOWFS[13243]:DEBUG:data.c:(146)Readmessagedonevalue=0xb5913d98Mar918:16:521850OpenHABOWFS[13243]:DEBUG:ow_parsename.c:(63)/uncached/7E.062E00001000/EDS0065/temperatureMar918:16:521850OpenHABOWFS[13243]:DEBUG:data.c:(193)DataHandler:FS_ParsedName_destroydoneMar918:16:521850OpenHABOWFS[13243]:DEBUG:data.c:(207)DataHandler:cm.ret=12Mar918:16:521850OpenHABOWFS[13243]:DEBUG:to_client.c:(76)payload=12size=12,ret=12,sg=0x10Aoffset=0Mar918:16:521850OpenHABOWFS[13243]:DEBUG:data.c:(226)FinishedwithclientrequestMar918:16:521850OpenHABOWFS[13243]:DEBUG:handler.c:(135)OWSERVERhandlerdoneMar918:16:521850OpenHABOWFS[13243]:DEBUG:ow_net_server.c:(259)Normalcompletion.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Here is the "Bad" debug output. Keep in mind, again, this contains the initial enumeration / directory listing request, and then the specific Device ID request for the 7E.062Exxxxx device:
Mar 9 18:41:02 1850OpenHAB OWFS[14125]: DEBUG: ow_parseoutput.c:(49) OWQ_parse_output
Mar 9 18:41:02 1850OpenHAB OWFS[14125]: DEBUG: ow_parseoutput.c:(158) OWQ_parse_output_float
Mar 9 18:41:02 1850OpenHAB OWFS[14125]: DEBUG: ow_parseoutput.c:(165) OWQ_parse_output_float, ft_temperature: 31.8875
This tells me the EDS0065 device already returns a wrong value to owserver. I guess OpenHAB accidentally tweaks some settings on the EDS0065 by accessing some other nodes in a unexpected way.
What I would do now: Write a test script to simulate what OpenHAB might do and hope I can also trigger the problem. Then, comment out half of my test script commands, try again (clean, of course) and see if the problem persists. And so on, until I have the single command which offends the ED0065.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Summary: owserver daemon returns value "-0.065" for all sensor parameters (temp, humidity, humidex, etc.) on a known-good EDS ENV-TH (EDS0065) temp/humidity sensor.
Background:
I have a working owserver 3.1p5 setup on Ubuntu 16.04.4 LTS, x86
32-bit. (Intel Core Solo CPU.) Compiled w/ default ./configure options on the server host.
owserver gathers sensor data via TCP socket from an EDS OWSERVER-ENET-2 hardware busmaster device. I have about 15 DS18B20 sensors all working fine with this setup, for about 3
months continuously.
I then bought an EDS ENV-TH (combined temp/humidity sensor), model
identifier EDS0065. This is listed as fully-supported by OWFS /
owserver.
After connecting the device to my hardware bus-master, I checked the
bus-master's built-in web page and can see that the ENV-TH sensor is
returning correct readings.
When I then try using OWFS owhttp to read data from the bus-master
device, I also get valid HTML files, and in the web browser when I drill
down to "/7E.062E00001000/EDS0065/", I see tables with correct listings
for sensor data.
So, I think the sensor and the bus-master are working fine.
When I then try to connect using OWFS owserver, (after killing owhttp of
course, and being certain no other OWFS processes are running,) and then
try to use owread to access the sensor data, I get the same output
regardless of which parameter I check. This output never changes:
user@OpenHAB:/opt/owfs/bin$ owread -s localhost:4304 /7E.062E00001000/EDS0065/temperature -0.0625 user@OpenHAB:/opt/owfs/bin$ owread -s localhost:4304 /7E.062E00001000/EDS0065/humidity -0.0625 user@OpenHAB:/opt/owfs/bin$ owread -s localhost:4304 /7E.062E00001000/EDS0065/humidex -0.0625 user@OpenHAB:/opt/owfs/bin$ owread -s localhost:4304 /7E.062E00001000/EDS0065/heat_index -0.0625 user@OpenHAB:/opt/owfs/bin$ owread -s localhost:4304 /7E.062E00001000/EDS0065/dew_point -0.0625Why is owserver returning "-0.0625" for all sensor readings, all the
time? (The actual values should be say, 15 for temperature and 50 to 60
for relative humidity.)
The only thing I can think of so far is perhaps a bug in an underlying
library within Ubuntu 16.04.4 LTS, or perhaps something related to
compiling & executing on a 32-bit CPU?
Appreciate help on this problem.
Here is my /etc/owfs.conf file for good measure:
Last edit: Gilbert Osmond 2017-03-10
Last edit: Jan Kandziora 2017-03-05
post retracted, please delete.
Last edit: Gilbert Osmond 2017-03-05
For good measure & since it wasn't hard to do, I went ahead & implemented all your suggested changes to my owfs.conf. The behavior overall & the specific problem with the sensor ID 7E.062Exxxxxx remains unchanged.
The output from owread is unchanged:
user@OpenHAB:/opt/owfs/bin$ owread -s localhost:4304 /7E.062E00001000/EDS0065/temperature -0.0625 user@OpenHAB:/opt/owfs/bin$ owread -s localhost:4304 /7E.062E00001000/EDS0065/humidity -0.0625 user@OpenHAB:/opt/owfs/bin$ owread -s localhost:4304 /7E.062E00001000/EDS0065/humidex -0.0625 user@OpenHAB:/opt/owfs/bin$ owread -s localhost:4304 /7E.062E00001000/EDS0065/heat_index -0.0625 user@OpenHAB:/opt/owfs/bin$ owread -s localhost:4304 /7E.062E00001000/EDS0065/dew_point -0.0625Other sensors (all DS18B20's) continue to work as expected:
user@OpenHAB:/opt/owfs/bin$ owread -s localhost:4304 /28.FF3FD4741604/temperature 12.875Last edit: Gilbert Osmond 2017-03-05
Does the reading change when you use /uncached/7E.062E00001000/EDS0065/temperature instead?
No, it does not change. Same output:
user@OpenHAB:/opt/owfs/bin$ owread -s localhost:4304 /uncached/7E.062E00001000/EDS0065/temperature -0.0625Last edit: Gilbert Osmond 2017-03-06
Here is --error_level=9 output from owserver:
COMMAND:
owread -s localhost:4304 /7E.062E00001000/EDS0065/temperatureCOMMAND OUTPUT:
-0.0625LOG OUTPUT:
And here is another log sample from a properly-working sensor:
COMMAND:
user@OpenHAB:/opt/owfs/bin$ owread -s localhost:4304 /28.FF3FD4741604/temperatureCOMMAND OUTPUT (a valid, real-world Celsius temperature)
12.625owserver LOG OUTPUT:
Sorry for the excess communications.
On further research, I have eliminated a native bug within OWFS owserver as the cause.
The problem is that my 3rd party application "OpenHAB" (a home automation package that runs in java) is forming requests for this particular sensor in a way that permanently confuses OWFS owserver.
Sequence of operations:
• Clean reboot of system.
• Start up owserver manually from command line.
• Query the 7E.062E00001000/EDS0065 sensor.
• Receive expected, good values.
• Start up OpenHAB home automation software with OneWire binding module.
• OpenHAB successfully queries all the DS18B20 sensors, BUT, as soon as it quries the 7E.062xxx EDS0065 sensor, owserver appears to "get confused" and thenceforward all it will return is "-0.0625" -- even when queried outside with the owread shell too.
As soon as I quit OpenHAB & stop the queries from OpenHAB, then restart owserver, this sensor reads normally.
So, this is a complicated & nasty liittle bug somewhere in the interaction between OpenHAB and owserver, or possibly even between OpenHAB and the OWSERVER-ENET-2 hardware busmaster device.
is this something you are willing to help me pursue, i.e. using network packet captures? I would not expect that but I would appreciate it.
Sure we can help you. Could you post two owserver logs of the identical owread -s localhost:4304 /uncached7E.062E00001000/EDS0065/temperature operation, one in the ok and one in the stuck fashion? That would help a lot.
OK -- the next 2 posts upcoming contain 2 different sequences:
FIRST, the WORKING sequence, where a freshly-started owserver daemon responds with normal, valid data for the new EDS0065 humidity sensor.
SECOND, the BROKEN sequence, where the OpenHAB software's OneWire binding (TCP socket client) queries owserver shortly after OpenHAB starts up. owserver responds with the static "bad" value, which then causes owserver to return the "bad" value regardless of client (i.e. from OpenHAB binding, OR from "owread",) and regardless of caching or even parameter name.
/***********/
/ GOOD / NORMAL owserver query / response cycle */
/**********/
CONDITIONS: owserver daemon running alone, after fresh kill -9 and re-start using command:
user@OpenHAB:~$ /usr/bin/owserver --error_level=9 -c /etc/owfs.confQUERY COMMAND:
owread -s localhost:4304 /uncached/7E.062E00001000/EDS0065/temperatureQUERY RESULT:
19.125(degrees Celsius, a valid response with a correct value.)TCPFLOW (network packet analysis) OUTPUT:
OWSERVER DEBUG LOG OUTPUT:
/***********/
/ The "BAD" query that "breaks" owserver **/
/**********/
CONDITIONS: owserver daemon running , after fresh kill -9 and re-start using command:
user@OpenHAB:~$ /usr/bin/owserver --error_level=9 -c /etc/owfs.confSequence of events:
"OpenHAB" v1.8.3 java-based home-automation server daemon then started up from command line.
~10-15 seconds to load OpenHAB, during which owserver remains idle.
OpenHAB then loads a "binding" (protocol interpreter) for OneWire which uses a TCP socket to query owserver on localhost:4304.
This OneWire binding software has been working fine for months with ~15 DS18B20 1Wire sensor definitions, and owserver 3.1p4 (and now 3.1p5, recently.)
But the first time the OneWire binding queries the new EDS0065 Temp/Humidity sensor, owserver responds with bad data, and moreover, owserver
continues to return static, invalid data for that sensor, both to OpenHAB and when using "owread" from the command line, until owserver is killed and restarted.
(Then "owread" will return correct values, up until the next time OpenHAB makes a corrupting query again.)
The bad response value is "31.8875" (which is the Fahreheit equivalent of -0.625 C.) It is an invalid value, and once corrupted it never changes until owserver is restarted.
The OneWire binding query packets log -- note, this includes both the initial enumeration query (OpenHAB binding requesting a list of devices,) and then a specific query for device ID: 7E.062E00001000
TCPFLOW (network packet analysis) OUTPUT:
/********
OWSERVER DEBUG LOG OUTPUT:
/*********/
Could you please apply the following patch and try again? I like to get some more information where the wrong value is crawling in.
I applied the patch & re-compiled. I am not experienced at patching so I hope it worked out. If the patch did not work, pls. give more explicit instructions about how to apply the patch, i.e. what directory to be in, and what "patch" command to use.
Good output debug log in this post, Bad / broken output log in the next post. I am not re-posting the tcpflow packet logs as I assume those would not change & can be referred to above if needed.
GOOD OUTPUT, from command:
owread -s localhost:4304 /uncached/7E.062E00001000/EDS0065/temperatureowserver DEBUG LOG
Here is the "Bad" debug output. Keep in mind, again, this contains the initial enumeration / directory listing request, and then the specific Device ID request for the 7E.062Exxxxx device:
owserver DEBUG output
This tells me the EDS0065 device already returns a wrong value to owserver. I guess OpenHAB accidentally tweaks some settings on the EDS0065 by accessing some other nodes in a unexpected way.
What I would do now: Write a test script to simulate what OpenHAB might do and hope I can also trigger the problem. Then, comment out half of my test script commands, try again (clean, of course) and see if the problem persists. And so on, until I have the single command which offends the ED0065.