owfs-developers — Developer's list for OWFS

Re: [Owfs-developers] 1-wire hubs

[Stefano M. <mo...@ic...>]

I assume that by “1-wire hub” you are referring to a device that allows you to access several distinct physical 1-wire busses as a single logical bus. I think the hub as a point in which a single 1-wire bus “transparently” branches out into several physical distinct busses.

In some cases you do not need a hub, because if you connect multiple bus masters to a single owserver host, the “root” view will show you all devices found under the different busses:

/26.xxx
/26.yyy
/bus.0/26.xxx
/bus.1/26.yyy

In my opinion you need a 1-wire hub only if the physical location at which the different 1-wire buses branch is far from the location at which your owserver host is located, but again with the availability of low-cost single board computers, it could be easier to place an owserver host at the branching location.

This said, iButtonLink sells the linkhube: https://www.ibuttonlink.com/products/linkhube <https://www.ibuttonlink.com/products/linkhube> (which is a bit expensive, in my opinion.)

The unipi product does not seem to be a “1-wire hub” in the sense defined above, as already noted by Jan.

Stefano

 
> On 20 Jul 2019, at 16:52, Jim Duda <ji...@du...> wrote:
> 
> Hello,
> 
> I have a 6 port 1-wire HUB that I purchased years ago from hobbyboards.com
> I think the device has finally stopped working.
> Hobbyboards hasn't come back online yet.
> 
> Can anyone offer any advice on any available 1-wire hub devices for sale?
> 
> The only one I can find is from unipi.
> https://www.unipi.technology/1-wire-8-port-hub-p31
> 
> Any advice appreciated.
> 
> Regards,
> 
> Jim
> 
> 
> 
> _______________________________________________
> Owfs-developers mailing list
> Owf...@li...
> https://lists.sourceforge.net/lists/listinfo/owfs-developers

Re: [Owfs-developers] I just downloaded the OWFS source code from the new GIT location...

[Stefano M. <mo...@ic...>]

The last official source release is v3.2p3 available at https://github.com/owfs/owfs/releases/tag/v3.2p3 <https://github.com/owfs/owfs/releases/tag/v3.2p3>

There have been a number to commits since that release, but should not touch the very old visual basic files.

BTW, I think that opening an issue could still be usefule for documenting this problem, including the exact Norton version and the exact file that the antivirus flags as a Trojan.

SM

> On 18 Jul 2019, at 05:32, Gregg Levine <gre...@gm...> wrote:
> 
> Hello!
> I'd be delighted to do so, except all I have is what I stated above,
> and perhaps the responses (as idiotic as they are) from Norton itself.
> I also followed the same steps to download a new GIT blob onto a
> folder on a Raspberry Pi to which I'd previously gotten OWFS to work
> that way. I've since compressed it into a TAR file which was also
> BZIP2 compressed.
> 
> Depending on what your response is, I'll retrieve it and try again.
> This time extracting that over what is already there.
> 
> Can you tell me, also, if there where any commits to the directory recently?
> -----
> Gregg C Levine gre...@gm...
> "This signature fought the Time Wars, time and again."
> 
> On Wed, Jul 17, 2019 at 1:22 PM Stefano Miccoli via Owfs-developers
> <owf...@li...> wrote:
>> 
>> Can you please open an issue at https://github.com/owfs/owfs/issues with more details?
>> 
>> SM
>> 
>> 
>> On 16 Jul 2019, at 01:34, Gregg Levine <gre...@gm...> wrote:
>> 
>> Hello!
>> Okay I found and downloaded the OWS source code from the new GIT
>> location. But during the process of doing that, I found that Norton
>> insisted that there was a Trojan hiding in the VB example of one of
>> the OWFS programs. I am convinced that this is a rare false positive
>> for the Norton antivirus program.
>> 
>> Incidentally this was downloaded onto a Linux on Windows instance
>> which is posing as SuSe SLES 12 server when running. I've built and
>> run the latest release on it and actually gotten it to work.
>> -----
>> Gregg C Levine gre...@gm...
>> "This signature fought the Time Wars, time and again."
>> 
>> 
>> _______________________________________________
>> Owfs-developers mailing list
>> Owf...@li...
>> https://lists.sourceforge.net/lists/listinfo/owfs-developers
>> 
>> 
>> _______________________________________________
>> Owfs-developers mailing list
>> Owf...@li...
>> https://lists.sourceforge.net/lists/listinfo/owfs-developers

Re: [Owfs-developers] 1-wire hubs

[Jan K. <jj...@gm...>]

Am 20.07.19 um 16:52 schrieb Jim Duda:
> Hello,
>
> I have a 6 port 1-wire HUB that I purchased years ago from hobbyboards.com
> I think the device has finally stopped working.
> Hobbyboards hasn't come back online yet.
>
> Can anyone offer any advice on any available 1-wire hub devices for sale?
>
> The only one I can find is from unipi.
> https://www.unipi.technology/1-wire-8-port-hub-p31
>
If I understand the port wiring given on that site correctly, this is a
purely passive wiring helper.

You have to wire each sensors so it's at the tip of a lobe coming from
the 3+6 GND+DQ pair and going into the 8+7 GND+DQ pair.

Kind regards

	Jan

[Owfs-developers] 1-wire hubs

[Jim D. <ji...@du...>]

Hello,

I have a 6 port 1-wire HUB that I purchased years ago from hobbyboards.com
I think the device has finally stopped working.
Hobbyboards hasn't come back online yet.

Can anyone offer any advice on any available 1-wire hub devices for sale?

The only one I can find is from unipi.
https://www.unipi.technology/1-wire-8-port-hub-p31

Any advice appreciated.

Regards,

Jim

Re: [Owfs-developers] Problem installing owserver on Raspbian Buster

[Jaroslav S. <js...@kk...>]

Hi Colin,
thanks for your reply. There seems to be a problem with owserver start 
job during installation. Although an error is shown, owserver is 
running. Terminal output below.

The most suspicious is this message:
owserver.service: Failed with result 'protocol'.

If I run "dpkg --configure -a" after the failed installation, everything 
seems fine.

In Stretch and earlier releases, everything worked out of the box. The 
/etc/owfs.conf file is the same as in Stretch.

Tried restarting the owserver service few more times and it seems the 
problem only appears a few times on a clean Raspbian image. After a 
while (an hour or so), I am not able to reproduce the issue anymore.

Any hints please? Thank you.

With kind regards,
Jaroslav


pi@raspberrypi:~ $ systemctl status owserver.service
● owserver.service - Backend server for 1-wire control
    Loaded: loaded (/lib/systemd/system/owserver.service; disabled; 
vendor preset: enabled)
    Active: active (running) since Thu 2019-07-18 12:23:25 BST; 12min ago
      Docs: man:owserver(1)
  Main PID: 952 (owserver)
     Tasks: 2 (limit: 2200)
    Memory: 772.0K
    CGroup: /system.slice/owserver.service
            └─952 /usr/bin/owserver -c /etc/owfs.conf

Jul 18 12:23:25 raspberrypi systemd[1]: Starting Backend server for 
1-wire control...
Jul 18 12:23:25 raspberrypi OWFS[952]: DEFAULT: ow_daemon.c:(144) 
Entered background mode, quitting.
Jul 18 12:23:25 raspberrypi systemd[1]: Started Backend server for 
1-wire control.



root@raspberrypi:~# journalctl -n 50
-- Logs begin at Wed 2019-07-10 01:21:16 BST, end at Thu 2019-07-18 
14:27:04 BST. --
Jul 18 14:13:34 raspberrypi systemd[705]: Stopped target Timers.
Jul 18 14:13:34 raspberrypi systemd[705]: gpg-agent-ssh.socket: Succeeded.
Jul 18 14:13:34 raspberrypi systemd[705]: Closed GnuPG cryptographic 
agent (ssh-agent emulation).
Jul 18 14:13:34 raspberrypi systemd[705]: dirmngr.socket: Succeeded.
Jul 18 14:13:34 raspberrypi systemd[705]: Closed GnuPG network 
certificate management daemon.
Jul 18 14:13:34 raspberrypi systemd[705]: Stopped target Paths.
Jul 18 14:13:34 raspberrypi systemd[705]: Reached target Shutdown.
Jul 18 14:13:34 raspberrypi systemd[705]: systemd-exit.service: Succeeded.
Jul 18 14:13:34 raspberrypi systemd[705]: Started Exit the Session.
Jul 18 14:13:34 raspberrypi systemd[705]: Reached target Exit the Session.
Jul 18 14:13:34 raspberrypi systemd[708]: 
pam_unix(systemd-user:session): session closed for user pi
Jul 18 14:13:34 raspberrypi systemd[1]: us...@10...rvice: Succeeded.
Jul 18 14:13:34 raspberrypi systemd[1]: Stopped User Manager for UID 1000.
Jul 18 14:13:34 raspberrypi systemd[1]: Stopping User Runtime Directory 
/run/user/1000...
Jul 18 14:13:34 raspberrypi systemd[757]: run-user-1000.mount: Succeeded.
Jul 18 14:13:34 raspberrypi systemd[1]: run-user-1000.mount: Succeeded.
Jul 18 14:13:34 raspberrypi systemd[1]: use...@10...rvice: 
Succeeded.
Jul 18 14:13:34 raspberrypi systemd[1]: Stopped User Runtime Directory 
/run/user/1000.
Jul 18 14:13:34 raspberrypi systemd[1]: Removed slice User Slice of UID 
1000.
Jul 18 14:14:00 raspberrypi groupadd[945]: group added to /etc/group: 
name=Debian-ow, GID=114
Jul 18 14:14:00 raspberrypi groupadd[945]: group added to /etc/gshadow: 
name=Debian-ow
Jul 18 14:14:00 raspberrypi groupadd[945]: new group: name=Debian-ow, 
GID=114
Jul 18 14:14:00 raspberrypi useradd[950]: new user: name=Debian-ow, 
UID=109, GID=114, home=/var/lib/owfs, shell=/usr/sbin/nologin
Jul 18 14:14:00 raspberrypi chage[957]: changed password expiry for 
Debian-ow
Jul 18 14:14:00 raspberrypi chfn[961]: changed user 'Debian-ow' information
Jul 18 14:14:04 raspberrypi systemd[1]: Reloading.
Jul 18 14:14:04 raspberrypi systemd[1]: ge...@tt...rvice: Current 
command vanished from the unit file, execution of the command list won't 
be resumed.
Jul 18 14:14:04 raspberrypi systemd[1]: ser...@tt...rvice: 
Current command vanished from the unit file, execution of the command 
list won't be resumed.
Jul 18 14:14:04 raspberrypi systemd[1]: Reloading.
Jul 18 14:14:05 raspberrypi systemd[1]: Starting Backend server for 
1-wire control...
Jul 18 14:14:05 raspberrypi OWFS[1134]: DEFAULT: ow_daemon.c:(144) 
Entered background mode, quitting.
Jul 18 14:14:05 raspberrypi systemd[1]: owserver.service: Failed with 
result 'protocol'.
Jul 18 14:14:05 raspberrypi systemd[1]: Failed to start Backend server 
for 1-wire control.
Jul 18 14:14:05 raspberrypi systemd[1]: owserver.service: Service 
RestartSec=100ms expired, scheduling restart.
Jul 18 14:14:05 raspberrypi systemd[1]: owserver.service: Scheduled 
restart job, restart counter is at 1.
Jul 18 14:14:05 raspberrypi systemd[1]: Stopped Backend server for 
1-wire control.
Jul 18 14:14:05 raspberrypi systemd[1]: Starting Backend server for 
1-wire control...
Jul 18 14:14:05 raspberrypi OWFS[1178]: DEFAULT: ow_daemon.c:(144) 
Entered background mode, quitting.
Jul 18 14:14:05 raspberrypi systemd[1]: Started Backend server for 
1-wire control.
Jul 18 14:14:07 raspberrypi systemd[1]: Reloading.
Jul 18 14:17:01 raspberrypi CRON[1256]: pam_unix(cron:session): session 
opened for user root by (uid=0)
Jul 18 14:17:01 raspberrypi CRON[1260]: (root) CMD (   cd / && run-parts 
--report /etc/cron.hourly)
Jul 18 14:17:01 raspberrypi CRON[1256]: pam_unix(cron:session): session 
closed for user root
Jul 18 14:17:34 raspberrypi systemd[1]: Stopping Backend server for 
1-wire control...
Jul 18 14:17:34 raspberrypi systemd[1]: owserver.service: Succeeded.
Jul 18 14:17:34 raspberrypi systemd[1]: Stopped Backend server for 
1-wire control.
Jul 18 14:17:56 raspberrypi OWFS[1282]: DEFAULT: ow_daemon.c:(144) 
Entered background mode, quitting.
Jul 18 14:27:04 raspberrypi systemd[1]: Starting Cleanup of Temporary 
Directories...
Jul 18 14:27:04 raspberrypi systemd[1]: systemd-tmpfiles-clean.service: 
Succeeded.
Jul 18 14:27:04 raspberrypi systemd[1]: Started Cleanup of Temporary 
Directories.



pi@raspberrypi:~ $ journalctl -xe
Jul 18 12:23:24 raspberrypi systemd[1]: Starting Backend server for 
1-wire control...
-- Subject: A start job for unit owserver.service has begun execution
-- Defined-By: systemd
-- Support: https://www.debian.org/support
--
-- A start job for unit owserver.service has begun execution.
--
-- The job identifier is 320.
Jul 18 12:23:24 raspberrypi OWFS[944]: DEFAULT: ow_daemon.c:(144) 
Entered background mode, quitting.
Jul 18 12:23:24 raspberrypi systemd[1]: owserver.service: Failed with 
result 'protocol'.
-- Subject: Unit failed
-- Defined-By: systemd
-- Support: https://www.debian.org/support
--
-- The unit owserver.service has entered the 'failed' state with result 
'protocol'.
Jul 18 12:23:24 raspberrypi systemd[1]: Failed to start Backend server 
for 1-wire control.
-- Subject: A start job for unit owserver.service has failed
-- Defined-By: systemd
-- Support: https://www.debian.org/support
--
-- A start job for unit owserver.service has finished with a failure.
--
-- The job identifier is 320 and the job result is failed.
Jul 18 12:23:24 raspberrypi systemd[1]: owserver.service: Service 
RestartSec=100ms expired, scheduling restart.
Jul 18 12:23:25 raspberrypi systemd[1]: owserver.service: Scheduled 
restart job, restart counter is at 1.
-- Subject: Automatic restarting of a unit has been scheduled
-- Defined-By: systemd
-- Support: https://www.debian.org/support
--
-- Automatic restarting of the unit owserver.service has been scheduled, 
as the result for
-- the configured Restart= setting for the unit.
Jul 18 12:23:25 raspberrypi systemd[1]: Stopped Backend server for 
1-wire control.
-- Subject: A stop job for unit owserver.service has finished
-- Defined-By: systemd
-- Support: https://www.debian.org/support
--
-- A stop job for unit owserver.service has finished.
--
-- The job identifier is 377 and the job result is done.
Jul 18 12:23:25 raspberrypi systemd[1]: Starting Backend server for 
1-wire control...
-- Subject: A start job for unit owserver.service has begun execution
-- Defined-By: systemd
-- Support: https://www.debian.org/support
--
-- A start job for unit owserver.service has begun execution.
--
-- The job identifier is 377.
Jul 18 12:23:25 raspberrypi OWFS[952]: DEFAULT: ow_daemon.c:(144) 
Entered background mode, quitting.
Jul 18 12:23:25 raspberrypi systemd[1]: Started Backend server for 
1-wire control.
-- Subject: A start job for unit owserver.service has finished successfully
-- Defined-By: systemd
-- Support: https://www.debian.org/support
--
-- A start job for unit owserver.service has finished successfully.
--
-- The job identifier is 377.
Jul 18 12:23:26 raspberrypi systemd[1]: Reloading.
Jul 18 12:23:28 raspberrypi sudo[700]: pam_unix(sudo:session): session 
closed for user root



On 16.07.2019 22:43, Colin Law wrote:
> On Tue, 16 Jul 2019 at 19:08, Jaroslav Sobota <js...@kk...> wrote:
>>
>> Creating config file /etc/owfs.conf with new version
>> Setting up libow-3.2-3:armhf (3.2p3+dfsg1-2) ...
>> Setting up owserver (3.2p3+dfsg1-2) ...
>> Job for owserver.service failed because the service did not take the
>> steps requi                                              red by its unit
>> configuration.
>> See "systemctl status owserver.service" and "journalctl -xe" for details.
> 
> Not certain, but I think it installed ok, but failed to start.  Did
> you run the commands suggested to see what it says?  Perhaps you just
> need to setup the config properly.
> 
> Colin
> 
> 
> _______________________________________________
> Owfs-developers mailing list
> Owf...@li...
> https://lists.sourceforge.net/lists/listinfo/owfs-developers
> 

Re: [Owfs-developers] I just downloaded the OWFS source code from the new GIT location...

[Gregg L. <gre...@gm...>]

Hello!
I'd be delighted to do so, except all I have is what I stated above,
and perhaps the responses (as idiotic as they are) from Norton itself.
I also followed the same steps to download a new GIT blob onto a
folder on a Raspberry Pi to which I'd previously gotten OWFS to work
that way. I've since compressed it into a TAR file which was also
BZIP2 compressed.

Depending on what your response is, I'll retrieve it and try again.
This time extracting that over what is already there.

Can you tell me, also, if there where any commits to the directory recently?
-----
Gregg C Levine gre...@gm...
"This signature fought the Time Wars, time and again."

On Wed, Jul 17, 2019 at 1:22 PM Stefano Miccoli via Owfs-developers
<owf...@li...> wrote:
>
> Can you please open an issue at https://github.com/owfs/owfs/issues with more details?
>
> SM
>
>
> On 16 Jul 2019, at 01:34, Gregg Levine <gre...@gm...> wrote:
>
> Hello!
> Okay I found and downloaded the OWS source code from the new GIT
> location. But during the process of doing that, I found that Norton
> insisted that there was a Trojan hiding in the VB example of one of
> the OWFS programs. I am convinced that this is a rare false positive
> for the Norton antivirus program.
>
> Incidentally this was downloaded onto a Linux on Windows instance
> which is posing as SuSe SLES 12 server when running. I've built and
> run the latest release on it and actually gotten it to work.
> -----
> Gregg C Levine gre...@gm...
> "This signature fought the Time Wars, time and again."
>
>
> _______________________________________________
> Owfs-developers mailing list
> Owf...@li...
> https://lists.sourceforge.net/lists/listinfo/owfs-developers
>
>
> _______________________________________________
> Owfs-developers mailing list
> Owf...@li...
> https://lists.sourceforge.net/lists/listinfo/owfs-developers

Re: [Owfs-developers] I just downloaded the OWFS source code from the new GIT location...

[Stefano M. <mo...@ic...>]

Can you please open an issue at https://github.com/owfs/owfs/issues <https://github.com/owfs/owfs/issues> with more details?

SM


> On 16 Jul 2019, at 01:34, Gregg Levine <gre...@gm...> wrote:
> 
> Hello!
> Okay I found and downloaded the OWS source code from the new GIT
> location. But during the process of doing that, I found that Norton
> insisted that there was a Trojan hiding in the VB example of one of
> the OWFS programs. I am convinced that this is a rare false positive
> for the Norton antivirus program.
> 
> Incidentally this was downloaded onto a Linux on Windows instance
> which is posing as SuSe SLES 12 server when running. I've built and
> run the latest release on it and actually gotten it to work.
> -----
> Gregg C Levine gre...@gm...
> "This signature fought the Time Wars, time and again."
> 
> 
> _______________________________________________
> Owfs-developers mailing list
> Owf...@li...
> https://lists.sourceforge.net/lists/listinfo/owfs-developers

Re: [Owfs-developers] Problem installing owserver on Raspbian Buster

[Colin L. <cl...@gm...>]

On Tue, 16 Jul 2019 at 19:08, Jaroslav Sobota <js...@kk...> wrote:
>
> Creating config file /etc/owfs.conf with new version
> Setting up libow-3.2-3:armhf (3.2p3+dfsg1-2) ...
> Setting up owserver (3.2p3+dfsg1-2) ...
> Job for owserver.service failed because the service did not take the
> steps requi                                              red by its unit
> configuration.
> See "systemctl status owserver.service" and "journalctl -xe" for details.

Not certain, but I think it installed ok, but failed to start.  Did
you run the commands suggested to see what it says?  Perhaps you just
need to setup the config properly.

Colin

[Owfs-developers] Problem installing owserver on Raspbian Buster

[Jaroslav S. <js...@kk...>]

Hi,
I tried installing owserver on the newest Raspbian Buster and I got 
post-installation error. See below for output.

I'm using RPi4 (also RPi 3B+ with the same result), Raspbian Lite and I 
haven't touched the default APT sources. Has anyone encountered the 
same? Is there a way to fix this (preferably in Raspbian image)?

Thank you.

With kind regards,
Jaroslav

pi@raspberrypi:~ $ sudo apt install owserver
Reading package lists... Done
Building dependency tree
Reading state information... Done
The following additional packages will be installed:
   libavahi-client3 libftdi1-2 libow-3.2-3 owfs-common
The following NEW packages will be installed:
   libavahi-client3 libftdi1-2 libow-3.2-3 owfs-common owserver
0 upgraded, 5 newly installed, 0 to remove and 0 not upgraded.
Need to get 399 kB of archives.
After this operation, 1,285 kB of additional disk space will be used.
Do you want to continue? [Y/n] y
Get:1 http://mirror.dkm.cz/raspbian/raspbian buster/main armhf 
libavahi-client3                                               armhf 
0.7-4+b1 [54.0 kB]
Get:2 http://mirror.dkm.cz/raspbian/raspbian buster/main armhf 
libftdi1-2 armhf                                               1.4-1+b2 
[27.7 kB]
Get:3 http://mirror.dkm.cz/raspbian/raspbian buster/main armhf 
owfs-common all 3 .2p3+dfsg1-2 [17.6 kB]
Get:4 http://mirror.dkm.cz/raspbian/raspbian buster/main armhf 
libow-3.2-3 armhf 3.2p3+dfsg1-2 [269 kB]
Get:5 http://mirror.dkm.cz/raspbian/raspbian buster/main armhf owserver 
armhf 3.                                              2p3+dfsg1-2 [30.8 kB]
Fetched 399 kB in 1s (469 kB/s)
Selecting previously unselected package libavahi-client3:armhf.
(Reading database ... 37620 files and directories currently installed.)
Preparing to unpack .../libavahi-client3_0.7-4+b1_armhf.deb ...
Unpacking libavahi-client3:armhf (0.7-4+b1) ...
Selecting previously unselected package libftdi1-2:armhf.
Preparing to unpack .../libftdi1-2_1.4-1+b2_armhf.deb ...
Unpacking libftdi1-2:armhf (1.4-1+b2) ...
Selecting previously unselected package owfs-common.
Preparing to unpack .../owfs-common_3.2p3+dfsg1-2_all.deb ...
Unpacking owfs-common (3.2p3+dfsg1-2) ...
Selecting previously unselected package libow-3.2-3:armhf.
Preparing to unpack .../libow-3.2-3_3.2p3+dfsg1-2_armhf.deb ...
Unpacking libow-3.2-3:armhf (3.2p3+dfsg1-2) ...
Selecting previously unselected package owserver.
Preparing to unpack .../owserver_3.2p3+dfsg1-2_armhf.deb ...
Unpacking owserver (3.2p3+dfsg1-2) ...
Setting up libftdi1-2:armhf (1.4-1+b2) ...
Setting up libavahi-client3:armhf (0.7-4+b1) ...
Setting up owfs-common (3.2p3+dfsg1-2) ...

Creating config file /etc/owfs.conf with new version
Setting up libow-3.2-3:armhf (3.2p3+dfsg1-2) ...
Setting up owserver (3.2p3+dfsg1-2) ...
Job for owserver.service failed because the service did not take the 
steps requi                                              red by its unit 
configuration.
See "systemctl status owserver.service" and "journalctl -xe" for details.
invoke-rc.d: initscript owserver, action "start" failed.
● owserver.service - Backend server for 1-wire control
    Loaded: loaded (/lib/systemd/system/owserver.service; disabled; 
vendor preset                                              : enabled)
    Active: activating (auto-restart) (Result: protocol) since Tue 
2019-07-16 16:                                              35:38 BST; 
25ms ago
      Docs: man:owserver(1)
   Process: 1104 ExecStart=/usr/bin/owserver -c /etc/owfs.conf 
(code=exited, stat us=0/SUCCESS)
  Main PID: 1104 (code=exited, status=0/SUCCESS)
dpkg: error processing package owserver (--configure):
  installed owserver package post-installation script subprocess 
returned error e                                              xit status 1
Processing triggers for man-db (2.8.5-2) ...
Processing triggers for libc-bin (2.28-10+rpi1) ...
Processing triggers for systemd (241-5+rpi1) ...
Errors were encountered while processing:
  owserver
E: Sub-process /usr/bin/dpkg returned an error code (1)

[Owfs-developers] Hurray! owfs.org is back!

[Nico B. <ni...@cu...>]

Maybe allready noticed is website is back...

My question is now, leave it like this or shall i make a fresh start?

Nico

Re: [Owfs-developers] DS18S20 fault again

[Colin L. <cl...@gm...>]

On Mon, 15 Jul 2019 at 21:49, Jan Kandziora <jj...@gm...> wrote:
> ...
> The DS18S20 has 9 bit accuracy only, while the DS18B20 supports 12 bit
> accuracy.

i think that should be 9/12 bits resolution rather than accuracy.  I
don't think the accuracy is affected.  They are both +-0.5C

Colin

[Owfs-developers] I just downloaded the OWFS source code from the new GIT location...

[Gregg L. <gre...@gm...>]

Hello!
Okay I found and downloaded the OWS source code from the new GIT
location. But during the process of doing that, I found that Norton
insisted that there was a Trojan hiding in the VB example of one of
the OWFS programs. I am convinced that this is a rare false positive
for the Norton antivirus program.

Incidentally this was downloaded onto a Linux on Windows instance
which is posing as SuSe SLES 12 server when running. I've built and
run the latest release on it and actually gotten it to work.
-----
Gregg C Levine gre...@gm...
"This signature fought the Time Wars, time and again."

Re: [Owfs-developers] DS18S20 fault again

[Jan K. <jj...@gm...>]

Am 15.07.19 um 22:03 schrieb Mick Sulley:
>
> latesttemp 127.688    8.875    -1.5    127.688
>
> temperature 24.9375    24.0625    23.5625    23.375
>
> So temperature is about right, but latesttemp is wildly out.  I always
> thought that latesttemp was derived from temperature, temperature9,
> temperature10, temperature11, temperature12 on a DS18B20 and just from
> temperature on a DS18S20, but that is not what I am seeing here.
>
Reading

	/uncached/<id>/latesttemp

reads the sampled temperature value from the scratchpad register on the
DS1820 chip while reading

	/uncached/<id>/temperature

will first initiate a new temperature conversion, then read the sampled
temperature value from the scratchpad register on the DS1820 chip.

The latesttemp nodes are meant for use in conjuction with the
/simultaneous/temperature nodes. Trigger those once for all chips,  read
the results from latesttemp on each chip one second later.


If you skip the /uncached part, you read from OWFS's internal cache
instead. Only if the cached value is considered as too old by OWFS, it
does the same operation as the /uncached variant.

The cache is updated in any case, but only for that single node read.


> I have always considered the DS18S20 and DS18B20 to be similar enough to
> not really prefer one over the other.  Is that true or is one better in
> terms of accuracy, reliability or any other factor?
>
These are binned variants of the same chip.

The DS18S20 has 9 bit accuracy only, while the DS18B20 supports 12 bit
accuracy.

Kind regards

	Jan

[Owfs-developers] DS18S20 fault again

[Mick S. <mi...@su...>]

I just had another DS18S20 sensor giving me strange readings, but this 
time it was fairly easy to access, so I was able to physically feel how 
hot it was.

My web page is based upon the latesttemp value.  The pipe it measures 
would be at around 25 degrees give or take a bit.  I saw it go to over 
50 degrees and so removed the insulation and a finger test on the sensor 
showed the expected 25 or so.  I took some screenshots of the owhttpd 
screen over about 2 minutes.

The screenshots show

latesttemp 127.688    8.875    -1.5    127.688

temperature 24.9375    24.0625    23.5625    23.375

So temperature is about right, but latesttemp is wildly out.  I always 
thought that latesttemp was derived from temperature, temperature9, 
temperature10, temperature11, temperature12 on a DS18B20 and just from 
temperature on a DS18S20, but that is not what I am seeing here.

I have always considered the DS18S20 and DS18B20 to be similar enough to 
not really prefer one over the other.  Is that true or is one better in 
terms of accuracy, reliability or any other factor?

Thanks

Mick

Re: [Owfs-developers] bus interface statistics

[Jan K. <jj...@gm...>]

Am 13.07.19 um 22:36 schrieb Mick Sulley:
>
> One other thought, I have separate power supplies for 1-wire and the
> Pi.  Can I just power cycle the 1-wire adapter and leave the Pi running?
>
It's only ever neccessary to power-cycle the DS2482-800.

I found a problem related to spurious bus shorts and the DS2482-800 just
a few days ago in a customer's equipment. Power-cycling the DS2482-800
fixed it each time.

So I kept plugging in iButton locks and keys until I had the culprit
which put the DS2482-800 into coma. Replaced it – all ok now.

(Note: Some types of iButton locks are prone to short-circuit. The
DS2482-800 does not like it at all.)

Kind regards

	Jan

Re: [Owfs-developers] bus interface statistics

[Colin R. <col...@gm...>]

Lowpowerlab sells some nice power management boards that use an Uno clone. Good support, lots of existing code. 

C

> On Jul 14, 2019, at 03:15, Stefano Miccoli via Owfs-developers <owf...@li...> wrote:
> 
> 
> 
>> On 13 Jul 2019, at 22:36, Mick Sulley <mi...@su...> wrote:
>> 
>> Thank you both for your input.  I agree, I do not like the scheduled power cycle option either and I continue to look for the root cause of the issue.
>> 
> Let me add just a few more comments: 100% reliability is of course not possible, therefore a watchdog timer may still be useful.
>> The reason I considered a scheduled power cycle is that it seems that after a power cycle I do not see any errors, then over a few days or weeks I start to see errors, 85 reads, device not found, etc and then I get a lockup, although the timing is very variable.
>> 
> If you experience a system degradation before lockup, then you can setup a daemon that monitors the 1-wire vitals, and eventually restarts the system when some threshold value is reached.
>> I do have heartbeat file which is monitored by another machine, so I will look at using that to power cycle it.
>> 
> The RPi chip has an hardware watchdog timer, which you can access via /dev/watchdog. Unfortunately the RPi is not able to power cycle itself, but only to reset, so some external board/system is needed to power-cycle the RPi.
>> One other thought, I have separate power supplies for 1-wire and the Pi.  Can I just power cycle the 1-wire adapter and leave the Pi running?
>> 
> I have no experience with the DS2482-800 and with HW design, but I understand that you have to power-cycle the 1-wire adapter, no need to cold reboot the RPi host. But maybe I’m mistaken here.
> 
> S.
> 
>> 
>>> On 13/07/2019 19:58, Stefano Miccoli via Owfs-developers wrote:
>>> 
>>> 
>>>> On 11 Jul 2019, at 23:10, Mick Sulley <mi...@su...> wrote:
>>>> 
>>>> The reason for the question is that I still have random bus lockups and I am considering creating something to power cycle the system, either on a time basis, e.g. 3am each day, or based on some early warning detection from the data in interface/statistics if that is possible.
>>>> 
>>>> Does anyone have an opinion on scheduled power cycle?  Good idea or not?
>>> 
>>> This make sense only if you are sure that the bus lockups are **not** random, but somehow occur only after some time has elapsed from the last power cycle, and this time is longer than one day.
>>> 
>>> On the contrary if the lookups are truly random, then a reboot every 24h just ensures that the longest down-time is less than 24h. If it is impossible to avoid random lookups then the most sensible solution would be a watchdog timer. This way you  can ensure that bus down time is shorter that the watchdog time interval itself.
>>> 
>>> Stefano
>>> 
>>> 
>>> 
>>> _______________________________________________
>>> Owfs-developers mailing list
>>> Owf...@li...
>>> https://lists.sourceforge.net/lists/listinfo/owfs-developers
>> _______________________________________________
>> Owfs-developers mailing list
>> Owf...@li...
>> https://lists.sourceforge.net/lists/listinfo/owfs-developers
> 
> _______________________________________________
> Owfs-developers mailing list
> Owf...@li...
> https://lists.sourceforge.net/lists/listinfo/owfs-developers

Re: [Owfs-developers] bus interface statistics

[Stefano M. <mo...@ic...>]

> On 13 Jul 2019, at 22:36, Mick Sulley <mi...@su...> wrote:
> 
> Thank you both for your input.  I agree, I do not like the scheduled power cycle option either and I continue to look for the root cause of the issue.
> 
Let me add just a few more comments: 100% reliability is of course not possible, therefore a watchdog timer may still be useful.
> The reason I considered a scheduled power cycle is that it seems that after a power cycle I do not see any errors, then over a few days or weeks I start to see errors, 85 reads, device not found, etc and then I get a lockup, although the timing is very variable.
> 
If you experience a system degradation before lockup, then you can setup a daemon that monitors the 1-wire vitals, and eventually restarts the system when some threshold value is reached.
> I do have heartbeat file which is monitored by another machine, so I will look at using that to power cycle it.
> 
The RPi chip has an hardware watchdog timer, which you can access via /dev/watchdog. Unfortunately the RPi is not able to power cycle itself, but only to reset, so some external board/system is needed to power-cycle the RPi.
> One other thought, I have separate power supplies for 1-wire and the Pi.  Can I just power cycle the 1-wire adapter and leave the Pi running?
> 
I have no experience with the DS2482-800 and with HW design, but I understand that you have to power-cycle the 1-wire adapter, no need to cold reboot the RPi host. But maybe I’m mistaken here.

S.

> 
> On 13/07/2019 19:58, Stefano Miccoli via Owfs-developers wrote:
>> 
>> 
>>> On 11 Jul 2019, at 23:10, Mick Sulley <mi...@su... <mailto:mi...@su...>> wrote:
>>> 
>>> The reason for the question is that I still have random bus lockups and I am considering creating something to power cycle the system, either on a time basis, e.g. 3am each day, or based on some early warning detection from the data in interface/statistics if that is possible.
>>> 
>>> Does anyone have an opinion on scheduled power cycle?  Good idea or not?
>> 
>> This make sense only if you are sure that the bus lockups are **not** random, but somehow occur only after some time has elapsed from the last power cycle, and this time is longer than one day.
>> 
>> On the contrary if the lookups are truly random, then a reboot every 24h just ensures that the longest down-time is less than 24h. If it is impossible to avoid random lookups then the most sensible solution would be a watchdog timer. This way you  can ensure that bus down time is shorter that the watchdog time interval itself.
>> 
>> Stefano
>> 
>> 
>> 
>> _______________________________________________
>> Owfs-developers mailing list
>> Owf...@li... <mailto:Owf...@li...>
>> https://lists.sourceforge.net/lists/listinfo/owfs-developers <https://lists.sourceforge.net/lists/listinfo/owfs-developers>
> _______________________________________________
> Owfs-developers mailing list
> Owf...@li...
> https://lists.sourceforge.net/lists/listinfo/owfs-developers

Re: [Owfs-developers] bus interface statistics

[Mick S. <mi...@su...>]

Thank you both for your input.  I agree, I do not like the scheduled 
power cycle option either and I continue to look for the root cause of 
the issue.

The reason I considered a scheduled power cycle is that it seems that 
after a power cycle I do not see any errors, then over a few days or 
weeks I start to see errors, 85 reads, device not found, etc and then I 
get a lockup, although the timing is very variable.

I do have heartbeat file which is monitored by another machine, so I 
will look at using that to power cycle it.

One other thought, I have separate power supplies for 1-wire and the 
Pi.  Can I just power cycle the 1-wire adapter and leave the Pi running?


On 13/07/2019 19:58, Stefano Miccoli via Owfs-developers wrote:
>
>
>> On 11 Jul 2019, at 23:10, Mick Sulley <mi...@su... 
>> <mailto:mi...@su...>> wrote:
>>
>> The reason for the question is that I still have random bus lockups 
>> and I am considering creating something to power cycle the system, 
>> either on a time basis, e.g. 3am each day, or based on some early 
>> warning detection from the data in interface/statistics if that is 
>> possible.
>>
>> Does anyone have an opinion on scheduled power cycle?  Good idea or not?
>
> This make sense only if you are sure that the bus lockups are **not** 
> random, but somehow occur only after some time has elapsed from the 
> last power cycle, and this time is longer than one day.
>
> On the contrary if the lookups are truly random, then a reboot every 
> 24h just ensures that the longest down-time is less than 24h. If it is 
> impossible to avoid random lookups then the most sensible solution 
> would be a watchdog timer. This way you  can ensure that bus down time 
> is shorter that the watchdog time interval itself.
>
> Stefano
>
>
> _______________________________________________
> Owfs-developers mailing list
> Owf...@li...
> https://lists.sourceforge.net/lists/listinfo/owfs-developers

Re: [Owfs-developers] bus interface statistics

[Stefano M. <mo...@ic...>]

> On 11 Jul 2019, at 23:10, Mick Sulley <mi...@su...> wrote:
> 
> The reason for the question is that I still have random bus lockups and I am considering creating something to power cycle the system, either on a time basis, e.g. 3am each day, or based on some early warning detection from the data in interface/statistics if that is possible.
> 
> Does anyone have an opinion on scheduled power cycle?  Good idea or not?

This make sense only if you are sure that the bus lockups are **not** random, but somehow occur only after some time has elapsed from the last power cycle, and this time is longer than one day.

On the contrary if the lookups are truly random, then a reboot every 24h just ensures that the longest down-time is less than 24h. If it is impossible to avoid random lookups then the most sensible solution would be a watchdog timer. This way you  can ensure that bus down time is shorter that the watchdog time interval itself.

Stefano

Re: [Owfs-developers] bus interface statistics

[Jan K. <jj...@gm...>]

Am 11.07.19 um 23:10 schrieb Mick Sulley:
> Looking at my system via owhttpd at top level I can see all the devices
> and some other things -
>
> bus.0 seems to mean the bus structure, so in there I can see bus.0 to
> bus.7  In each of these I see just the devices on that bus plus
> interface, simultaneous and alarm, and drilling down into
> interface/statistics there is more data
>
bus.0 to bus.7 may be the channels of a single DS2482-800, or they may
be a mix of individual adapters or owservers connected.

You may find bus.4/bus.6 for channel #6 of an DS2482-800 at the owserver
listed as bus.4. As owservers may connect to other owservers, there may
be even more levels.


> Is there any documentation on the data in there?
>
The manpages! See e.g.
https://packages.debian.org/de/sid/all/owfs-doc/filelist for a list of
typical installation pathes.


> The reason for the question is that I still have random bus lockups and
> I am considering creating something to power cycle the system, either on
> a time basis, e.g. 3am each day, or based on some early warning
> detection from the data in interface/statistics if that is possible.
>
> Does anyone have an opinion on scheduled power cycle?  Good idea or not?
>
The DS2482-800 is known to be susceptible to dips in its power sluppy.
Depending on your setup, it may be also susceptible to shorts on any of
the Onewire channels (because they affect the power supply of the
DS2482-800). The only known way to get the chip out of this unuseable
mode is power-cycling it.

One short dip is enough. There is no warning.

I would rather find the source of the power supply problems or shorts
than applying a crude fix.

The other option is not using the DS2482-800 but several DS2483 instead.

Kind regards

	Jan

[Owfs-developers] bus interface statistics

[Mick S. <mi...@su...>]

Looking at my system via owhttpd at top level I can see all the devices 
and some other things -

bus.0 seems to mean the bus structure, so in there I can see bus.0 to 
bus.7  In each of these I see just the devices on that bus plus 
interface, simultaneous and alarm, and drilling down into 
interface/statistics there is more data

Is there any documentation on the data in there?

The reason for the question is that I still have random bus lockups and 
I am considering creating something to power cycle the system, either on 
a time basis, e.g. 3am each day, or based on some early warning 
detection from the data in interface/statistics if that is possible.

Does anyone have an opinion on scheduled power cycle?  Good idea or not?

Thanks

Mick

[Owfs-developers] DS2483/DS2482 python help

[Colin R. <col...@gm...>]

Hello all,

This a bit of a hail mary, and not 100% germane to the group, but I 
figured that at least a few of you here may have enough relevant 
knowledge to point me somewhere helpful.

I am attempting to communicate with a DS2483 bus master from an ESP32 
using micropython, and having some difficulty at early stages. 
Specifically, I seem to always return a status register that says that 
the bus is busy, there are devices present, and sometimes that there is 
a bus short (status bytes of 0x1f and 0x1b).

If anybody can provide any input or resources on hunting this down (or 
test code for a Pi, using SMBus or otherwise), or ideas on how to better 
implement this (by porting C directly for example), I would be 
infinitely grateful. Please feel free to contact me off-list.

Kind regards,
Colin

Re: [Owfs-developers] DS18S20 fault Question

[Henrik Ö. <tr...@gm...>]

@Matthias
Would you add a capacitor per sensor or for the whole bus?
My bus is quite stable, but I'm always trying to make it more stable. :-)

Den ons 19 juni 2019 kl 13:53 skrev Matthias Urlichs via Owfs-developers <
owf...@li...>:

> On 19.06.19 13:03, Mick Sulley wrote:
> > Yes all of my sensors are powered.
>
> In that case, my next step would be to replace the "hot" sensor.
>
> For added peace-of-mind, I'd also add a small capacitor (100nF or so)
> between Vcc and GND.
>
> --
> -- mit freundlichen Grüßen
> --
> -- Matthias Urlichs
>
>
>
> _______________________________________________
> Owfs-developers mailing list
> Owf...@li...
> https://lists.sourceforge.net/lists/listinfo/owfs-developers
>

Re: [Owfs-developers] DS18S20 fault Question

[Matthias U. <mat...@ur...>]

On 19.06.19 13:03, Mick Sulley wrote:
> Yes all of my sensors are powered.

In that case, my next step would be to replace the "hot" sensor.

For added peace-of-mind, I'd also add a small capacitor (100nF or so)
between Vcc and GND.

-- 
-- mit freundlichen Grüßen
-- 
-- Matthias Urlichs

Re: [Owfs-developers] DS18S20 fault Question

[Mick S. <mi...@su...>]

Yes all of my sensors are powered.  I will do more investigation.  
Thanks for the comments

On 19/06/2019 09:19, Matthias Urlichs via Owfs-developers wrote:
> On 19.06.19 09:39, Jan Kandziora wrote:
>> The 1W host has to supply current to the 1W line to power all the
>> parasitic powered slave devices.
> Well, the solution is to not parasitically power anything.
>
> Of course you can't do that with DS2401 switches or iButtons, but the
> other 1wire ICs have Vcc pins for a reason.
>