Re: [Owfs-developers] bus interface statistics

[Colin Reese]

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 
>  wrote:
> 
> 
> 
>> On 13 Jul 2019, at 22:36, Mick Sulley  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  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
>>> Owfs-developers@lists.sourceforge.net
>>> https://lists.sourceforge.net/lists/listinfo/owfs-developers
>> ___
>> Owfs-developers mailing list
>> Owfs-developers@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/owfs-developers
> 
> ___
> Owfs-developers mailing list
> Owfs-developers@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/owfs-developers
___
Owfs-developers mailing list
Owfs-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/owfs-developers

[Owfs-developers] DS2483/DS2482 python help

[Colin Reese]

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


___
Owfs-developers mailing list
Owfs-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/owfs-developers

Re: [Owfs-developers] owfs.org expired?

[Colin Reese]

Somewhat related to the python conversation -- has anyone considered a 
light-weight owfs for micropython? Or at least porting the C and python 
bindings? The onewire support on micropython is about where arduino 
was/is in its infancy. I'm in a place right now where I need to write 
functions for things besides the boilerplate DS18X20 you often find. I'm 
 about to write from scratch but thought that someone might have 
already started down this path.


C

On 5/25/2019 12:16 AM, Nico Bouthoorn via Owfs-developers wrote:
Meanwhile i've updated https://onewirefilesystem.org/ a little bit, as 
an copy of owfs.org.  Work in progress.


I've bought the Rasberry with the 1-wire interface (couldn't resist) . 
I've made  documentation, it works very, i've placed the R. pi in garden 
in a greenhouse the measure temperature via wifi: 
https://onewirefilesystem.org/raspberry-pi


Nico

Johan Ström wrote:

FYI, I have not received any update on this yet.

On 2019-05-17 10:41, Johan Ström wrote:
I have received a screenshot from Mike showing that he had the 
possibility to renew the expired domain. According to enom's FAQ it 
should be possible to perform a transfer of expired domain, but it 
must go through their support who can provide the transfer code.

So, I have asked Mike if he could do that. Waiting for reply.

Johan
--
Sent from my Android device with K-9 Mail. Please excuse my brevity.

On May 17, 2019 9:03:41 AM GMT+02:00, Nico Bouthoorn via 
Owfs-developers  wrote:


    I don't want to push it, but has someone (Mike) look into it 
about the expiring of the owfs.org domain?
    I wil take care of it if somen give me the domain transfer 
code.   If you don't trust me, we can store it in a common  place/safe.


    Nico

-- 


    Owfs-developers mailing list
    Owfs-developers@lists.sourceforge.net
    https://lists.sourceforge.net/lists/listinfo/owfs-developers



___
Owfs-developers mailing list
Owfs-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/owfs-developers





___
Owfs-developers mailing list
Owfs-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/owfs-developers





___
Owfs-developers mailing list
Owfs-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/owfs-developers

Re: [Owfs-developers] owfs.org is down

[Colin Reese]

Who has the login info for the registrar account? I’d guess it can be 
reactivated. 

C

> On May 2, 2019, at 00:02, Nico Bouthoorn  wrote:
> 
> The dropbox link is not valid anymore.
> 
> Nico
> 
> Johan Ström schreef:
>> The old whois information:
>> https://github.com/owfs/owfs/issues/35#issuecomment-480738656
>> Interestingly enough it seems to be the same if I do a whois right now,
>> and Registry expiration date is May 13th?
>> As for the contents, Mike has previously posted a dropbox link with a
>> full raw dump (mysql db + php files + alot of other things) of the site.
>> Perhaps it held some secret passwords which have now been used to "take
>> over" the site, in case the domain isn't actually expired yet?
>> Johan
>>> On 2019-05-02 08:41, Nico Bouthoorn via Owfs-developers wrote:
>>> owfs.info and owfs.it forexample  is still free, owfs.io also but
>>> expensive.  i can registrar a domain.   If someone still has the
>>> content of the old webiste?
>>> 
>>> Nico
>>> 
>>> Colin Reese schreef:
>>>> Who was the registrar?
>>>> 
>>>>> On May 1, 2019, at 23:19, Nico Bouthoorn via Owfs-developers
>>>>>  wrote:
>>>>> 
>>>>> Thats a pitty... i volunteered
>>>>> 
>>>>> Matthias Urlichs via Owfs-developers schreef:
>>>>>>> On 01.05.19 10:38, Nico Bouthoorn via Owfs-developers wrote:
>>>>>>> Who owns the domains now?, it looks like it has nothing todo with
>>>>>>> owfs
>>>>>>> anymore.
>>>>>> Owch. Typical domain grabbing idiocy. We should have transferred it
>>>>>> before it expired. :-(
>>>>>> Reasonable registrars block new registrations for a time to allow the
>>>>>> domain to be transferred by the legit owner …
>>>>>> I can look into contesting that registration, though "owfs" isn't a
>>>>>> registered trademark or anything AFAIK, thus chances are slim.
>>>>> 
>>>>> -- 
>>>>> 0623391101
>>>>> 
>>>>> 
>>>>> ___
>>>>> Owfs-developers mailing list
>>>>> Owfs-developers@lists.sourceforge.net
>>>>> https://lists.sourceforge.net/lists/listinfo/owfs-developers
>>> 
> 
> -- 
> 0623391101


___
Owfs-developers mailing list
Owfs-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/owfs-developers

Re: [Owfs-developers] owfs.org is down

[Colin Reese]

Who was the registrar?

> On May 1, 2019, at 23:19, Nico Bouthoorn via Owfs-developers 
>  wrote:
> 
> Thats a pitty... i volunteered
> 
> Matthias Urlichs via Owfs-developers schreef:
>>> On 01.05.19 10:38, Nico Bouthoorn via Owfs-developers wrote:
>>> Who owns the domains now?, it looks like it has nothing todo with owfs
>>> anymore.
>> Owch. Typical domain grabbing idiocy. We should have transferred it
>> before it expired. :-(
>> Reasonable registrars block new registrations for a time to allow the
>> domain to be transferred by the legit owner …
>> I can look into contesting that registration, though "owfs" isn't a
>> registered trademark or anything AFAIK, thus chances are slim.
> 
> -- 
> 0623391101
> 
> 
> ___
> Owfs-developers mailing list
> Owfs-developers@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/owfs-developers


___
Owfs-developers mailing list
Owfs-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/owfs-developers

Re: [Owfs-developers] Suggestions of Microcontrollers for 1-wire use.

[Colin Reese]

In response to the wired ethernet issue :

https://www.olimex.com/Products/IoT/ESP32/ESP32-GATEWAY/open-source-hardware

https://www.digikey.com/product-detail/en/olimex-ltd/ESP32-EVB/1188-1177-ND/6580749&?gclid=EAIaIQobChMI8t2Q5N_O4AIV_yCtBh0rgQhgEAQYASABEgJdUPD_BwE

All those Pi clones will have the same problems with much less support than a 
Pi. 

C

> On Feb 21, 2019, at 19:53, Gregg Levine  wrote:
> 
> Hello!
> it is interesting that you mention OpenWRT in this context. Early in
> the cycles regarding OWFS one of us got it to work on an appropriately
> configured WRT54GL router. That meant following a website's
> instructions to open the rig and find and attach to it the two serial
> ports it needs to continue.
> 
> Oh and that also includes constructing the adapters needed to
> translate the 3,.3V logic levels on the Router board to the RS232
> levels need to make the serial adapters work.
> 
> To find out more simply instruct Google to search for WRT54G serial
> port and there you are.
> 
> I don't wear the List Manager's hat here, but I find this extremely
> interesting, and will support it.
> -
> Gregg C Levine gregg.drw...@gmail.com
> "This signature fought the Time Wars, time and again."
>> On Thu, Feb 21, 2019 at 6:18 PM Alastair D'Silva  
>> wrote:
>> 
>> I'll throw in my $0.02 too...
>> 
>> I was of the opinion that it would be awesome to have an owserver
>> implementation for the ESP, but now that supercheap Linux SBCs such
>> as the Orange Pi Zero, Nanopi Neo, etc are available, it's hard to make
>> that argument based on hardware cost, especially if you need ethernet
>> rather than Wifi.
>> 
>> It's also hard to make the argument based on power, we measured an
>> underclocked Allwinner H3 at 0.25W (with the GPU disabled).
>> 
>> My current position now is that a cheap SBC takes all the software
>> effort away, and the write wear issue can be solved either by
>> netbooting or using a readonly root filesystem - Buildroot & OpenWRT
>> are both good choices to build this.
>> 
>> --
>> Alastair D'Silva   mob: 0423 762 819
>> skype: alastair_dsilva
>> Twitter: @EvilDeece
>> blog: http://alastair.d-silva.org
>> 
>> 
>> On Thu, 2019-02-21 at 23:54 +0100, Stefano Miccoli via Owfs-developers
>> wrote:
>>> Quite an interesting discussion, please forgive me if I throw in my
>>> 1cent.
>>> 
>>> We should not forget that normal RPis are educational boards, not
>>> meant for professional use. OS on a SD is a terrible idea, with
>>> regard to card corruption, but at least it is *impossible* to brick
>>> your board. Something wrong? just swap SDs and start over…  I think
>>> that this is a key point for educational/hobby use.
>>> 
>>> For industrial application there is the compute module <
>>> https://www.raspberrypi.org/products/compute-module-3/>;, with up to
>>> 32GB  eMMC, and, as already mentioned, newer RPis can boot from USB
>>> but also from network. If you are familiar with setting up a DHCP,
>>> TFTP, NFS server, you can also try a fully storage less network
>>> client setup. (Of course this makes sense if you are going to deploy
>>> a cluster of at least five RPis. But with a reasonable server and
>>> network this easily scales up to tens of nodes.)
>>> 
>>> However the main point, in my opinion, is that for most application
>>> you do not need the power of a full fledged linux system-on-chip
>>> (with 8GB+ storage, 1GB ram, 4 cores, GPU, hdmi port, ethernet, etc.)
>>> Moreover linux systems need administration and security updates, etc.
>>> so for a great number of applications it is just over kill.
>>> 
>>> So if you are not going to use the distributed “intelligence” and
>>> compute power sleeping in your SOC nodes, the µcontroller is for sure
>>> the way to go.
>>> 
>>> Stefano
>>> 
>>>> On 21 Feb 2019, at 06:29, Colin Reese 
>>>> wrote:
>>>> 
>>>> Joe,
>>>> 
>>>> I transitioned from Pis to ESP32. I was all-in on Pis, trust me. I
>>>> love linux. The issues:
>>>> 
>>>> It's not just the power supply. SDCards in this environment will
>>>> corrupt eventually, absolutely. There is nothing that can protect
>>>> the operating system from eventual corruption. Yes, I too, have
>>>> been lucky and had them run for years. You simply cannot count on
>>>> this with consumer-grade sd cards. You can buy industri

Re: [Owfs-developers] Suggestions of Microcontrollers for 1-wire use.

[Colin Reese]

Agreed on all of this. 

Even eMMC is susceptible to FS corruption due to no protection of the write 
cycle at unexpected power down. It is an issue that needs to be addressed. 
Meanwhile, my micros just don’t ever die. Even if they do, i can preconfigure 
one, throw it in the mail, and it’s a five minute swap out. 

My rationale for a standalone Linux box was manifold, but the crux was that not 
all devices live on the internet constantly, and being able to pull databases 
periodically and/or view it without WAN access seemed like a pretty reasonable 
endeavor. I’m pretty over that. It’s a minuscule fraction of application cases 
I can live without (or use GSM). 

C

> On Feb 21, 2019, at 14:54, Stefano Miccoli via Owfs-developers 
>  wrote:
> 
> Quite an interesting discussion, please forgive me if I throw in my 1cent.
> 
> We should not forget that normal RPis are educational boards, not meant for 
> professional use. OS on a SD is a terrible idea, with regard to card 
> corruption, but at least it is *impossible* to brick your board. Something 
> wrong? just swap SDs and start over…  I think that this is a key point for 
> educational/hobby use. 
> 
> For industrial application there is the compute module 
> <https://www.raspberrypi.org/products/compute-module-3/>, with up to 32GB  
> eMMC, and, as already mentioned, newer RPis can boot from USB but also from 
> network. If you are familiar with setting up a DHCP, TFTP, NFS server, you 
> can also try a fully storage less network client setup. (Of course this makes 
> sense if you are going to deploy a cluster of at least five RPis. But with a 
> reasonable server and network this easily scales up to tens of nodes.)
> 
> However the main point, in my opinion, is that for most application you do 
> not need the power of a full fledged linux system-on-chip (with 8GB+ storage, 
> 1GB ram, 4 cores, GPU, hdmi port, ethernet, etc.) Moreover linux systems need 
> administration and security updates, etc. so for a great number of 
> applications it is just over kill. 
> 
> So if you are not going to use the distributed “intelligence” and compute 
> power sleeping in your SOC nodes, the µcontroller is for sure the way to go.
> 
> Stefano
>   
>> On 21 Feb 2019, at 06:29, Colin Reese  wrote:
>> 
>> Joe,
>> 
>> I transitioned from Pis to ESP32. I was all-in on Pis, trust me. I love 
>> linux. The issues:
>> 
>> It's not just the power supply. SDCards in this environment will corrupt 
>> eventually, absolutely. There is nothing that can protect the operating 
>> system from eventual corruption. Yes, I too, have been lucky and had them 
>> run for years. You simply cannot count on this with consumer-grade sd cards. 
>> You can buy industrial quality flash or eMMC, but at this point you are 
>> spending more for your memory than you are on the board, and often much, 
>> much more. If you do enough research, you will find that this is simply 
>> something you cannot practically avoid, unless you go to these expensive 
>> cards, or do work to make a frozen, read-only operating system image that 
>> offloads all data that need to be permanently stored onto something like a 
>> flash drive, where you do not care if it becomes partially corrupted. It's 
>> sad, but true. I have talked to dozens of people who use these. Every single 
>> one has had these issues, regardless of how good their power supply is. If 
>> your application cannot tolerate a reformat periodically (remote devices 
>> come to mind), this situation is simply a non-option.
>> 
>> The operating system is constantly being updated, and if you want things 
>> like, I dunno, support for Python 3.5+, you have to deal with the fact that 
>> it is often times a bleeding edge operating system, and things simply break. 
>> LSB was non-functional for a period ... it has at many times simply been a 
>> mess.
>> 
>> For me, I do not need a local database. I push it to a cloud service (my own 
>> servers, in this case), and handle it there, and serve it to anywhere on the 
>> net. For this reason, the complexity of a Pi solution simply does not 
>> outweigh the above issues.
>> 
>> Now, you can get an ESP32, which has WiFi, 4MB flash, bluetooth, in a tiny 
>> package, for $10. You can get one with a nice little oled display for $19. 
>> You can get one with an sdcard and wired ethernet for $30. You can get 
>> another version with 4MB more of program space via PSRAM for a little more. 
>> You can get em with relays, IR transceivers, CAN, RS485 .. lots of things. 
>> It's not quite as diverse as the arduino ecosystem, but it is getting there 
>> for sure. Best, you can run mi

Re: [Owfs-developers] Suggestions of Microcontrollers for 1-wire use.

[Colin Reese]

Joe,

I transitioned from Pis to ESP32. I was all-in on Pis, trust me. I love 
linux. The issues:


It's not just the power supply. SDCards in this environment will corrupt 
eventually, absolutely. There is nothing that can protect the operating 
system from eventual corruption. Yes, I too, have been lucky and had 
them run for years. You simply cannot count on this with consumer-grade 
sd cards. You can buy industrial quality flash or eMMC, but at this 
point you are spending more for your memory than you are on the board, 
and often much, much more. If you do enough research, you will find that 
this is simply something you cannot practically avoid, unless you go to 
these expensive cards, or do work to make a frozen, read-only operating 
system image that offloads all data that need to be permanently stored 
onto something like a flash drive, where you do not care if it becomes 
partially corrupted. It's sad, but true. I have talked to dozens of 
people who use these. Every single one has had these issues, regardless 
of how good their power supply is. If your application cannot tolerate a 
reformat periodically (remote devices come to mind), this situation is 
simply a non-option.


The operating system is constantly being updated, and if you want things 
like, I dunno, support for Python 3.5+, you have to deal with the fact 
that it is often times a bleeding edge operating system, and things 
simply break. LSB was non-functional for a period ... it has at many 
times simply been a mess.


For me, I do not need a local database. I push it to a cloud service (my 
own servers, in this case), and handle it there, and serve it to 
anywhere on the net. For this reason, the complexity of a Pi solution 
simply does not outweigh the above issues.


Now, you can get an ESP32, which has WiFi, 4MB flash, bluetooth, in a 
tiny package, for $10. You can get one with a nice little oled display 
for $19. You can get one with an sdcard and wired ethernet for $30. You 
can get another version with 4MB more of program space via PSRAM for a 
little more. You can get em with relays, IR transceivers, CAN, RS485 .. 
lots of things. It's not quite as diverse as the arduino ecosystem, but 
it is getting there for sure. Best, you can run micropython on it and 
avoid having to write any C whatsoever. I ported a ton of code over from 
my Pi projects. Best of all, it is rock solid. Mine reboots once an 
hour, stores data in a little json file to pick up after it reboots, and 
loads config from a set of json files. It posts to a web API, hosts its 
own web page for web-based config ... it's just ... wonderful.


Should probably contact me off-list if you want, as this is not germane 
to OWFS, but happy to give you any info you like.


Cheers,
C

On 2/20/2019 7:38 PM, joep wrote:

Hi All,

     To some extent this follows from thread: *Reliability and 
Robustness of the DS2482-100 or DS2482-800*


     I've been using a couple of Raspberry Pi's (RPi 1 Model A+) to 
manage the temperature, humidity and lighting in a terrarium since 
2014/2015. One Pi is in active use while the other is used as a 
development platform to try things out on. Overall I'm impressed by how 
much one can do without spending a fortune and I'm quite keen to explore 
further.


     One thing which always bothered me with the Pi's is the SD card. 
I've had a few corruptions (all power supply related). Even with a clean 
and stable supply I am still doubtful if one can achieve "industrial 
grade" reliability if using SD cards. So I'm now looking for other 
microcontroller options to control my 1-wire based system as I'm 
intending to extend management to my greenhouses where reliability is 
more important.


     Options I have looked at so far include the Arduino (Uno, Zero or 
DUE) and the ESP32. Haven't fully explored the latter but it seems to 
have an incredible number of interfaces. I'm quite impressed by the 
Arduino - it's simple, there's a big choice of units and it's easily 
extensible (with a lot of pre-built modules available). My design will 
involve power switching and (ideally) more than one 1-wire bus (so a 
DS2482-100 is likely to be involved). The system will also interface to 
my network for monitoring and management.


     What are your opinions re. suitable microcontrollers where 
reliability and ease of extensibility are requirements.


--
Regards
Joe P.



___
Owfs-developers mailing list
Owfs-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/owfs-developers




___
Owfs-developers mailing list
Owfs-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/owfs-developers

Re: [Owfs-developers] Strange read failure

[Colin Reese]

As long as 85 is never a valid temperature. Not sure why they put the error 
temp in a functional range. 

> On Feb 19, 2019, at 05:35, Mick Sulley  wrote:
> 
> The failure happened for about 10-20 minutes, reading about every 10 seconds 
> or so, then it recovered and is reading fine again.
> 
> All devices are powered.
> 
> I could change my code so that it reads fasttemp and if that is 85 it reads 
> through the others to try to find a good read.  Is that a sensible thing to 
> do?
> 
> Thanks
> 
> Mick
> 
>> On 19/02/2019 12:49, Jan Kandziora wrote:
>>> Am 19.02.19 um 10:39 schrieb Mick Sulley:
>>> My control system has detected a no read (85) on a DS18B20 temp sensor,
>>> however if I look at it via owhttpd I can see temperature, temperature11
>>> and temperature12, but 85 for fasttemp, temperature9 and temperature10.
>>> 
>>> How can that happen?  The sensor had been working OK.  I am running
>>> 3.2p3 on a Raspberry Pi
>>> 
>> Each reading of the uncached temperature nodes (but latesttemp) triggers
>> a new conversion. The browser orders owhttpd to do exactly that. What
>> you see isn't one conversion but a series of conversions of which some
>> failed because of a Power-On-Reset during conversion (that's the 85°C
>> reading) and some failed not.
>> 
>> Check your cabling. Also check if powering the chip helps.
>> 
>> Kind regards
>> 
>>Jan
>> 
>> 
>> ___
>> Owfs-developers mailing list
>> Owfs-developers@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/owfs-developers
> 
> 
> ___
> Owfs-developers mailing list
> Owfs-developers@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/owfs-developers


___
Owfs-developers mailing list
Owfs-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/owfs-developers

Re: [Owfs-developers] Reliability and Robustness of the DS2482-100 or DS2482-800

[Colin Reese]

You can directly run 1wire on digital io using existing libraries, but you’d 
need to build your own commands for devices. I’m about to do it for a few 
devices on ESP32 in MicroPython. DS18B20 works out of the box but search isn’t 
even implemented. Not too hard though. 

If you want to go bus master route, you can throw a ds2483 on an i2c bus and go 
that way. I’ve used them for years and they’re great. I end up needing uarts 
for other things and prefer to reserve them for when I have no other choice. 

WRT to the Pi, I have moved away from them completely due to reliability 
issues, so I think your move is wise. I use ESP32s everywhere. Thermostat, 
irrigation, pushing everything to cloud and also doing local control. 

C

> On Feb 15, 2019, at 01:19, Mail Lists  wrote:
> 
> Hi Guys,
> 
> I’ve been using a couple of LinkUSB 1-Wire USB adaptors with a RPi running 
> OWFS for my heating system, which seems to have performed well.
> 
> However, I’m considering changing it to something that will interface 
> directly to the Clipsal C-Bus system I have in the house, so I can control 
> the heating directly from within the C-Bus world and remove the RPi, to make 
> it more robust in case we sell the house in the nest few years.
> 
> So I’m thinking of making a device that talks to the 1-Wire via some 
> DS2482-100 modules or a DS2482-800 and maybe driving it from a ESP32 with one 
> of the UARTs connected to a C-Bus to Serial module and use the Open-Source 
> C-Bus node software Clipsal released years ago to join the two worlds.
> 
> So has anyone got any feedback on how reliable the DS2482-100 or DS2482-800 
> are and if there are some special precautions I need to consider?
> 
> Regards
> 
> Alex Shepherd
> 
> ___
> Owfs-developers mailing list
> Owfs-developers@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/owfs-developers


___
Owfs-developers mailing list
Owfs-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/owfs-developers

Re: [Owfs-developers] python-ow failure with new Raspbian Stretch

[Colin Reese]

I do exclusively. I was using my own wrapper reading directories but now use 
pyownet. 

C

> On Dec 17, 2017, at 8:45 AM, Gregg Levine  wrote:
> 
> Hello!
> I'd go a bigger step further and make them optional by way of how the
> configure script is managed. I manage three platforms here. My desktop
> a 32 bit machine running Slackware 11.0 Linux, and this laptop, that
> also runs Slackware 14.2 in 64 bit mode. And of course any number of
> Raspberry Pi platforms.
> 
> We'd a poll of some kind asking how many people use Python in the OWFS
> community, and even TCL and then PHP. Once we've got those numbers,
> we'd have some idea of what to do next.
> 
> Of course the merely obvious question is why the swig bindings are not
> under active development. The incredibly obvious question then is who
> was performing that task.
> -
> Gregg C Levine gregg.drw...@gmail.com
> "This signature fought the Time Wars, time and again."
> 
> 
> On Sun, Dec 17, 2017 at 10:58 AM, Matthias Urlichs via Owfs-developers
>  wrote:
>> On 17.12.2017 00:19, Stefano Miccoli wrote:
>>> Unfortunately owpython (the swig bindings) is not under active
>>> development.
>> 
>> I'd go a step further and remove them from the next release.
>> 
>> --
>> -- Matthias Urlichs
>> 
>> 
>> --
>> Check out the vibrant tech community on one of the world's most
>> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
>> ___
>> Owfs-developers mailing list
>> Owfs-developers@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/owfs-developers
> 
> --
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> ___
> Owfs-developers mailing list
> Owfs-developers@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/owfs-developers

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Owfs-developers mailing list
Owfs-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/owfs-developers

Re: [Owfs-developers] USB-I2C-1-wire for Star Networking

[Colin Reese]

Yes.

UPS even die eventually. My little board tells the Pi to shut down when battery 
gets low. It's basically a smart mini ups. 

Colin

> On Dec 12, 2017, at 7:12 PM, joep <j...@naturalmethods.org> wrote:
> 
> Hi Colin,
> 
> I had those experiences as well (including permanently damaged SD Cards 
> and PC's damaged by lightning strikes) and now have all IT equipment on a 
> UPS. The 1-wire controller will be part of a home automation server and won't 
> be remotely installed - it will be in the study on a UPS.
> 
> Regards
> Joe P.
> 
>> On 13/12/17 11:43, Colin Reese wrote:
>> WRT power, USB power is still an issue, especially over long period with 
>> fluctuating power. I use a power-management board and battery backup for 
>> this reason. Non-graceful shutdowns not only corrupt the operating system, 
>> but also potentially the SDCards permanently. This is a bad situation, 
>> obviously, exacerbated for remote installations.
>> 
>> C
>> 
>>> On 12/12/2017 5:34 PM, joep wrote:
>>> Thanks again Jan.
>>> 
>>>  >>> $ owserver --i2c=/dev/i2c-0:ALL
>>> 
>>> That answers my most pressing question.
>>> 
>>>  >>>I'm talking about the Raspberry Zero W, which has a built-in SDIO WLAN
>>> adapter and a built-in antenna. No fiddling with USB needed (though USB
>>> power isn't much of an issue anymore since the Raspberry B+).
>>> 
>>> I understood your initial suggestion re the Raspberry Zero W. My suspicion 
>>> is that WiFi is flaky irrespective of the host controller - I've had issues 
>>> with name brand WiFi units on name brand PC's. I suspect WiFi (and it's 
>>> drivers) is designed for shortish-term connections - not long ones lasting 
>>> months. Ethernet seems to fare much better.
>>> 
>>> Regards
>>> Joe P.
>>> 
>>>> On 13/12/17 11:08, Jan Kandziora wrote:
>>>>> Am 12.12.2017 um 22:38 schrieb joep:
>>>>> Jan thanks for the reply.
>>>>> 
>>>>> I currently have 2 Raspberry Pi's (of late 2012 vintage - forgot the
>>>>> model ID's) and I've been running them since early 2013. I've run
>>>>> one for 6 months non-stop (to manage the lighting and temperature in
>>>>> a terrarium) and only stopped it to update the Raspbian firmware. I
>>>>> use the "Blue DS9490R unit" (Dallas call it a DS9490R) to drive the
>>>>> 1-wire network. On of the main issues I found with operating the Pi
>>>>> with WiFi connectivity is the WiFi connectivity - seems to be a bit
>>>>> flaky (maybe the drivers for the specific WiFi unit - the WiFi was
>>>>> not powered directly from the Pi but from a USB hub)
>>>>> 
>>>> USB power on the original Raspberries was a source of constant
>>>> misfortune. And USB hubs often enough do, too.
>>>> 
>>>> 
>>>>> So I don't
>>>>> think I'll chose a Raspberry B Zero W for long term stability
>>>>> reasons.
>>>>> 
>>>> I'm talking about the Raspberry Zero W, which has a built-in SDIO WLAN
>>>> adapter and a built-in antenna. No fiddling with USB needed (though USB
>>>> power isn't much of an issue anymore since the Raspberry B+).
>>>> 
>>>> 
>>>> 
>>>>> The system I'm thinking of building is for a home server and will use
>>>>> a low-end laptop as I do not have to wire the basic infrastructure to
>>>>> get a computing environment happening (power supply, screen,
>>>>> keyboard, memory, case) - it's all setup already. All I'll need is a
>>>>> USB-to-I2C-to-1_wire.
>>>>> 
>>>>> If I'm to use a USB-to-I2C adaptor (say FT232H) to drive a I2C
>>>>> 1-wire master (say a DS2482-800) how should I initialize OWFS?
>>>>> 
>>>>> sudo owfs –d=/dev/i2c-0 /mnt/owfs ? or
>>>>> 
>>>>> sudo owfs –u=/dev/i2c-0 /mnt/owfs (manual says this option is for a
>>>>> "USB adapter (DS9490) as 1-wire bus master") ?
>>>>> 
>>>> Please don't use the owfs binary. It has an unsolvable race condition.
>>>> Use owserver and access it through the owwrite, owread, owdir, owget
>>>> shell tools or through one of the language bindings.
>>>> 
>>>> $ owserver --i2c=/dev/i2c-0:ALL
>>>> 
>>>> Kind regards
>>>> 
>>>> Jan
>>>

Re: [Owfs-developers] USB-I2C-1-wire for Star Networking

[Colin Reese]

WRT power, USB power is still an issue, especially over long period with 
fluctuating power. I use a power-management board and battery backup for 
this reason. Non-graceful shutdowns not only corrupt the operating 
system, but also potentially the SDCards permanently. This is a bad 
situation, obviously, exacerbated for remote installations.


C

On 12/12/2017 5:34 PM, joep wrote:

Thanks again Jan.

 >>> $ owserver --i2c=/dev/i2c-0:ALL

That answers my most pressing question.

 >>>I'm talking about the Raspberry Zero W, which has a built-in SDIO WLAN
adapter and a built-in antenna. No fiddling with USB needed (though USB
power isn't much of an issue anymore since the Raspberry B+).

I understood your initial suggestion re the Raspberry Zero W. My 
suspicion is that WiFi is flaky irrespective of the host controller - 
I've had issues with name brand WiFi units on name brand PC's. I suspect 
WiFi (and it's drivers) is designed for shortish-term connections - not 
long ones lasting months. Ethernet seems to fare much better.


Regards
Joe P.

On 13/12/17 11:08, Jan Kandziora wrote:

Am 12.12.2017 um 22:38 schrieb joep:

Jan thanks for the reply.

I currently have 2 Raspberry Pi's (of late 2012 vintage - forgot the
model ID's) and I've been running them since early 2013. I've run
one for 6 months non-stop (to manage the lighting and temperature in
a terrarium) and only stopped it to update the Raspbian firmware. I
use the "Blue DS9490R unit" (Dallas call it a DS9490R) to drive the
1-wire network. On of the main issues I found with operating the Pi
with WiFi connectivity is the WiFi connectivity - seems to be a bit
flaky (maybe the drivers for the specific WiFi unit - the WiFi was
not powered directly from the Pi but from a USB hub)


USB power on the original Raspberries was a source of constant
misfortune. And USB hubs often enough do, too.



So I don't
think I'll chose a Raspberry B Zero W for long term stability
reasons.


I'm talking about the Raspberry Zero W, which has a built-in SDIO WLAN
adapter and a built-in antenna. No fiddling with USB needed (though USB
power isn't much of an issue anymore since the Raspberry B+).




The system I'm thinking of building is for a home server and will use
a low-end laptop as I do not have to wire the basic infrastructure to
get a computing environment happening (power supply, screen,
keyboard, memory, case) - it's all setup already. All I'll need is a
USB-to-I2C-to-1_wire.

If I'm to use a USB-to-I2C adaptor (say FT232H) to drive a I2C
1-wire master (say a DS2482-800) how should I initialize OWFS?

sudo owfs –d=/dev/i2c-0 /mnt/owfs ? or

sudo owfs –u=/dev/i2c-0 /mnt/owfs (manual says this option is for a
"USB adapter (DS9490) as 1-wire bus master") ?


Please don't use the owfs binary. It has an unsolvable race condition.
Use owserver and access it through the owwrite, owread, owdir, owget
shell tools or through one of the language bindings.

$ owserver --i2c=/dev/i2c-0:ALL

Kind regards

Jan


-- 


Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Owfs-developers mailing list
Owfs-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/owfs-developers



-- 


Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Owfs-developers mailing list
Owfs-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/owfs-developers


--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Owfs-developers mailing list
Owfs-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/owfs-developers

Re: [Owfs-developers] USB-I2C-1-wire for Star Networking

[Colin Reese]

Yes, I totally get it. Unfortunately, you can't always depend on having 
wired interfaces. Or, at least I can't. So you manage.


Colin


On 12/12/2017 2:05 PM, joep wrote:

Hi Colin,

     When I use WiFi I do have a shell script, invoked by CRON, that 
periodically checks the health of the network interfaces and restarts 
them if down (also records in a log file which interface went down and 
when - WiFi features prominently in the log file). Much rather have 
something intrinsically stable like a wired Ethernet interface.


Regards
Joe P.

On 13/12/17 07:54, Colin Reese wrote:
WiFi connectivity is the crux for sure. I've written tons of code 
around keeping them connected in various circumstances. If you can get 
them on wired, they'll stay up forever. Otherwise, you'll need to 
write yourself a daemon to bring it down and back up when it loses 
connectivity. Netifaces in python2.7 or python3.5+ is what I use for 
this.


C

On 12/12/2017 1:38 PM, joep wrote:

Jan thanks for the reply.

I currently have 2 Raspberry Pi's (of late 2012 vintage - forgot the 
model ID's) and I've been running them since early 2013. I've run one 
for 6 months non-stop (to manage the lighting and temperature in a 
terrarium) and only stopped it to update the Raspbian firmware. I use 
the "Blue DS9490R unit" (Dallas call it a DS9490R) to drive the 
1-wire network. On of the main issues I found with operating the Pi 
with WiFi connectivity is the WiFi connectivity - seems to be a bit 
flaky (maybe the drivers for the specific WiFi unit - the WiFi was 
not powered directly from the Pi but from a USB hub). So I don't 
think I'll chose a Raspberry B Zero W for long term stability reasons.


The system I'm thinking of building is for a home server and will use 
a low-end laptop as I do not have to wire the basic infrastructure to 
get a computing environment happening (power supply, screen, 
keyboard, memory, case) - it's all setup already. All I'll need is a 
USB-to-I2C-to-1_wire.


If I'm to use a USB-to-I2C adaptor (say FT232H) to drive a I2C 1-wire 
master (say a DS2482-800) how should I initialize OWFS?


 sudo owfs –d=/dev/i2c-0 /mnt/owfs ? or

 sudo owfs –u=/dev/i2c-0 /mnt/owfs (manual says this option is 
for a "USB adapter (DS9490) as 1-wire bus master") ?


 ... other ?

Regards
Joe P.

On 12/12/17 23:43, Jan Kandziora wrote:

Am 12.12.2017 um 06:07 schrieb joep:

Way back, in Apr 22, 2012 5:42pm to be precise, Patryk-6 started a
thread called 'usb-i2c-1wire tutorial' (at
https://sourceforge.net/p/owfs/mailman/message/29163416/) in which he
started discussing a USB-to-1-wire bus master to replace the then
discontinued DS2490. I believe that the DS2490 has now been replaced
by the DS2490r which is in production so Patryk-6's need may no
longer be there.


There is no such thing as a DS2490R. The DS2490 is the chip inside the
blue **DS9490R** and DS9490B adapters. Ten years ago, you could buy the
DS2490 chip to build similar adapters yourself but in 2010 or so Maxim
decided not to sell the chip any more.

You can still buy the blue adapters though.



One possible implementation is for a
USB-to-I2C interface (using, for example, an adafruit FT232H breakout
unit) driving a DS2482-800 (or multiple DS24282-100) to give multiple
independent 1-wire busses.


Correct. But using one or more Raspberry B Zero W running owserver may
be a **cheaper** and simpler idea, as the Raspberries already have
exposed I²C buses. See it as a WLAN to Onewire bridge.



The main questions I'm interested in resolving is: Can I use OWFS
drivers to drive a DS2482-800 through the USB-to-i2C interface
(FT232H)?


OWFS uses the Linux kernel to access I²C, so any USB-I²C adapter for
which a Linux kernel driver exists will work.

Kind regards

Jan




-- 


Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Owfs-developers mailing list
Owfs-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/owfs-developers


-- 


Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Owfs-developers mailing list
Owfs-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/owfs-developers




--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Owfs-developers mailing list
Owfs-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/owfs-developers

Re: [Owfs-developers] USB-I2C-1-wire for Star Networking

[Colin Reese]

WiFi connectivity is the crux for sure. I've written tons of code around 
keeping them connected in various circumstances. If you can get them on 
wired, they'll stay up forever. Otherwise, you'll need to write yourself 
a daemon to bring it down and back up when it loses connectivity. 
Netifaces in python2.7 or python3.5+ is what I use for this.


C

On 12/12/2017 1:38 PM, joep wrote:

Jan thanks for the reply.

I currently have 2 Raspberry Pi's (of late 2012 vintage - forgot the 
model ID's) and I've been running them since early 2013. I've run one 
for 6 months non-stop (to manage the lighting and temperature in a 
terrarium) and only stopped it to update the Raspbian firmware. I use 
the "Blue DS9490R unit" (Dallas call it a DS9490R) to drive the 1-wire 
network. On of the main issues I found with operating the Pi with WiFi 
connectivity is the WiFi connectivity - seems to be a bit flaky (maybe 
the drivers for the specific WiFi unit - the WiFi was not powered 
directly from the Pi but from a USB hub). So I don't think I'll chose a 
Raspberry B Zero W for long term stability reasons.


The system I'm thinking of building is for a home server and will use a 
low-end laptop as I do not have to wire the basic infrastructure to get 
a computing environment happening (power supply, screen, keyboard, 
memory, case) - it's all setup already. All I'll need is a 
USB-to-I2C-to-1_wire.


If I'm to use a USB-to-I2C adaptor (say FT232H) to drive a I2C 1-wire 
master (say a DS2482-800) how should I initialize OWFS?


     sudo owfs –d=/dev/i2c-0 /mnt/owfs ? or

     sudo owfs –u=/dev/i2c-0 /mnt/owfs (manual says this option is for a 
"USB adapter (DS9490) as 1-wire bus master") ?


     ... other ?

Regards
Joe P.

On 12/12/17 23:43, Jan Kandziora wrote:

Am 12.12.2017 um 06:07 schrieb joep:

Way back, in Apr 22, 2012 5:42pm to be precise, Patryk-6 started a
thread called 'usb-i2c-1wire tutorial' (at
https://sourceforge.net/p/owfs/mailman/message/29163416/) in which he
started discussing a USB-to-1-wire bus master to replace the then
discontinued DS2490. I believe that the DS2490 has now been replaced
by the DS2490r which is in production so Patryk-6's need may no
longer be there.


There is no such thing as a DS2490R. The DS2490 is the chip inside the
blue **DS9490R** and DS9490B adapters. Ten years ago, you could buy the
DS2490 chip to build similar adapters yourself but in 2010 or so Maxim
decided not to sell the chip any more.

You can still buy the blue adapters though.



One possible implementation is for a
USB-to-I2C interface (using, for example, an adafruit FT232H breakout
unit) driving a DS2482-800 (or multiple DS24282-100) to give multiple
independent 1-wire busses.


Correct. But using one or more Raspberry B Zero W running owserver may
be a **cheaper** and simpler idea, as the Raspberries already have
exposed I²C buses. See it as a WLAN to Onewire bridge.



The main questions I'm interested in resolving is: Can I use OWFS
drivers to drive a DS2482-800 through the USB-to-i2C interface
(FT232H)?


OWFS uses the Linux kernel to access I²C, so any USB-I²C adapter for
which a Linux kernel driver exists will work.

Kind regards

Jan




-- 


Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Owfs-developers mailing list
Owfs-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/owfs-developers


--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Owfs-developers mailing list
Owfs-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/owfs-developers

Re: [Owfs-developers] System Lock-up again

[Colin Reese]

There's also this:

http://www.mouser.com/Search/m_ProductDetail.aspx?Mean-Well%2FHDR-15-5%2F=pHY8AWQbqIPp9NNEfa6UOQ%3D%3D

I use this:

https://lowpowerlab.com/guide/mightyboost/

It requires a moteino (arduino clone) to run shutdown and power management apps 
(and RF comms if you get one with RF). I also have to moteino send battery 
voltage, events, and status updates to Pi. A non-RF variant costs $10. If you 
go this route, I have a redone state-machine sketch  I can send you. I also 
have daughter boards for the Pi to mount these on (they also have a footprint 
for a DS2483 1Wire bus master). 

C

> On Sep 25, 2017, at 4:28 AM, Matthias Urlichs via Owfs-developers 
>  wrote:
> 
>> On 25.09.2017 10:32, Mick Sulley wrote:
>> Matthias, I have just looked through the Meanwell site but cannot see
>> any that are adjustable (may have missed it there are a lot there),
>> can you tell me which one you used please?
> https://www.trcelectronics.com/mean-well-din-rail-power-supply-mdr-20
> 
> -- 
> -- Matthias Urlichs
> 
> 
> --
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> ___
> Owfs-developers mailing list
> Owfs-developers@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/owfs-developers
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
Owfs-developers mailing list
Owfs-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/owfs-developers

Re: [Owfs-developers] System Lock-up again

[Colin Reese]

So many problems come from there. I use a power management board with boost 
converter and lipo for this reason. Deals with outages as well with graceful 
shutdown. 

C

> On Sep 24, 2017, at 7:56 AM, Matthias Urlichs via Owfs-developers 
>  wrote:
> 
>> On 24.09.2017 12:38, Mick Sulley wrote:
>> Any suggestions on how I can find out what is causing this.
> 
> When I had this problem, the root cause was a flaky power supply.
> 
> Get a cap-rail-mounted adjustable 5V power supply (e.g. from Meanwell).
> Connect the Pi, then carefully adjust the voltage up to 5.15V. That's
> still well within spec (+5% tolerance means 5.25V) but helps a lot when
> you have transient problems.
> 
> The affected Pi didn't have any more hiccups after I did that.
> 
> Also, add a 0.1µF ceramic cap between 5V and ground of the 1wire lines,
> close to the Pi, to buffer spikes from out there.
> 
> -- 
> -- Matthias Urlichs
> 
> 
> --
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> ___
> Owfs-developers mailing list
> Owfs-developers@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/owfs-developers

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Owfs-developers mailing list
Owfs-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/owfs-developers

Re: [Owfs-developers] DIY Arduino based Display (LCD, OLED)

[Colin Reese]

No display picture!

On 9/3/2017 8:23 AM, Dr. Trigon wrote:

Hello

Just wanted to share my display ("LCD") solution for 1-wire networks 
with you:


http://www.instructables.com/id/Arduino-1-wire-Display-144-Chars/

This basically covers all my needs as it is open and adoptable to future 
needs. By that it also solves all my LCD issues... ;))
(may be I still continue to look into others but there is no need for it 
anymore)


Greetings and enjoy the rest of your weekend!

Dr. Trigon


--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot



___
Owfs-developers mailing list
Owfs-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/owfs-developers



--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Owfs-developers mailing list
Owfs-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/owfs-developers

Re: [Owfs-developers] Minimal Wi-Fi power?

[Colin Reese]

A micro also has far better power-down options (nA) and shorter activity 
periods. It all adds up. 

> On Aug 2, 2017, at 5:29 PM, Loren Amelang  wrote:
> 
> On Wednesday, August 2, 2017 at 10:31 AM,
> owfs-developers-requ...@lists.sourceforge.net wrote:
>> 1. Re: Arduino yun as wifi 1wire master
> 
> I keep reading these posts saying Wi-Fi is a power hog. I just ordered a pair 
> of Raspberry Pi Zero W boards to find out...  All the web sites say that the 
> "W" version adds 20 mA to the power consumption of the non-wireless Zero 
> board. Presumably that's with the Wi-Fi not heavily loaded...  If the board 
> takes 70 to 100 mA with the Wi-Fi off, adding another 20 mA does not seem 
> like a major disadvantage. I'm sure if you were uploading camera video, that 
> would go way up, but for an occasional switch change or temperature reading 
> I'd expect the idle value most of the time. 
> 
> Am I missing something important here, or are people thinking older 
> generations of Wi-Fi? 
> 
> Loren
> 
> | Loren Amelang | lo...@pacific.net |
> 
> 
> 
> 
> --
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> ___
> Owfs-developers mailing list
> Owfs-developers@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/owfs-developers

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Owfs-developers mailing list
Owfs-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/owfs-developers

Re: [Owfs-developers] Arduino yun as wifi 1wire master

[Colin Reese]

They're great, but WiFi is terrible for power, and RF916 (or even LoRa) are 
great for range where Bluetooth is not. Pin compatibility with power module, a 
well-developed ecosystem ... I've done my research on this, and for low-power 
remote nodes these are the goods. They're also great for power management for 
Pi projects where intermittent power is an issue. Graceful shutdowns with a 
little 800mAh LiPo (the power boards have a boost DC/DC) save my OS. Autoboot 
when power is back. It's truly great. I use them in all sorts of commercial 
installs. 

C

> On Aug 2, 2017, at 9:23 AM, Andrew Errington  wrote:
> 
> All the cool kids are using ESP8266 modules these days.
> 
> Andrew
> 
>> On Aug 2, 2017 4:14 PM, "Dr. Trigon"  wrote:
>> Hi Colin
>> 
>> >wall. Low power + existing libraries for 1Wire. This RF unit (I use
>> >Moteinos) would cost you about $20. The gateway unit would also cost
>> >you
>> >about $20. I send things around encrypted, data format json strings,
>> >and
>> >it's very easy to manage. If you want to shove this into 1Wire, do it
>> >on
>> >the gateway node as data is received.
>> 
>> So Moteino = Arduino+RF correct? That would mean I would have to write 
>> sketches for it and some script for the gateway raspi using externals 
>> mechanism in owfs, right? I would like to have a generic 1wire master - so 
>> would think about OneWireFirmata - don't know. (By "generic master" I mean 
>> something where I can just connect sensors without having to write or modify 
>> code.)
>> 
>> >I have code for all of this including the Pi serial handler if you are
>> >interested.
>> 
>> If you have some more info at hand, I intressted in having a look for future 
>> changes in my setup but for now I am happy with my solution.
>> 
>> Thanks and greetings
>> 
>> --
>> Check out the vibrant tech community on one of the world's most
>> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
>> ___
>> Owfs-developers mailing list
>> Owfs-developers@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/owfs-developers
>> 
> --
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> ___
> Owfs-developers mailing list
> Owfs-developers@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/owfs-developers
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
Owfs-developers mailing list
Owfs-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/owfs-developers

Re: [Owfs-developers] Arduino yun as wifi 1wire master

[Colin Reese]

I reiterate that I think this is shoving a round peg into a square hole.
You requirements scream to me that you should be using an RF node that
beams your data into a gateway Pi behind closed doors and attached to the
wall. Low power + existing libraries for 1Wire. This RF unit (I use
Moteinos) would cost you about $20. The gateway unit would also cost you
about $20. I send things around encrypted, data format json strings, and
it's very easy to manage. If you want to shove this into 1Wire, do it on
the gateway node as data is received.

You can even very cheaply get power management boards (called Mightyboost,
~$20, attaches directly to Moteino) that will allow you to charge batteries
attached to your RF unit, although with their ridiculously low power
consumption, I don't even think this would be an issue. They'll run on a
single battery for a long long time.

I have code for all of this including the Pi serial handler if you are
interested.

Colin

On Tue, Aug 1, 2017 at 11:09 AM, Dr. Trigon  wrote:

> Hello all!
>
> Thanks for the numerous replies and suggestions to this topic! To make a
> long story short; I decided to not insist in a free/open solution for now
> and ordered a ethernet2wifi converter as I have an unused ethernet master
> around. For later I consider using a Raspi Zero W + level-shifting
> transistor + pull-up as this is an intressting option. Or may be an
> commercial master (USB, I2C, etc.) on the raspi.
>
> For power, a solar panel was the solution I considered and still do. DC/DC
> converters are amazingly efficient nowadays... ;)
>
> Drilling any hole - also in the proximity of the roof is not an option, as
> I currently live in an apartment block. Otherwise this can be a very nice
> solution. Actually I would prefer it, but then go outside with ethernet for
> a 1wire master as the 1wire could become verrry long otherwise (even though
> it might work).
>
> owserver-deamon that would be needed to run on the Raspi Zero W e.g.,
> means running 'owserver' binary, right?
>
> The reason why I wanted to avoid running another instance of owserver in
> the first place, was power consumption and the fact that importing owfs
> instances from other machines might be a bit problematic (or connecting to
> other instances using the -s option). I read a few comments about this,
> don't know. Regarding power, I assumed the processors consumption (avr vs.
> arm, yun vs. raspi) and the number of processes running does matter, but if
> wifi dominates that might be wrong here. (And thus even an uno with wifi
> shield consumes the same.)
>
> Thanks for all your comments and greetings
>
>
> Am 23. Juli 2017 14:06:39 MESZ schrieb owfs-developers-request <
> owfs-developers-requ...@lists.sourceforge.net>:
>>
>>
>> Send Owfs-developers mailing list submissions to
>>  owfs-developers@lists.sourceforge.net
>>
>> To subscribe or unsubscribe via the World Wide Web, visit
>>  https://lists.sourceforge.net/lists/listinfo/owfs-developers
>> or, via email, send a message with subject or body 'help' to
>>  owfs-developers-requ...@lists.sourceforge.net
>>
>> You can reach the person managing the list at
>>  owfs-developers-ow...@lists.sourceforge.net
>>
>> When replying, please edit your Subject line so it is more specific
>> than "Re: Contents of Owfs-developers digest..."
>>
>>
>> Today's Topics:
>>
>>1. Re: Arduino yun as wifi 1wire master (Jan Kandziora)
>>2. Re: Arduino yun as wifi 1wire master (Stefano Miccoli)
>>
>>
>> --
>>
>>
>> Message: 1
>> Date: Sat, 22 Jul 2017 15:12:21 +0200
>> From: Jan Kandziora 
>> To: owfs-developers@lists.sourceforge.net
>> Subject: Re: [Owfs-developers] Arduino yun as wifi 1wire master
>> Message-ID: <502209ec-a3ef-5c46-2b19-1e3750800...@gmx.de>
>> Content-Type: text/plain; charset=utf-8
>>
>> Am 22.07.2017 um 12:24 schrieb Dr. Trigon:
>>
>>>
>>>  Raspi Zero is fine too, but someone needs
>>>  to tell me how to set the software up, how to build the stuff
>>>  together.
>>
>>
>> 1. You buy a Raspberry Pi Zero W.
>> 2. You put an Raspian image (minimal will do) from the Raspberry Pi
>> website onto an >2GB micro SD card and put it into the Pi.
>> 3. You switch on the thing, connect a HDMI screen and keyboard to it,
>> then login into this little Linux box in front of you.
>> 4. You configure Wifi and Internet connection to get the thing connected
>> to your indoors equipment and load software form the internet.
>> 5. You apt-get the owserver package and edit the raspi's
>> /boot/config.txt to include the w1-gpio overlay on GPIO4. Reboot.
>> 6. You now have a 3.3V onewire on GPIO4, available through Wifi, TCP
>> port 4304. This is what owserver does.
>> 7. Your indoor devices can connect to that owserver on the Raspberry via
>> -s :4304 command line option.
>> 8. Congrats. You are done.
>>
>>
>>  I don't want to run another instance of owfs on those
>>>  devices as they should act as master and not owfs servers.

Re: [Owfs-developers] Arduino yun as wifi 1wire master

[Colin Reese]

If you prefer no wifi and want to run on battery, I'd suggest something like a 
Moteino: RF arduino clones. You can bitbang 1W and they have very low power 
requirements. A central gateway node on your Pi to aggregate and you're set. 
How and if you shove this into owfs is up to you, but I've never gone this 
route. 

As far as reading directly from the Pi, avoiding maxim chips is a fool's errand 
when a performant $2 bus master like the DS2483 is available. 

C

> On Jul 20, 2017, at 4:49 AM, Jan Kandziora  wrote:
> 
>> Am 20.07.2017 um 12:45 schrieb Dr. Trigon:
>> My intention was not to run owfs on the Yun, but use the Yun as
>> master connected by ethernet/wifi to an owfs server (like enet
>> e.g.).
>> 
>> 1wire === Yun as 1wire Master === owfs server
>> 
>> Where the connection between Yun and owfs server is a wifi.
>> 
>> How can I connect an raspi zero via wifi to my owfs server and use
>> the bitbang? I would like to avoid using Maxim chips if possible -
>> should be open.
>> 
> The Raspberry Pi Zero W is pretty similar to the Raspberry Pi B+. You
> can use the standard Rasbian or any other Linux distro meant for the
> Raspberry (there are several.)
> 
> The 40-pin extension header is also the same as on the other
> Raspberries, so you can use all the manuals and premanufactured
> extensions boards OOTB. The only things that are missing are the bulky
> USB-A and Ethernet connectors. (It even has HDMI.)
> 
> Bitbanging onewire is supported through the w1 kernel driver. That's the
> same as with the Arduino Yun, I think.
> 
> 
>> The ESP8266 looks intressting but I don't like having wifi on every
>> single sensor - don't like this IoT stuff. Would like to have 1 1wire
>> master connected by wifi to my home lan and the owfs server running
>> on another machine there.
>> 
>> This master should be possible to run from battery, btw.
>> 
> Both the Arduino Yun and the Raspberry Pi Zero W have similar power
> requirements. About 2W for the SoC.
> 
> If "by battery" you mean a "small battery" then - forget it. Wifi alone
> need about 600mW of power. That's for any board.
> 
> 
> Kind regards
> 
>Jan
> 
> 
> 
> 
> 
> 
> --
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> ___
> Owfs-developers mailing list
> Owfs-developers@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/owfs-developers

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Owfs-developers mailing list
Owfs-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/owfs-developers

Re: [Owfs-developers] Unsupported 1-wire device

[Colin Reese]

Out of curiosity, why did you not use one of the supported avr 1Wire slave 
implementations?

> On May 3, 2017, at 9:55 AM, Péter Zsembery  wrote:
> 
> Dear Members,
> I have implemented a TX-20 anemometer in my home made 1-wire weather station. 
> Since TX-20 does not have 1-wire interface I had to develop my own 1-wire 
> slave unit (based on a PIC16F877A MCU)  which is a bridge between the 
> anemometer and the 1-wire network. The 1-wire network is managed by a home 
> developed 1-wire master (also based on a PIC16F877A MCU)  which can handle 
> the home made 1-wire slave.
> Now I want to attach the weather station to a Raspberry Pi. I plan to use 
> OWFS and a DS2482 as 1-wire master.
> Is it possible to configure the OWFS to recognize and communicate with my 
> custom 1-wire slave device? If yes please advise where to find the 
> documentation.
> Thank you
> Peter
> --
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> ___
> Owfs-developers mailing list
> Owfs-developers@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/owfs-developers

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Owfs-developers mailing list
Owfs-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/owfs-developers

Re: [Owfs-developers] Fine-tune timing against disappearing slaves

[Colin Reese]

Sven, what code are you using on your attiny?

> On Feb 15, 2017, at 7:27 AM, Jan Kandziora  wrote:
> 
>> Am 15.02.2017 um 08:25 schrieb Sven Giermann:
>> 
>> I have several temperature sensors and 1 DS2423 counter in one room. All
>> are connected with a Cat.5 network cable (about 30 meters) in a single bus
>> that ends in another room with a small embedded Debian ARM (armel) server
>> that runs OWFS 2.8p15-1.
>> 
> Please update to 3.1p5. No one wants to hunt bugs fixed for years.
> 
> 
>> Everything fine up to here. Let's call this branch "A".
>> 
>> I then started to connect some software programmed ATTiny85 custom 1-wire
>> slaves, drawing another branch (branch "B") from my server. That way, the
>> first star-alike topology was built, currently a single bus, but with the
>> master in the middle.
>> This also worked for the first 2 devices, about 7 meters distance to the
>> master (remember the additional 30 m to the other sensors). I used simple
>> electric cable (NYM-J 3x1.5mm²) for this second branch, because I needed
>> the third wire for some higher currents.
>> 
> I would suspect the ATtiny slaves are a more picky about the timing then
> the Dallas/Maxim ones.
> 
> 
>> Well... some months later I added 2 more custom slaves on a third branch
>> ("C"), having a typical star topology now with the master in the middle.
>> Again, those are connected with NYM-J as well, with about 4 meters distance
>> and. yes, it worked!
>> 
>> My problems started when I expanded the last branch by another 4 meters
>> trying to connect a third slave on that branch!
>> Suddenly all 3 slaves on that branch disappeared from the bus.
>> 
> Yes. That could happen and it is likely to happen. The star topology is bad.
> 
> 
>> I could not get them back, whatever I tried: removing the 4 meters
>> extension, disconnecting the other 2 branches, only connect a single slave
>> - nothing helped.
>> (But they showed up and worked for weeks before I added the extension!)
>> 
>> I then finished my setup first - having a total of 3 slaves on branch "B"
>> and 7 slaves on branch "C". Branch "B" has a total length of 12 meters,
>> branch "C" about 30 meters:
>> 
>> Master (DS9490R)
>> |--()--()--...--()   "A", 30 meters Cat.5, 8 slaves
>> |--()--()--()"B", 12 meters NYM-J1.5, 3 slaves
>> |--()--()--...--()   "C", 30 meters NYM-J1.5, 7 slaves
>> 
>> Still, only all slaves of branch "A" and the the first two of branch "B"
>> show up on the bus. For testing purpose I went and connected my laptop
>> running a virtualized Debian installation and OWFS to that bus - and: ALL
>> devices showed up and responded to read and write commands. It took some
>> seconds and maybe 3-4 runs of 'owdir /uncached' to see all devices, but
>> finally it worked.
>> 
> No, it didn't. What you have is an extremely brittle setup which may or
> may not work, depending on moon phase and other non-insightful
> parameters. This is impossible to debug.
> 
> 
>> 
>> Now... does anyone have any advice what to change/try next?
>> Should I try to compile OWFS 3.1?
>> 
> You should install the Rasbian package from the testing repository.
> 
> Testing(Stretch) has owfs-3.1p5. You can use the owfs packages
> from the Raspbian testing repository. Edit (or create) your
> /etc/apt/preferences to contain:
> --
> Package: *
> Pin: release o=Raspbian,a=stable
> Pin-Priority: 500
> 
> Package: *
> Pin: release o=Raspbian,a=testing
> Pin-Priority: 300
> --
> This is important so you keep stable (Jessie) for all packages but the ones
> explicitly taken from testing (Stretch).
> 
> 
> Then, add a line
> --
> deb http://mirrordirector.raspbian.org/raspbian/ testing main contrib
> non-free rpi
> --
> to your /etc/apt/sources.list to get access to the Raspbian testing
> repository.
> 
> Do an
> 
> $ sudo apt-get update
> 
> to read the package metadata, then check
> 
> $ sudo apt-cache policy
> 
> whether the testing repo is there with priority 300. Then
> 
> $ sudo apt-get update -t testing owserver ow-shell
> 
> That should install all you need, including the startup files and
> systemd units.
> Note you have to edit /etc/owfs.conf again to contain (this and only this)
> --
> !server: server = localhost:4304
> server: w1
> --
> Restart the owserver service after that.
> 
> 
>> Is there any configuration (defines?) that can cause different timing on
>> the bus - making it work on i386 and fail on armel?
>> 
> Do you use the DS9490 on both?
> 
> 
>> Any advise to change the bus? Different cable? Different master (I have
>> another 

Re: [Owfs-developers] Hiding incompatible device variants

[Colin Reese]

Thanks!

I'll get out the programmer shortly and test this out. I only have 328s around 
but from what I remember it's an easy change in the config file. I just fiddled 
for some time and nothing ever popped up on my bus. 

Colin


> On Feb 11, 2017, at 1:24 AM, Johan Ström <jo...@stromnet.se> wrote:
> 
>> On 11/02/17 09:12, Colin Reese wrote:
>> 
>> If you could point me to a known working hardware/software configuration on 
>> or offline I would be quite grateful.
>> 
>> Thanks,
>> Colin
>> 
> Ok, so here is a pretty much copy-paste solution which should work:
> 
> I'm running with a Mega88 with the internal 8Mhz RC. I have a custom 
> file "mydevices.cfg" [1] in the moat source dir.
> I build & program the device with
> 
> make CFG=mydevices.cfg burn_mymoat
> 
> Or, to just test build: skip burn_ prefix
> 
> avrdude is used to program via an Avr-ISPmkII.
> python3 is required for Cfg
> the regular AVR stack is required (avr-gcc, avr-objcopy etc)
> 
> The first time you run the command it will allocate a random ID and add 
> "onewire_id" to the cfg file.
> 
> Hope this can help you get started!
> 
> /Johan
> 
> 
> 
> [1] mydevices.cfg:
> 
> _include: world.cfg
> env:
>   prog: avrispmkii -P usb
>   avrdude: avrdude
> 
> devices:
>   _default:
> _ref: defaults.target.m88
> types:
>   _ref: defaults.types
> code: []
> 
>   mymoat:
> _ref: defaults.target.m88
> _doc: Mega88PU-A with 8Mhz RC
> types:
>   port: 12
>   adc: 9
>   status: 1
> port:
> 
>  # See world.cfg for what the ^ and * etc symbols mean!
> 
>   1: B2^* # Green LED (low to light)
>   2: B1^* # Red LED (low to light)
>   3: B0_*
>   4: D7~+*
> 
>   5: D6_* # Unused
>   6: D5_* # Unused
>   7: B7_* # Unused
>   8: B6_* # Unused
> 
>   9: D4_* # Unused
>   10: D3_* # Unused
> #  # D2 is 1W
>   11: D1_* # Unused
>   12: D0_* # Unused
>   # PC6 is reset, already has external pull-up
> 
>   # PC0-PC5 + ADC6-7 are used as ADC. No pullup necessary
> unused: [B5,B4,B3]
> 
> adc:
>   1: 0*
>   2: 1*
>   3: 2*
>   4: 3*
>   5: 4*
>   6: 5*
>   7: 6*
>   8: 7*
>   9: T-* # temperature
> 
> 
> 
> --
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, SlashDot.org! http://sdm.link/slashdot
> ___
> Owfs-developers mailing list
> Owfs-developers@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/owfs-developers

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
___
Owfs-developers mailing list
Owfs-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/owfs-developers

Re: [Owfs-developers] Hiding incompatible device variants

[Colin Reese]

If you could point me to a known working hardware/software configuration on or 
offline I would be quite grateful. 

Thanks,
Colin

> On Feb 11, 2017, at 12:08 AM, Johan Ström  wrote:
> 
>> On 11/02/17 06:16, Alastair D'Silva wrote:
>> By the way, if you do an onewire LED driver, the feature I adore most is
>>> synchronous control over a whole bus. So multiple LED units can be pre-
>>> programmed to dim in a controlled fashion starting at a single point in
>> time.
>>> You had to implement a new command similar to "Convert T" to achieve this.
>>> That would break any existing driver but is extremly simple to implement
>> in
>>> your own driver (and the simultanenous code, of course).
>> That sounds like a great idea, thanks.
>> 
>> These are the commands I have implemented currently:
>> ALL_OFF(sets all the channels on the device off, maybe a candidate
>> for a simultaneous command?)
>> COUNT_CHANNELSreturns the number of available channels to the master
>> SET_CHANNELfades a channel to a specified RGBW value over a
>> specified time
>> GET_CHANNELgets the current RGBW value of a channel, and the
>> fade time remaining
>> 
>> It should be relatively straightforward to add a COMMIT command which only
>> starts fading the requested channels once received.
>> 
> I've done some (not yet published) work on MoaT (another custom slave) 
> to add some LED PWM'ing capabilities. It have been on pause lately 
> though, but the prototype is lying on my desk and have been fading a LED 
> strip up and down for a few months now.
> 
> Anyway, my prototype has support for the following settings/modes:
> * Direct PWM duty cycle control (for setting a static value)
> * "Breath" / ramp / flash mode: Fades back and forth between two min/max 
> values, with adjustable step size (how much to inc/dec the PWM output), 
> step duration (how long to wait between each inc/dec), and hold duration 
> (how long to wait at min/max). With zero step duration it's just 
> flashing between min/max.
> * Repeat mode: same as above but just repeats the specified number of 
> times. Useful for i.e "flash 10 times then stay off" (or on, configurable).
> 
> This gives quite a few parameters to control for each channel though, 
> could perhaps be simplified or improved..
> I had the same idea about a "master" control, can probably be very 
> useful indeed!
> 
> Well, just wanted to throw it out there.. Perhaps it can inspire some 
> good ideas, and perhaps that can inspire me to get back on working with 
> it :)
> 
> /Johan
> 
> --
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, SlashDot.org! http://sdm.link/slashdot
> ___
> Owfs-developers mailing list
> Owfs-developers@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/owfs-developers

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
___
Owfs-developers mailing list
Owfs-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/owfs-developers

Re: [Owfs-developers] Hiding incompatible device variants

[Colin Reese]

I want so badly an avr owfs slave. There are no available ADCs, and the 
DIO are expensive and a pain to use.

I never got MOAT to work. I would use ARM if it worked out of the box.

Colin


On 2/10/2017 4:07 PM, Jan Kandziora wrote:
> Am 10.02.2017 um 22:04 schrieb Alastair D'Silva:
>> Hi folks,
>>
>> I've written a 1Wire slave implementation for ARM (which I will be open
>> sourcing), in order to implement some functionality that does not exist in
>> the 1Wire world (multichannel RGBW control).
>>
>> Given the small amount of address space available in the family, I figured
>> the best course of action for further implementations would be to keep the
>> family code, and add a command to allow the master to query the device
>> specifics.
>>
> What is your device emulating? A DS2408? There is some code inside OWFS'
> DS2408 codebase which handles the various HD44780 displays connected to
> the DS2408. It's ugly, it's error-prone and it's hard to debug.
>
> Please don't require us to put even more quirks into the existing driver
> sources.
>
> If you make your own device, please give it its own family code and
> create your own driver source file in the owlib tree. We are going to
> face at most twenty fundamentally different designs of homebrewn devices
> and there's plenty of unused address space for that.
>
> Kind regards
>
>   Jan
>
> --
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, SlashDot.org! http://sdm.link/slashdot
> ___
> Owfs-developers mailing list
> Owfs-developers@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/owfs-developers
>

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
___
Owfs-developers mailing list
Owfs-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/owfs-developers

Re: [Owfs-developers] 85 degree reading means error, readout timing, error should be filtered

[Colin Reese]

If there is no way to distinguish 85 error/power up from 85 valid, you cannot 
filter it. Period. It must all be done on the other side of owfs, and the user 
strategy for this depends on application and expected results. 

You could add flags like last_was_85, or a time stamp last_non_85, but this is 
trivial to do elsewhere. 

> On Jan 8, 2017, at 5:54 AM, Ekkehard Pofahl  wrote:
> 
> Hello,
> 
> I am using OWFS since more than two years in different versions on a Raspi 2. 
> This alone shows, that I think it is a very good program.
> 
> From time to time there is the "85 degree" discussion. It is a clear design 
> flaw of the DS 18xxx chips to sent out a valid temperature reading, when an 
> error code should be sent out.
> 
> Everybody should be aware of the 85 degree flaw and mask it out,
> 
> Previously I thought, 85 degree is only happening, if the power supply is 
> insufficient, or shortly after power-on.
> 
> BUT it seems, that within OWFS there are other ways to read 85 degrees.
> 
> E.g. reading temperature value to quick after conversion command. This has 
> been reported on also Arduino 1-wire software. Or something else ?
> 
> I see the issue with OWFS Version 3.1p1 and 3.1p5. I did not check for other 
> versions or parasite powered DS chips.
> 
> Observation : the error code "85 Grad" is transmitted frequently with the 
> DS18B20.  Only two participants on the bus, stable power supply, no parasite 
> power.
> 
> Open OWFS issues :
> 
> 1) make sure wrong timing is not provoking 85 degree readings on the OWFS 
> server
> 2) filter out 85 degree "somewhere" in OWFS. Otherwise every user of the OWFS 
> server needs to do that filtering.
> 3) do statistics on 85 degree reading
> 
> 
> pi@hsx03:~ $ date
> Thu  5 Jan 17:20:33 CET 2017
> pi@hsx03:~ $ sudo /opt/owfs/bin/owfs --version
> /opt/owfs/bin/owfs version:
> 3.1p5
> libow version:
> 3.1p5
> 
> 
> owhttpd readings :
> 
> 
> top   highest level   directory
> 28.28DBA701   28.28DBA701 directory
> 26.9D46F500   26.9D46F500 directory
> bus.0 bus.0   directory
> 
> uncached version
> updirectory
> address   2828DBA701A3
> alias 
> 
> crc8  A3
> errataerrata
> family28
> fasttemp  85
> id28DBA701
> latesttemp85
> locator   
> power YES (1)
> r_address A301A7DB2828
> r_id  01A7DB28
> r_locator 
> scratchpad
> 50054B467FFF0C101C
> temperature   21.6875
> temperature10 85
> temperature11 21.75
> temperature12 21.6875
> temperature9  85
> temphigh  
> 
> templow   
> 
> tempres   
> 
> type  DS18B20
> 
> 
> 
> temperature   23.0625
> temperature10 85
> temperature11 23.125
> temperature12 23.0625
> temperature9  85
> temphigh  
> 
> templow   
> 
> type  DS18B20
> 
> 
> temperature   23.1875
> temperature10 85
> temperature11 23.1875
> temperature12 23.1875
> temperature9  85
> temphigh  
> 
> templow   
> 
> tempres   
> 
> type  DS18B20
> 
> Sometimes everything is o.k. : 
> 
> scratchpad
> 72014B467FFF0E1057
> temperature   23.125
> temperature10 23.25
> temperature11 23.25
> temperature12 23.125
> temperature9  23.5
> 
> 
> I don't observe this on a DS18S20 :
> 
> 
> scratchpad
> 2E004B460D10C4
> temperature   22.9375
> temphigh  
> 
> templow   
> 
> type  DS18S20
> 
> 
> Best regards
> Ekkehard
> 
> 
> --
> Check out the vibrant tech community on one of the world's most 
> engaging tech sites, SlashDot.org! http://sdm.link/slashdot
> ___
> Owfs-developers mailing list
> Owfs-developers@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/owfs-developers
--
Check out the vibrant tech community on one of the world's most 
engaging tech sites, SlashDot.org! http://sdm.link/slashdot___
Owfs-developers mailing list
Owfs-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/owfs-developers

Re: [Owfs-developers] SS-WALL-TH

[Colin Reese]

I've used (and have) a couple of these, but never used them with owfs. If you 
need a test let me know. 

> On Dec 9, 2016, at 3:48 AM, Nigel Titley  wrote:
> 
> OK, sounds as though no one has. I'll look at doing it myself.
> 
> Thanks
> 
> Nigel
> 
> 
>> On 06/12/16 18:36, Nigel Titley wrote:
>> Has anyone looked at writing code for the SS-WALL-TH from iButtonlink.
>> It's a temp/humidity sensor intended to be embedded into
>> drywall/plasterboard and it uses IBL's smart-slave technology. I'm
>> guessing that it wouldn't be too difficult to do but if anyone has
>> looked at it or made a start then I don't want to duplicate effort. If
>> no one has then a pointer or two of what parts of the code need
>> modifying would be a good starter. I'm a reasonably competent C coder.
>> 
>> Alternatively I'll donate a sensor to anyone who wants to do this.
>> 
>> Thanks
>> 
>> Nigel
>> 
>> 
>> --
>> Developer Access Program for Intel Xeon Phi Processors
>> Access to Intel Xeon Phi processor-based developer platforms.
>> With one year of Intel Parallel Studio XE.
>> Training and support from Colfax.
>> Order your platform today.http://sdm.link/xeonphi
>> ___
>> Owfs-developers mailing list
>> Owfs-developers@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/owfs-developers
> 
> 
> --
> Developer Access Program for Intel Xeon Phi Processors
> Access to Intel Xeon Phi processor-based developer platforms.
> With one year of Intel Parallel Studio XE.
> Training and support from Colfax.
> Order your platform today.http://sdm.link/xeonphi
> ___
> Owfs-developers mailing list
> Owfs-developers@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/owfs-developers
--
Developer Access Program for Intel Xeon Phi Processors
Access to Intel Xeon Phi processor-based developer platforms.
With one year of Intel Parallel Studio XE.
Training and support from Colfax.
Order your platform today.http://sdm.link/xeonphi___
Owfs-developers mailing list
Owfs-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/owfs-developers

Re: [Owfs-developers] Can the owserver be "overloaded"?

[Colin Reese]

Maybe dumb question, but are the additional inputs floating or connected? I 
noticed some interesting behavior on these as well when in use recently. 

Colin


> On Nov 18, 2016, at 1:45 AM, Arne Raaen  wrote:
> 
> Hi,
> 
> I have a HobbyBoards relay card based on DS2408, used with LinkUSB
> 
> I used a routine (unconditionally) updating PIO.0 through PIO.5 every
> minute.
> 
> I observed that PIO.6 and PIO.7 would be activated at random intervals,
> typically a few times per day or less.
> 
> 
> I attempted
> * use all free pairs for a better ground line
> * plug the LinkUSB directly into the HB card
> * change from perl + OWNET to python + pyownet
> 
> Nothing helped reliably.
> 
> I than changed the code to read owserver first, and update only when
> needed, which reduces owserver writes from 6 per minute to a few times
> per day.
> 
> Since then I have not seen any unwanted activation of PIO.6 and PIO.7.
> 
> (Other owserver actvity is reading mainly temperature sensors, every minute)
> 
> 
> 
> 
> 
> Arne
> 
> 
> --
> ___
> Owfs-developers mailing list
> Owfs-developers@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/owfs-developers
--
___
Owfs-developers mailing list
Owfs-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/owfs-developers

Re: [Owfs-developers] New site

[Colin Reese]

I added some things. I show up as Interface Innovations at the moment.

C

On 9/14/2016 12:08 PM, Johan Ström wrote:
> On 14/09/16 10:02, Jan Kandziora wrote:
>
>> Am 14.09.2016 um 07:21 schrieb Johan Ström:
>>> Colin, Jan, Colin, and everyone else: Besides the above, what do you
>>> guys think of the GitHub wiki? Would it be an acceptable way to go
>>> forward? It certainly has a few downsides (mainly lack of structuring,
>>> image uploads), but it's very easy to get started, and no external
>>> hosting required.
>>>
>> I think we should go for it. Having less automation on the github site
>> isn't too bad.
>>
>>
>>> I think I would vote to focus on a single wiki to start with, and
>>> nothing on GH pages besides perhaps welcome-page, very basic info and
>>> pointers to the wiki.. That way we can start to build up all the info on
>>> the wiki, and when we have some nice wiki-pages, we could move it to GH
>>> pages ("the homepage") if we think it makes sense.
>>>
>> Yes, that's the way to go.
> I guess it's decided then! :)
>
>>
>> About the welcome page: Let's start with a page about Onewire in
>> general, then give owfs as *one* of the solutions.
>>
>> A driver hierarchy would help most to structure that page. Not an image,
>> just a table of colored, clickable blocks
>>
>> And are you all okay with a bit uncouth writing style? Because I think
>> it helps loosening up the exact, technical text parts.
> Sounds good! I'll do some cleanup of the current page design to get
> something simple to use, probably using some other theme which isn't
> horizontally limited..
>
>
> To make our presence on Github a bit more "real", I've setup mirroring
> of the sourceforge repo to github:
>
> https://github.com/owfs/owfs
>
> A script on a server of mine updates the repo every 15 minutes, until
> we're ready to do a real move.
>
> I'm hoping Paul will send the list an email acknowledging that he's okay
> with this too, but if we don't hear from him, I vote to continue anyway.
>
> Regards
> Johan
>
> --
> ___
> Owfs-developers mailing list
> Owfs-developers@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/owfs-developers
>

--
___
Owfs-developers mailing list
Owfs-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/owfs-developers

Re: [Owfs-developers] New site

[Colin Reese]

As long as the word uncouth is used. 

When it comes to family codes I have an orphaned page here that may be helpful. 
I'll also be restructuring my site this week. Good timing. 

https://www.interfaceinnovations.org/onewirefamilycodes.html

C



> On Sep 14, 2016, at 1:02 AM, Jan Kandziora  wrote:
> 
>> Am 14.09.2016 um 07:21 schrieb Johan Ström:
>> 
>> Colin, Jan, Colin, and everyone else: Besides the above, what do you
>> guys think of the GitHub wiki? Would it be an acceptable way to go
>> forward? It certainly has a few downsides (mainly lack of structuring,
>> image uploads), but it's very easy to get started, and no external
>> hosting required.
> I think we should go for it. Having less automation on the github site
> isn't too bad.
> 
> 
>> I think I would vote to focus on a single wiki to start with, and
>> nothing on GH pages besides perhaps welcome-page, very basic info and
>> pointers to the wiki.. That way we can start to build up all the info on
>> the wiki, and when we have some nice wiki-pages, we could move it to GH
>> pages ("the homepage") if we think it makes sense.
> Yes, that's the way to go.
> 
> About the welcome page: Let's start with a page about Onewire in
> general, then give owfs as *one* of the solutions.
> 
> A driver hierarchy would help most to structure that page. Not an image,
> just a table of colored, clickable blocks
> 
> And are you all okay with a bit uncouth writing style? Because I think
> it helps loosening up the exact, technical text parts.
> 
> 
> Kind regards
> 
>Jan
> 
> --
> ___
> Owfs-developers mailing list
> Owfs-developers@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/owfs-developers

--
___
Owfs-developers mailing list
Owfs-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/owfs-developers

Re: [Owfs-developers] New site

[Colin Reese]

In this case, owfs and owfs-wiki repos seem to make sense. Would be nice if 
there were a blacklist feature. 

> On Sep 11, 2016, at 10:06 AM, Johan Ström <jo...@stromnet.se> wrote:
> 
>> On 11/09/16 18:55, Colin Reese wrote:
>> I see. I didn't see there was a restricted access list option for the public 
>> wiki.
> Just to be clear:
> 
> Each repository can have it's own wiki.
> A wiki can either be publicly editable ("any github user"), or only 
> editable by repository collaborators ("users in teams with push access").
> 
> Two different repositories (and their accompanying wikis) does not need 
> to have the same list of collaborators (write access).
> 
> 
> --
> ___
> Owfs-developers mailing list
> Owfs-developers@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/owfs-developers

--
___
Owfs-developers mailing list
Owfs-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/owfs-developers

Re: [Owfs-developers] New site

[Colin Reese]

I see. I didn't see there was a restricted access list option for the public 
wiki. 

> On Sep 11, 2016, at 9:46 AM, Johan Ström <jo...@stromnet.se> wrote:
> 
> If we opt for an "any user" wiki it can be attached to the main repo, yes.
> 
> The only(?) reason for detaching it would be have a 
> non-publicy-editable, but with a different access list than the main repo.
> 
> 
>> On 11/09/16 18:39, Colin Reese wrote:
>> Why can't there be an 'any user' wiki attached to the real repo? What has 
>> detaching the wiki solved?
>> 
>>>> On Sep 11, 2016, at 9:18 AM, Johan Ström <jo...@stromnet.se> wrote:
>>>> 
>>>>> On 10/09/16 14:02, Jan Kandziora wrote:
>>>>> Am 10.09.2016 um 11:22 schrieb Colin Law:
>>>>> Is there really a need for two?  Why
>>>>> not just have everything in one?
>>>> Because of access rights. GitHub only allows full developer access to
>>>> anything or no rights at all. Not Wiki-alone.
>>>> 
>>>> We could settle on having an owfs-doc project with a open wiki of course.
>>> For testing, I opened a new owfs-doc repo with a publicly editable wiki.
>>> Feel free to try it out, anyone with a Github account should be able to
>>> edit:
>>> 
>>> https://github.com/owfs/owfs-doc/wiki
>>> 
>>> --
>>> ___
>>> Owfs-developers mailing list
>>> Owfs-developers@lists.sourceforge.net
>>> https://lists.sourceforge.net/lists/listinfo/owfs-developers
>> --
>> ___
>> Owfs-developers mailing list
>> Owfs-developers@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/owfs-developers
> 
> 
> --
> ___
> Owfs-developers mailing list
> Owfs-developers@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/owfs-developers

--
___
Owfs-developers mailing list
Owfs-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/owfs-developers

Re: [Owfs-developers] New site

[Colin Reese]

Why can't there be an 'any user' wiki attached to the real repo? What has 
detaching the wiki solved?

> On Sep 11, 2016, at 9:18 AM, Johan Ström  wrote:
> 
>> On 10/09/16 14:02, Jan Kandziora wrote:
>>> Am 10.09.2016 um 11:22 schrieb Colin Law:
>>> Is there really a need for two?  Why
>>> not just have everything in one?
>> Because of access rights. GitHub only allows full developer access to
>> anything or no rights at all. Not Wiki-alone.
>> 
>> We could settle on having an owfs-doc project with a open wiki of course.
> For testing, I opened a new owfs-doc repo with a publicly editable wiki.
> Feel free to try it out, anyone with a Github account should be able to 
> edit:
> 
> https://github.com/owfs/owfs-doc/wiki
> 
> --
> ___
> Owfs-developers mailing list
> Owfs-developers@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/owfs-developers

--
___
Owfs-developers mailing list
Owfs-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/owfs-developers

Re: [Owfs-developers] New site

[Colin Reese]

I think a distinctly themed user wiki is probably a good idea. A bunch of the 
content there will be useful, but not appropriate for docs. Also, other Colin, 
I can't think of a better way to merge content, e.g. what info I have on the Pi 
with whatever you're writing, than a wysiwyg editor. 

C

> On Sep 10, 2016, at 5:54 AM, Colin Law  wrote:
> 
>> On 10 September 2016 at 11:52, Johan Ström  wrote:
>>> On 10/09/16 12:13, Colin Law wrote:
 On 10 September 2016 at 10:21, Johan Ström  wrote:
 ...
 I suggest the following:
 
 a) For public site, use Github Pages with Jekyll.
 We (the developer community) would use git to push files which are
 rendered & published automatically by github on push.
 If someone is more confortable with the Github online text editor, that
 is possible to. If not a project contributor, you fork first and issue
 pull request.
 
 b) For user-written content, we use a fully open Github Wiki.
 If well written articles are put there, we could opt to either copy them
 to the site, or at least link them.
>>> If I wrote a technical note describing how to interface 1-wire to a Pi
>>> which would that go in, and how would a user looking for it know which
>>> one to look in?
>> Two ways:
>> a) You start to write it on the wiki, and if it is a well written
>> technical note, the developer community approves it and moves it to the
>> site (will probably just be a 1:1 copy of the page), or in some way gets
>> featured on the site.
> 
> Moving it would not be a good idea as then there would be broken links
> to the original around the internet.
> 
>> b) You write it directly for the site by forking the site, writing the
>> note in your own repo, then issue a pull request where we merge your
>> changes into the official site.
>> Mostly based on what you, the writer, is most comfortable with!
>> 
>> To find user-written content, we first make it very obvious (on the
>> site) that we have a wiki with (only) user contributed stuff. If we want
>> to make it more integrated, we could add hooks/scripts to automatically
>> link any wiki pages directly from the site, thereby making it even
>> easier to find.
>> (new wiki page => hook called => script adds link to page => deploys new
>> page => article is now linked directly from site)
>> Might even be possible to show the wiki in an iframe? but probably would
>> be too much clutter..
> 
> That could be a good solution if it worked, so the wiki appears as an
> extension to the main site, and everything is indexed and searched
> from the main site.  Still not sure why an open wiki for everything
> would not be good enough and would be simpler to support.
> 
> Colin
> 
> --
> ___
> Owfs-developers mailing list
> Owfs-developers@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/owfs-developers

--
___
Owfs-developers mailing list
Owfs-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/owfs-developers

Re: [Owfs-developers] New site

[Colin Reese]

Well, I have to say that the site looks outdated and is difficult to navigate. 
It does not make it easy to get information that appears useful or 
authoritative. When I was new to owfs, I could not find even the basic 
information I needed to explain how owfs and owserver interact. The best 
information is found through searching listserv entries indexed by Google. This 
is a statement in itself to the ineffectiveness of the site and additionally to 
the important of improving the form of it. 

Colin


> On Sep 9, 2016, at 5:00 PM, Jan Kandziora  wrote:
> 
>> Am 08.09.2016 um 22:32 schrieb Johan Ström:
>> 
>> .. what else?
> First: I'd love to get rid of are these personal blogs who give stray
> information bites which are quickly outdated and totally out of control.
> This is the source of most misfortune for owfs users. I'm pretty sure
> only 1 of 10 shows up here at the mailing list and ask us. Nine of ten
> people will give up or just live with their brittle setup.
> 
> 
> I have to admit: I personally hate those people who endlessly copypaste
> that blurb about using a pullup of 4.7k to 5V on the Raspberry Pi GPIO4.
> 
> The simple reason people can tell this is because... the authoritative
> source of information... our site... had nothing about this. Or at
> least, it's covered by layers and layers of owfs internals which sound
> like nonsense to anybody but us developers.
> 
> 
> Same with using the FUSE binding. People endlessly copypaste blurbs
> about using the FUSE binding.
> 
> We really, really should say people: Hey, we have a FUSE binding, it's a
> nice technical demo. But it turned out using FUSE for pseudofilesystems
> is a bad idea because of race conditions so... don't do that. Forget
> that thing exists. Thank you.
> 
> 
> The SWIG bindings, our next construction site. People usually *don't*
> know there are at least three python bindings to owfs for example, with
> the best one OFF-SITE. Or what the difference between owlib, owcapi and
> ownet is.
> 
> 
> And our zoo of host adapter options has to be explained. Simply. When to
> use which host adapter.
> 
> 
> And we should make people interested in owfs look right and left, too.
> The w1 kernel driver can make them happy, too (for example for using the
> DS28E17). The owfs external mechanism on the other hand can be used to
> put GPIOs into OWFS, which makes owserver some sort of Network I/O
> expander. And the two can be combined, making arbitrary I²C sensors into
> network-enabled owfs nodes with very little userspace code.
> 
> 
>> 
>> Jan, your last lines talked about alternative to push/pull content. A 
>> github hosted page could actually be edited directly in the github UI, 
>> there is a Edit button which opens an editor directly. You'd of course 
>> have to fork it first, and you still need to do basic markup.
>> But if instructed how to do it, is that too advanced?
> Not too advanced.
> 
> My concern was: For end users, the biggest hurdle would be additional
> software. They usually don't care about the markup, we have to fix that.
> 
> We need to have a documentation project where end users can easily edit
> pages and we have bit of control about what is written there, so
> outdated and wrong information cannot live forever. That's why I want to
> encourage end users to document their owfs related stuff at a central
> site. So we can maintain it.
> 
> This should be seperated from "official" documentation but in a way the
> difference is only sublime. So people see "Hey, my owfs project is
> recognized by the owfs people. Great!"
> 
> 
> So, having two wikis, one along the official sources and one for end
> users would be great.
> 
> I think we can push wiki pages created from manpages etc. so this will
> make Colin and Stefano happy too, I think.
> 
> 
> Okay? Can we settle on this? Or continue discussion?
> 
> Kind regards
> 
>Jan
> 
> 
> 
> 
> 
> 
> 
> 
> --
> ___
> Owfs-developers mailing list
> Owfs-developers@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/owfs-developers

--
___
Owfs-developers mailing list
Owfs-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/owfs-developers

Re: [Owfs-developers] New site

[Colin Reese]

> On Sep 8, 2016, at 2:53 AM, Stefano Miccoli  wrote:
> 
> 
>> On 08 Sep 2016, at 10:20, Jan Kandziora  wrote:
>> 
>> Face it, simple markup alone will not give you any contributors. Hell,
>> non-developer documentation contributors don't want to bother with
>> markup at all!
>> 
>> What we need is an interface that makes it easy for *anyone* to
>> contribute to the documentation. If we don't have that, we could just
>> stick to HTML.
> 
> Sorry, but I **strongly** disagree: html if you don’t use some form of 
> template engine is not sustainable

Agreed. I wouldn't touch it. 

Also, lost the piece on how it looks, but this is 2016 and there is no excuse 
for not having a cleanly styled and mobile-friendly site. It affects usability. 
Is owfs from 1985 or today?

> Suppose you have 200+ pages, and you need to add a single row in the footer: 
> should you open all the 200 html files by hand and add the html markup? 
> Should you write a bash+sed+m4 script and programmatically change all the 
> files? Or should you just change a single line in a template file and have 
> some processor regenerate the whole site?
> 
> The real question here is not about having hundreds of contributors hacking 
> docs with an WYSIWYG on-line editor. Our problem is to use a technology which 
> allows us tho **efficiently** build a decent new owfs.org site.

I actually think media wiki is a pretty good model, hosting issues 
notwithstanding. See below. 

> 
> My personal list of important requirements. The new site should be
> 
> 1) static and integrated with git (push to publish)

I like git very much, but having to learn it to contribute to a community 
maintained page is a pretty large barrier. I use it from the CL, but I've heard 
the desktop app is not good. 

> 2) future proof (ability to integrate new web technologies as they appear)
> 3) based on templates
> 4) allow for easy inclusion of html and css
> 5) be very lightweight as what regards maintenance.
> 
> You guessed it, I wrote the above list with jekyll in mind :-))
> 
> I use both jekyll and Sphinx: while Sphinx is the way to go for python or C 
> docs (http://pyownet.readthedocs.io/en/latest/) it is not flexible enough for 
> owfs.org, which should be a little more than a bunch of docs.
> 
> So consider jekyll https://jekyllrb.com as a system based on
> 
> * Markdown: a lightweight markup language, which is much more than *simple* 
> markup. 
> * Liquid, which is a template engine
> * plain old html and css (you are not forced to use markdown or templates… a 
> jekyll site could also be 100% html+css)
> 
> As a bonus with jekyll you get seamless integration into github (but NO 
> vendor lock-in since it is fully open source), free hosting on 
> pages.guthub.com, rouge syntax highlighting…
> 
> Stefano
> --
> ___
> Owfs-developers mailing list
> Owfs-developers@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/owfs-developers
--
___
Owfs-developers mailing list
Owfs-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/owfs-developers

Re: [Owfs-developers] New site

[Colin Reese]

Here is an example of pages made using Sphinx:

https://pgm.readthedocs.io/en/develop/

C

> On Sep 7, 2016, at 11:29 PM, Johan Ström <jo...@stromnet.se> wrote:
> 
>> On 08/09/16 00:13, Colin Reese wrote:
>> What are the cons for a github-hosted wiki again?
> Well, my only objection would be that it is a third party, but since
> "we" don't really have a proper organization or funding or anything like
> that which would naturally be able to "run it ourselfs", every solution
> would become a third party in any way...
> So, no, I don't have any cons for Github.
>> 
>> It really seems to make sense to have all of the source and the how-to 
>> hosted in one place, in an easy to use and modify format. Admin and 
>> source control is easy to use (it is designed for it, after all), 
>> managed, and attached to the repo for owfs itself. This really seems 
>> like the obvious solution to me.
>> 
>> https://help.github.com/articles/about-github-wikis/
> It should be noted that Github wikis and Github pages are two different
> things:
> 
> The Github wiki is inline in the repo UI, and features a basic WYSIWYG
> editor (seems to support multiple markup methods). Either contributors
> can edit, or all can edit, directly on site.
> It doesn't seem easy to do vetting of edits though, i.e. "pull requests"
> from contributors. Either you allow *everyone* to edit the wiki, or only
> project collaborators (who can also commit code I guess?). It *is*
> possible to manually handle the wiki as a git repo, and do merges that
> way, but not via Github UI.
> 
> The Github pages are just static files commited to a GIT repo, which are
> then presented standalone (no github UI) on xxx.github.io (custom domain
> supported too).
> For pages, you *can* use the built-in preprocessing framework Jekyll. I
> tried it out a bit yesterday, you just commit static files the same way,
> but you can create separate layout files and do some automatic
> processing such as iterate files in a directory, or data structures etc,
> and produce appropriate output. So, html/markdown/"jekyll code"/others
> as input, html as output (which is shown on xxx.github.io).
> Quite powerful, but requires some manual work. There is no web editor,
> so you must clone the repo and edit it locally, making the threshold to
> contribute a bit higher.
> 
> So both have pros and cons.. Regardless of which one we find most
> suiting, I'd say we should keep all info in *one* place, and just use
> the other for pointing to the first place. Don't have half of the info
> in pages and wiki.. Or...? Perhaps basic info & best practices on Page,
> and have non-collaborator contributions on wiki, where articles evolve
> into best practices, which goes to the site?
>> 
>> Colin
>> 
>> 
>>> On 9/7/2016 3:03 PM, Jan Kandziora wrote:
>>>> Am 07.09.2016 um 21:23 schrieb Johan Ström:
>>>> Pro:
>>>> - would be able to properly version it in git
>>>> - Could integrate with automatic build on push, using pull requests for
>>>> contribution etc.
>>>> - static is simple
>>>> Cons:
>>>> - Depending on how it's implemented, it could be trickier to contribute.
>>>> But most contributors are probably somewhat tech-savvy anyway..
>>> If we use "simple" markup, we have to pick a person who extends the
>>> "simple" markup as needed. I don't like the idea of not being able to
>>> draw a table in a certain way or arrange text around an image just
>>> because the "simple" markup does not support what I need.
> It's nice to be flexible, but to what extent? Are there any formatting
> languages supporting this, that is not manual HTML? I would not want to
> do manual HTML for the overall content, just because we need special
> tables in once place.
> If we go with GH Wiki, their markdown seems to support inline HTML. If
> we go with GH Pages, we can do whatever we want.
>>> 
>>> In reality, we don't need this "simple" markup when all the people who
>>> are contributing to the documentation are developers.
> If I understand you correct, you want something more powerful, perhaps
> HTML or other? If so, I don't agree. Its not about making it simple for
> computer-illiterate people to contribute, it's making it easy for *us*
> to write docs and not have to worry about writing verbose HTML around
> everything to make it readable.
>>> 
>>> It's either user+developers, then cms/wiki is the way to go, or plain
>>> old html files, with some preprocessing to put each article into a
>>> c

Re: [Owfs-developers] New site

[Colin Reese]

What are the cons for a github-hosted wiki again?

It really seems to make sense to have all of the source and the how-to 
hosted in one place, in an easy to use and modify format. Admin and 
source control is easy to use (it is designed for it, after all), 
managed, and attached to the repo for owfs itself. This really seems 
like the obvious solution to me.

https://help.github.com/articles/about-github-wikis/

Colin


On 9/7/2016 3:03 PM, Jan Kandziora wrote:
> Am 07.09.2016 um 21:23 schrieb Johan Ström:
>>
>> Pro:
>> - would be able to properly version it in git
>> - Could integrate with automatic build on push, using pull requests for
>> contribution etc.
>> - static is simple
>> Cons:
>> - Depending on how it's implemented, it could be trickier to contribute.
>> But most contributors are probably somewhat tech-savvy anyway..
>>
> If we use "simple" markup, we have to pick a person who extends the
> "simple" markup as needed. I don't like the idea of not being able to
> draw a table in a certain way or arrange text around an image just
> because the "simple" markup does not support what I need.
>
> In reality, we don't need this "simple" markup when all the people who
> are contributing to the documentation are developers.
>
> It's either user+developers, then cms/wiki is the way to go, or plain
> old html files, with some preprocessing to put each article into a
> common frame, suppling breadcrumbs and a table of contents
> automatically. All inbetween will gives us a headache.
>
>
>>
>> I'm going to lift a followup question: should we stay on sourceforge?
>> Even if Github may be hyped and nowadays used by every granny and her
>> cat, it *is* a lot better than Sourceforge when it comes to git.. and
>> everything around it..
>> We would certainly not be the first project to leave SF.. They may not
>> yet have covertly bundled installers and what not with owfs, but who
>> knows..
>> (http://www.infoworld.com/article/2931753/open-source-software/sourceforge-the-end-cant-come-too-soon.html).
>>
> I have some old projects at sourceforge but yes, I've started new
> projects on github only since some years ago. I would never again begin
> a new project on sf.net.
>
> Why? Because sf.net is the yahoo of software. Totally bloated and full
> of bells and whistles you don't want, with the main functions
> complicated and brittle.
>
>
>
>> I haven't looked at github pages much more than during writing message,
>> but something like this is tempting:
>> * Move project to github: git hosting, issue handling, pull requests.
>> * Setup new github pages, automatically built by pushing to either main
>> repo or a separate site repo. If we juse sphinx,  jekyll, or plain
>> markdown, or something else, I don't know.
>> * Handle contributions to docs and source the same way: pull requests
>>
>> Github could thus handle: GIT, basic descriptions, issues, pull
>> requests, pages (site), releases.
>> However, not mailinglist. We could keep that at sourceforge though.
>>
> I would like to consolidate the ways to report problems and bugs. It's a
> bit tedious to have this at so many locations. Sourceforge does a
> terrible job translating between the different interfaces.
>
> Any good plan how to migrate this? What should the mailing list be good
> for in the future? Developers only? If yes, who is taking care for
> people reporting problems and bugs on the github tracker?
>
>
>> (as it happens, I just created https://github.com/owfs. If we're not
>> going to use it, then at least so no-one else can steal it.. :))
>>
> Fine. Please add me (ianka) to the organisation.
>
>
>>> If we had to rewrite from scratch, that would be an awful lot of work.
>> That it would indeed.. But at the same time, we would need to go through
>> everything and clean out a lot of old/bad examples anyway. I'd say,
>> unless we're to keep the old site totally, we need to go through all
>> pages and move/filter the content.
>>
> This, yes. My concern was about authorship and copyright mostly.
> "© Copyright 2003-2016 - OWFS website" isn't a good thing to start with.
>
>
> Kind regards
>
>   Jan
>
> --
> ___
> Owfs-developers mailing list
> Owfs-developers@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/owfs-developers
>

--
___
Owfs-developers mailing list
Owfs-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/owfs-developers

Re: [Owfs-developers] Problem with owserver not starting at boot on raspbian jessie

[Colin Reese]

There's a GPIO you can read for undervoltage. 35 IIRC. 

> On Aug 25, 2016, at 7:35 AM, Nigel Titley  wrote:
> 
> 
> 
>> On 25/08/16 15:27, Jan Kandziora wrote:
>>> Am 25.08.2016 um 16:07 schrieb Nigel Titley:
>>> 
 On 25/08/16 13:47, Matthias Urlichs wrote:
> On 25.08.2016 14:38, Nigel Titley wrote:
> This is a possibility and it had crossed my mind that this might be the
> issue but it doesn't explain why a subsequent attempt to start it from
> the command line fails.
 I had that problem on one of my Raspberry Pi systems.
 
 The issue went away after I changed the power supply.
 
>>> Hmm, that's an interesting approach. I can certainly try it, although
>>> it's an official 2.5A Pi PSU
>>> 
>> Check if you have the little colored square in the top right corner of
>> the screen. That's what the GPU inescapably displays when it thinks the
>> voltage isn't high enough or too unstable. Problem may be the cable, not
>> the power supply itself.
>> 
> It's running headless. I'll measure the voltage though and I've got
> alternative known-good power supplies.
> 
> Nigel
> 
> --
> ___
> Owfs-developers mailing list
> Owfs-developers@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/owfs-developers

--
___
Owfs-developers mailing list
Owfs-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/owfs-developers

Re: [Owfs-developers] Turning OWFS website into a Wiki. Was: owfs is DISABLED

[Colin Reese]

Yes. I have content to contribute. 

> On Jul 26, 2016, at 1:18 AM, Jan Kandziora  wrote:
> 
>> Am 26.07.2016 um 08:36 schrieb Martin Patzak (GMX):
>> who else thinks the following should find it's way onto the owfs web-site?
> Guys, face it: Paul Alfille has GONE. I hope he's okay, doing family
> business, something like that. But I'm afraid he will not come back and
> tidy up things in any case.
> 
> We are a bit disorganised because of this at the moment.
> 
> 
> If I had to decide, I would take all the content of the web site, throw
> out all the out-of-date information and feed the rest into a Mediawiki,
> where you and others can maintain it yourself. Then shutdown the old
> website.
> 
> 
> OWFS developers, OWFS users: should we do that?
> 
> 
> Kind regards
> 
>Jan
> 
> --
> What NetFlow Analyzer can do for you? Monitors network bandwidth and traffic
> patterns at an interface-level. Reveals which users, apps, and protocols are 
> consuming the most bandwidth. Provides multi-vendor support for NetFlow, 
> J-Flow, sFlow and other flows. Make informed decisions using capacity planning
> reports.http://sdm.link/zohodev2dev
> ___
> Owfs-developers mailing list
> Owfs-developers@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/owfs-developers

--
What NetFlow Analyzer can do for you? Monitors network bandwidth and traffic
patterns at an interface-level. Reveals which users, apps, and protocols are 
consuming the most bandwidth. Provides multi-vendor support for NetFlow, 
J-Flow, sFlow and other flows. Make informed decisions using capacity planning
reports.http://sdm.link/zohodev2dev
___
Owfs-developers mailing list
Owfs-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/owfs-developers

Re: [Owfs-developers] Datanab MAX31850 reading

[Colin Reese]

Ok I'm on 2.9.5. I'll update. I figured that the module you wrote was low level 
stuff but apparently I don't know what does what. 

C

> On Jun 30, 2016, at 7:34 PM, Paul W Panish <ppan...@panishnet.com> wrote:
> 
> It looks like Paul submitted my changes in v2.9p6. Support for the 
> MAX31850 was added in v2.9p2. Not sure what you're saying beyond this, 
> and I haven't worked with the scratchpad registers.
> 
> When I modified this code I basically performed a dump of the data 
> available in the ow_1820.c module to find which data structure held the 
> correct information for the hot junction temperature. I then modified 
> the code to present this data on a "temperature" query. Two years later 
> I don't really remember the specifics.
> 
> If you're running a version prior to 2.9p6 I'd suggest you update at 
> least that far and give it a try.
> 
> Colin Reese wrote:
>> In what rev were these made? I'm on 2.9 I believe and neither make sense.
>> 
>> What is the possibility that scratchpad gets read wrong? I have no 
>> visibility into the code but the faults I am observing are suspect, 
>> considering everything reads fine using tmex.
>> 
>> 
>>> On Jun 30, 2016, at 3:58 AM, Paul W Panish<ppan...@panishnet.com>  wrote:
>>> 
>>> Sure, sorry I can't be of more help at the moment.
>>> 
>>> To be clear, with the changes I made, which were done empirically, I was 
>>> able to read the hot junction thermocouple temperature using the  
>>> "temperature" access string on the MAX31850 development board I had 
>>> purchased. It also read properly with the different resolution access 
>>> strings, "temperature9", "temperature10"...
>>> 
>>> As I recall, without the two code changes I made, the value returned by 
>>> "temperature" made no sense for either the cold or hot junction. I don't 
>>> think I checked what "thermocouple" returned, but it's not clear to me from 
>>> my email exactly what experiments I performed.
>>> 
>>> Paul W Panish
>>> Mobile: (603) 343-8901
>>> 
>>>>> On Jun 30, 2016, at 04:56, Jan Kandziora<j...@gmx.de>  wrote:
>>>>> 
>>>>> Am 29.06.2016 um 23:51 schrieb Paul W Panish:
>>>>> All,
>>>>> 
>>>>> I just realized the attachment from my email to Paul Alfille wouldn't
>>>>> be readable for anyone not using Postbox on a Mac. Here's a copy of
>>>>> the text, sorry about the bad formatting:
>>>> Thanks for the reply, Paul.
>>>> 
>>>> I try to understand all this first.
>>>> 
>>>> Kind regards
>>>> 
>>>>   Jan
>>> --
>>> Attend Shape: An AT Tech Expo July 15-16. Meet us at AT Park in San
>>> Francisco, CA to explore cutting-edge tech and listen to tech luminaries
>>> present their vision of the future. This family event has something for
>>> everyone, including kids. Get more information and register today.
>>> http://sdm.link/attshape
>>> ___
>>> Owfs-developers mailing list
>>> Owfs-developers@lists.sourceforge.net
>>> https://lists.sourceforge.net/lists/listinfo/owfs-developers
>> 
>> --
>> Attend Shape: An AT Tech Expo July 15-16. Meet us at AT Park in San
>> Francisco, CA to explore cutting-edge tech and listen to tech luminaries
>> present their vision of the future. This family event has something for
>> everyone, including kids. Get more information and register today.
>> http://sdm.link/attshape
>> ___
>> Owfs-developers mailing list
>> Owfs-developers@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/owfs-developers
> 
> --
> Attend Shape: An AT Tech Expo July 15-16. Meet us at AT Park in San
> Francisco, CA to explore cutting-edge tech and listen to tech luminaries
> present their vision of the future. This family event has something for
> everyone, including kids. Get more information and register today.
> http://sdm.link/attshape
> ___
> Owfs-developers mailing list
> Owfs-developers@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/owfs-developers

--
Attend Shape: An AT Tech Expo July 15-16. Meet us at AT Park in San
Francisco, CA to explore cutting-edge tech and listen to tech luminaries
present their vision of the future. This family event has something for
everyone, including kids. Get more information and register today.
http://sdm.link/attshape
___
Owfs-developers mailing list
Owfs-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/owfs-developers

Re: [Owfs-developers] Datanab MAX31850 reading

[Colin Reese]

In what rev were these made? I'm on 2.9 I believe and neither make sense. 

What is the possibility that scratchpad gets read wrong? I have no visibility 
into the code but the faults I am observing are suspect, considering everything 
reads fine using tmex. 


> On Jun 30, 2016, at 3:58 AM, Paul W Panish  wrote:
> 
> Sure, sorry I can't be of more help at the moment. 
> 
> To be clear, with the changes I made, which were done empirically, I was able 
> to read the hot junction thermocouple temperature using the  "temperature" 
> access string on the MAX31850 development board I had purchased. It also read 
> properly with the different resolution access strings, "temperature9", 
> "temperature10"... 
> 
> As I recall, without the two code changes I made, the value returned by 
> "temperature" made no sense for either the cold or hot junction. I don't 
> think I checked what "thermocouple" returned, but it's not clear to me from 
> my email exactly what experiments I performed. 
> 
> Paul W Panish
> Mobile: (603) 343-8901
> 
>>> On Jun 30, 2016, at 04:56, Jan Kandziora  wrote:
>>> 
>>> Am 29.06.2016 um 23:51 schrieb Paul W Panish:
>>> All,
>>> 
>>> I just realized the attachment from my email to Paul Alfille wouldn't
>>> be readable for anyone not using Postbox on a Mac. Here's a copy of
>>> the text, sorry about the bad formatting:
>> Thanks for the reply, Paul.
>> 
>> I try to understand all this first.
>> 
>> Kind regards
>> 
>>   Jan
> 
> --
> Attend Shape: An AT Tech Expo July 15-16. Meet us at AT Park in San
> Francisco, CA to explore cutting-edge tech and listen to tech luminaries
> present their vision of the future. This family event has something for
> everyone, including kids. Get more information and register today.
> http://sdm.link/attshape
> ___
> Owfs-developers mailing list
> Owfs-developers@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/owfs-developers

--
Attend Shape: An AT Tech Expo July 15-16. Meet us at AT Park in San
Francisco, CA to explore cutting-edge tech and listen to tech luminaries
present their vision of the future. This family event has something for
everyone, including kids. Get more information and register today.
http://sdm.link/attshape
___
Owfs-developers mailing list
Owfs-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/owfs-developers

Re: [Owfs-developers] Datanab MAX31850 reading

[Colin Reese]

DS9490R yields similar results. This time only a ground short is 
observed. Again, this seemed to read fine into a DS9490R using the TMEX 
API through LabVIEW.

Looking at the two datasheets, there is no way to avoid device-dependent 
code. There need to be three distinct values: temperature, 
tctemperature, and tcjctemperature.

The reason for this is that the temperature in bytes 0-1 is formatted 
differently in the MSB. See below for summary for temp (DS1825) and 
CJC-compensated temp:

Bit / DS1825 / MAX31850
0 - 2^-4 - Fault
1 - 2^-3 - Reserved
2 - 2^-2 - 2^-2
3 - 2^-1 - 2^-1
4 - 2^0 - 2^0
5 - 2^1 - 2^1
6 - 2^2 - 2^2
7 - 2^3 - 2^3

8 - 2^4 - 2^4
9 - 2^5 - 2^5
10 - 2^6 - 2^6
11 - S - 2^7
12 - S - 2^8
13 - S -2^9
14 - S - 2^10
15 - S - S

Thus, you need to know whether you are looking for a value interpreted 
as a DS1825 or as a MAX31850. Because they are indistinguishable from 
software, you'd just know which one to read. This is the way that I 
wrote the routine on the LabVIEW program I wrote using TMEX API. You 
just have to know which value to read.

Still, even with this, I cannot match up the value being read with owfs 
with either interpretation. A hex dump of the scratchpad, for example, 
gives me:

e9 00 f2 0e ff ff ff ff 29

Big endian, LSB MSB
e9 00 = 11101001 0010

This gives me -14.5625 for a DS1825 and 14.5 for a 31850.

For bytes 2-3:
f2 0e 0010 1110

This gives me 14.9375 for a 31850, with a ground short fault.

Values read by owfs are 0.875 for temp and 236 for thermocouple.

So ... should I just read the scratchpad and do my own conversion, or 
can someone rewrite this?

Colin








On 6/29/2016 1:49 PM, Jan Kandziora wrote:
> Am 29.06.2016 um 21:56 schrieb Colin Reese:
>> I just pulled off the hex and noted short VDD and also ground short
>> faults. These also showed up in owfs. I'm waiting on a scratchpad
>> dump from onewireviewer, but how is this even possible? The device is
>> both prebuilt commercially and also reads fine into a DS9490R. Is the
>> data being read incorrectly into owfs?
>>
> My next check would be with the DS9490R and owfs.
>
> Kind regards
>
>   Jan
>
> --
> Attend Shape: An AT Tech Expo July 15-16. Meet us at AT Park in San
> Francisco, CA to explore cutting-edge tech and listen to tech luminaries
> present their vision of the future. This family event has something for
> everyone, including kids. Get more information and register today.
> http://sdm.link/attshape
> ___
> Owfs-developers mailing list
> Owfs-developers@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/owfs-developers
>

--
Attend Shape: An AT Tech Expo July 15-16. Meet us at AT Park in San
Francisco, CA to explore cutting-edge tech and listen to tech luminaries
present their vision of the future. This family event has something for
everyone, including kids. Get more information and register today.
http://sdm.link/attshape
___
Owfs-developers mailing list
Owfs-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/owfs-developers

Re: [Owfs-developers] Datanab MAX31850 reading

[Colin Reese]

Indeed. Unfortunately onewireviewer won't even give me raw scratchpad data. 

It seems to me that since the temperature (ds1825) and CJC compensated 
temperature (31850) are in the same place (bytes 0-1) they should both be 
delivered to 'temperature' and CJC (1-2) should be in an auxiliary location. 

C

> On Jun 29, 2016, at 1:49 PM, Jan Kandziora <j...@gmx.de> wrote:
> 
>> Am 29.06.2016 um 21:56 schrieb Colin Reese:
>> I just pulled off the hex and noted short VDD and also ground short 
>> faults. These also showed up in owfs. I'm waiting on a scratchpad
>> dump from onewireviewer, but how is this even possible? The device is
>> both prebuilt commercially and also reads fine into a DS9490R. Is the
>> data being read incorrectly into owfs?
> My next check would be with the DS9490R and owfs.
> 
> Kind regards
> 
>Jan
> 
> --
> Attend Shape: An AT Tech Expo July 15-16. Meet us at AT Park in San
> Francisco, CA to explore cutting-edge tech and listen to tech luminaries
> present their vision of the future. This family event has something for
> everyone, including kids. Get more information and register today.
> http://sdm.link/attshape
> ___
> Owfs-developers mailing list
> Owfs-developers@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/owfs-developers

--
Attend Shape: An AT Tech Expo July 15-16. Meet us at AT Park in San
Francisco, CA to explore cutting-edge tech and listen to tech luminaries
present their vision of the future. This family event has something for
everyone, including kids. Get more information and register today.
http://sdm.link/attshape
___
Owfs-developers mailing list
Owfs-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/owfs-developers

Re: [Owfs-developers] Datanab MAX31850 reading

[Colin Reese]

I just pulled off the hex and noted short VDD and also ground short 
faults. These also showed up in owfs. I'm waiting on a scratchpad dump 
from onewireviewer, but how is this even possible? The device is both 
prebuilt commercially and also reads fine into a DS9490R. Is the data 
being read incorrectly into owfs?

Thanks,
Colin


On 6/29/2016 12:03 PM, Colin Reese wrote:
> Hello all,
>
> I have a Datanab TC to 1Wire that uses a MAX31850:
>
> http://www.datanab.com/sensors/1wire-%20thermocouple-sensor-thrmcpl_k.php
>
> The device reads fine using a DS9490R on Windows using a package I have
> written to read the device as in the datasheet (OneWire Viewer does not
> read temperature on the 31850).
>
> Using a DS2483 on owfs, I get some weird stuff. According to the man
> page here (http://owfs.org/uploads/DS1825.html), the temperature should
> give CJC, and thermocouple should give CJC-compensated temperature.
> These values are as follows (owfs is mounted in Celsius):
>
> Temp (CJT): -1.75
> TC:  417
>
> Clearly something is amiss. Moving the 1Wire connection without touching
> the TC gives:
>
> CJC: 22C
> TC: 55C
>
> Ideas?
>
> Thanks,
> Colin
>
>

--
Attend Shape: An AT Tech Expo July 15-16. Meet us at AT Park in San
Francisco, CA to explore cutting-edge tech and listen to tech luminaries
present their vision of the future. This family event has something for
everyone, including kids. Get more information and register today.
http://sdm.link/attshape
___
Owfs-developers mailing list
Owfs-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/owfs-developers

[Owfs-developers] Datanab MAX31850 reading

[Colin Reese]

Hello all,

I have a Datanab TC to 1Wire that uses a MAX31850:

http://www.datanab.com/sensors/1wire-%20thermocouple-sensor-thrmcpl_k.php

The device reads fine using a DS9490R on Windows using a package I have 
written to read the device as in the datasheet (OneWire Viewer does not 
read temperature on the 31850).

Using a DS2483 on owfs, I get some weird stuff. According to the man 
page here (http://owfs.org/uploads/DS1825.html), the temperature should 
give CJC, and thermocouple should give CJC-compensated temperature. 
These values are as follows (owfs is mounted in Celsius):

Temp (CJT): -1.75
TC:  417

Clearly something is amiss. Moving the 1Wire connection without touching 
the TC gives:

CJC: 22C
TC: 55C

Ideas?

Thanks,
Colin



--
Attend Shape: An AT Tech Expo July 15-16. Meet us at AT Park in San
Francisco, CA to explore cutting-edge tech and listen to tech luminaries
present their vision of the future. This family event has something for
everyone, including kids. Get more information and register today.
http://sdm.link/attshape
___
Owfs-developers mailing list
Owfs-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/owfs-developers

Re: [Owfs-developers] Rookie Mistake

[Colin Reese]

Yeah you need to have a breakout and solder skills. I was going to mention this 
but you'd already ordered them. 

C

> On Jun 18, 2016, at 7:19 PM, Peter Hollenbeck  wrote:
> 
> I bought 4 DS2483R ICs from DigiKey, two bucks each.
> I thought I was getting something I could work with. Hah!
> 
> If anyone in Canada can use them I will mail them gratis.
> In mid July I can mail them to anyone in the U.S.
> 
> Peter
> --
> What NetFlow Analyzer can do for you? Monitors network bandwidth and traffic
> patterns at an interface-level. Reveals which users, apps, and protocols are 
> consuming the most bandwidth. Provides multi-vendor support for NetFlow, 
> J-Flow, sFlow and other flows. Make informed decisions using capacity planning
> reports. http://sdm.link/zohomanageengine
> ___
> Owfs-developers mailing list
> Owfs-developers@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/owfs-developers

--
What NetFlow Analyzer can do for you? Monitors network bandwidth and traffic
patterns at an interface-level. Reveals which users, apps, and protocols are 
consuming the most bandwidth. Provides multi-vendor support for NetFlow, 
J-Flow, sFlow and other flows. Make informed decisions using capacity planning
reports. http://sdm.link/zohomanageengine
___
Owfs-developers mailing list
Owfs-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/owfs-developers

Re: [Owfs-developers] AB Electronics

[Colin Reese]

I second the ds2483. Incredibly cheap and reliable. 

> On Jun 13, 2016, at 2:43 AM, Jan Kandziora  wrote:
> 
>> Am 13.06.2016 um 04:11 schrieb Peter Hollenbeck:
>> This article:
>> https://www.packtpub.com/books/content/raspberry-pi-and-1-wire
>> suggests using a 1-Wire DS2482-100 bridge from AB Electronics to connect to
>> a DS18B20.
> This board is an overly complex design. The DS2483 onewire host chip
> will work on a 3.3V I²C bus and gives you a 5V onewire at the same time.
> External circuit: two resistors.
> 
> If you only want to connect a single DS18B20, the cheap solution
> of connecting it (and a 1k pullup to 3.3V) to GPIO4 is sufficient.
> 
> Kind regards
> 
>Jan
> 
> --
> What NetFlow Analyzer can do for you? Monitors network bandwidth and traffic
> patterns at an interface-level. Reveals which users, apps, and protocols are 
> consuming the most bandwidth. Provides multi-vendor support for NetFlow, 
> J-Flow, sFlow and other flows. Make informed decisions using capacity 
> planning reports. https://ad.doubleclick.net/ddm/clk/305295220;132659582;e
> ___
> Owfs-developers mailing list
> Owfs-developers@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/owfs-developers

--
What NetFlow Analyzer can do for you? Monitors network bandwidth and traffic
patterns at an interface-level. Reveals which users, apps, and protocols are 
consuming the most bandwidth. Provides multi-vendor support for NetFlow, 
J-Flow, sFlow and other flows. Make informed decisions using capacity 
planning reports. https://ad.doubleclick.net/ddm/clk/305295220;132659582;e
___
Owfs-developers mailing list
Owfs-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/owfs-developers

Re: [Owfs-developers] Cable Length

[Colin Reese]

To clarify, I want a rating, not a statement from the vendor such as 
"water-resistant", which can mean anything. 

> On Jun 9, 2016, at 11:45 AM, Steinar Midtskogen <stei...@latinitas.org> wrote:
> 
> Colin Reese <colin.re...@gmail.com> writes:
> 
>> You have a source for ip rated with screw terminals? I never found
>> one. I looked at xlr some time ago and was unsatisfied with what I
>> found. Another equipment vendor I know uses them, but 'pretty
>> waterproof' is insufficient for an end-user product if I sell it on.
> 
> It's been so many years since I researched this, and I haven't inspected
> the switchbox on my roof in years, so I can't even quite remember what
> type I have.
> 
> Try to google for "XLR IP67".  But IP67 is just "pretty waterproof".  If
> you need connectors that stay submerged in water, you need IP68.  Try
> search for "XLR IP68".
> 
> -- 
> Steinar
> 
> --
> What NetFlow Analyzer can do for you? Monitors network bandwidth and traffic
> patterns at an interface-level. Reveals which users, apps, and protocols are 
> consuming the most bandwidth. Provides multi-vendor support for NetFlow, 
> J-Flow, sFlow and other flows. Make informed decisions using capacity 
> planning reports. https://ad.doubleclick.net/ddm/clk/305295220;132659582;e
> ___
> Owfs-developers mailing list
> Owfs-developers@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/owfs-developers

--
What NetFlow Analyzer can do for you? Monitors network bandwidth and traffic
patterns at an interface-level. Reveals which users, apps, and protocols are 
consuming the most bandwidth. Provides multi-vendor support for NetFlow, 
J-Flow, sFlow and other flows. Make informed decisions using capacity 
planning reports. https://ad.doubleclick.net/ddm/clk/305295220;132659582;e
___
Owfs-developers mailing list
Owfs-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/owfs-developers

Re: [Owfs-developers] Cable Length

[Colin Reese]

Ip65 is fine. All rated that well are solder connectors that I found. 
Inconvenient for customers. 

C

> On Jun 9, 2016, at 11:45 AM, Steinar Midtskogen <stei...@latinitas.org> wrote:
> 
> Colin Reese <colin.re...@gmail.com> writes:
> 
>> You have a source for ip rated with screw terminals? I never found
>> one. I looked at xlr some time ago and was unsatisfied with what I
>> found. Another equipment vendor I know uses them, but 'pretty
>> waterproof' is insufficient for an end-user product if I sell it on.
> 
> It's been so many years since I researched this, and I haven't inspected
> the switchbox on my roof in years, so I can't even quite remember what
> type I have.
> 
> Try to google for "XLR IP67".  But IP67 is just "pretty waterproof".  If
> you need connectors that stay submerged in water, you need IP68.  Try
> search for "XLR IP68".
> 
> -- 
> Steinar
> 
> --
> What NetFlow Analyzer can do for you? Monitors network bandwidth and traffic
> patterns at an interface-level. Reveals which users, apps, and protocols are 
> consuming the most bandwidth. Provides multi-vendor support for NetFlow, 
> J-Flow, sFlow and other flows. Make informed decisions using capacity 
> planning reports. https://ad.doubleclick.net/ddm/clk/305295220;132659582;e
> ___
> Owfs-developers mailing list
> Owfs-developers@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/owfs-developers

--
What NetFlow Analyzer can do for you? Monitors network bandwidth and traffic
patterns at an interface-level. Reveals which users, apps, and protocols are 
consuming the most bandwidth. Provides multi-vendor support for NetFlow, 
J-Flow, sFlow and other flows. Make informed decisions using capacity 
planning reports. https://ad.doubleclick.net/ddm/clk/305295220;132659582;e
___
Owfs-developers mailing list
Owfs-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/owfs-developers

Re: [Owfs-developers] Cable Length

[Colin Reese]

Half resistance. Also guarantees not having the capacitance issues due to 
pairing unlike signals together. 

> On Jun 7, 2016, at 1:37 PM, Peter Hollenbeck <pwhb...@gmail.com> wrote:
> 
> In what way is using a pair better than using a single conductor.
> (It's obvious I know little about this.)
> 
> Thanks,
> Peter
> 
>> On Mon, Jun 6, 2016 at 5:58 PM, Jerry Scharf 
>> <sch...@lagunawayconsulting.com> wrote:
>> Hi,
>> 
>> I'm not sure what you are doing, but I have two long runs with 10s of 18b20s 
>> on at least a couple hundred feet of cat5. The way I do it is 1 pair for +5, 
>> 1 pair for ground and one pair that is out and back data lines to the punch 
>> down panel (I know it's a bus, but star wiring is way easier in a building.) 
>> I hate to think what the effective capacitance on the data line is. Driven 
>> by two different Link interfaces.
>> 
>> I do get occasional errors, but it works pretty well.
>> 
>> jerry
>> 
>> 
>>> On 06/06/2016 04:28 PM, Peter Hollenbeck wrote:
>>> My cable issues don't yet have to do with connectors. From posts I have 
>>> read here I was under the impression that 1wire would work over Cat5 up to 
>>> 100m. Not for me. I am testing with one sensor, a waterproof DS18B20 from 
>>> Adafruit. Longest cable that works is about 45 feet. I have tried a LinkUSB 
>>> and a HobbyBoards powered master. Using a Raspberry Pi.
>>> 
>>> Peter
>>> 
>>>> On Mon, Jun 6, 2016 at 1:42 PM, Colin Reese <colin.re...@gmail.com> wrote:
>>>> You have a source for ip rated with screw terminals? I never found one. I 
>>>> looked at xlr some time ago and was unsatisfied with what I found. Another 
>>>> equipment vendor I know uses them, but 'pretty waterproof' is insufficient 
>>>> for an end-user product if I sell it on.
>>>> 
>>>> Colin
>>>> 
>>>> 
>>>> > On Jun 6, 2016, at 1:29 PM, Steinar Midtskogen <stei...@latinitas.org> 
>>>> > wrote:
>>>> >
>>>> > I struggled a few years with the most terrible connectors that you can
>>>> > use outdoors, rj12 or rj45, then switched to XLR connectors, which are
>>>> > cheap and sturdy.  You can get IP67 rated XLR connectors as well, but
>>>> > even the cheapest XLR connectors seem to work well with basic humidity
>>>> > protection.
>>>> >
>>>> > I made a couple of switchboxes using XLR connectors and put them in
>>>> > metal mailboxes.  They've worked well for about 10 years now.
>>>> >
>>>> > -Steinar
>>>> >
>>>> > Colin Reese <colin.re...@gmail.com> writes:
>>>> >
>>>> >> Of course.
>>>> >>
>>>> >> The gender complement is this guy:
>>>> >>
>>>> >> http://www.alliedelec.com/lumberg-automation-hirschmann-rsc-4-7/70050935/
>>>> >>
>>>> >> They're not cheap at about $20/pr, but they are both IP67 and also
>>>> >> field-serviceable (internal screw terminals). This is a rare combination
>>>> >> that customers who do not want to solder really appreciate. I run
>>>> >> 5V/Data/Gnd/Shield as a standard pinout.
>>>> >>
>>>> >> C
>>>> >
>>>> > --
>>>> > What NetFlow Analyzer can do for you? Monitors network bandwidth and 
>>>> > traffic
>>>> > patterns at an interface-level. Reveals which users, apps, and protocols 
>>>> > are
>>>> > consuming the most bandwidth. Provides multi-vendor support for NetFlow,
>>>> > J-Flow, sFlow and other flows. Make informed decisions using capacity
>>>> > planning reports. 
>>>> > https://ad.doubleclick.net/ddm/clk/305295220;132659582;e
>>>> > ___
>>>> > Owfs-developers mailing list
>>>> > Owfs-developers@lists.sourceforge.net
>>>> > https://lists.sourceforge.net/lists/listinfo/owfs-developers
>>>> 
>>>> --
>>>> What NetFlow Analyzer can do for you? Monitors network bandwidth and 
>>>> traffic
>>>> patterns at an interface-level. Reveals which users, apps, and protocols 
>>>> 

Re: [Owfs-developers] Cable Length

[Colin Reese]

Well, the best way to use it would be to double twisted pairs as like
conductors, but you'd have to do your own breakout for that. It would be
well worth it.

i.e.:

BLU - 5V
BLU/WHT - 5V
GRN - GND
GRN/WHT - GND
BRN - DATA
BRN/WHT - DATA

C

On Mon, Jun 6, 2016 at 5:17 PM, Peter Hollenbeck <pwhb...@gmail.com> wrote:

> I just said:
> "My cable issues don't yet have to do with connectors. From posts I have
> read here I was under the impression that 1wire would work over Cat5 up to
> 100m. Not for me. I am testing with one sensor, a waterproof DS18B20 from
> Adafruit. Longest cable that works is about 45 feet. I have tried a LinkUSB
> and a HobbyBoards powered master. Using a Raspberry Pi."
>
> Correction:
> I just tested with a 100 feet of different Cat5E and it works.
> The cable that doesn't work is off a 200 foot length of outdoor Cat5
> bought online. What is the chance that this latter cable is faulty. It
> tests good with a able tester, but that is just continuity. What other
> factors are there?
>
> How can I buy cable and know it's good stuff and not junk?? (I need 170
> feet.)
>
> I'm on a remote island in B.C. Canada. Cannot go to the corner store and
> buy more cable.
>
> Thanks,
> Peter
>
> On Mon, Jun 6, 2016 at 4:28 PM, Peter Hollenbeck <pwhb...@gmail.com>
> wrote:
>
>> My cable issues don't yet have to do with connectors. From posts I have
>> read here I was under the impression that 1wire would work over Cat5 up to
>> 100m. Not for me. I am testing with one sensor, a waterproof DS18B20 from
>> Adafruit. Longest cable that works is about 45 feet. I have tried a LinkUSB
>> and a HobbyBoards powered master. Using a Raspberry Pi.
>>
>> Peter
>>
>> On Mon, Jun 6, 2016 at 1:42 PM, Colin Reese <colin.re...@gmail.com>
>> wrote:
>>
>>> You have a source for ip rated with screw terminals? I never found one.
>>> I looked at xlr some time ago and was unsatisfied with what I found.
>>> Another equipment vendor I know uses them, but 'pretty waterproof' is
>>> insufficient for an end-user product if I sell it on.
>>>
>>> Colin
>>>
>>>
>>> > On Jun 6, 2016, at 1:29 PM, Steinar Midtskogen <stei...@latinitas.org>
>>> wrote:
>>> >
>>> > I struggled a few years with the most terrible connectors that you can
>>> > use outdoors, rj12 or rj45, then switched to XLR connectors, which are
>>> > cheap and sturdy.  You can get IP67 rated XLR connectors as well, but
>>> > even the cheapest XLR connectors seem to work well with basic humidity
>>> > protection.
>>> >
>>> > I made a couple of switchboxes using XLR connectors and put them in
>>> > metal mailboxes.  They've worked well for about 10 years now.
>>> >
>>> > -Steinar
>>> >
>>> > Colin Reese <colin.re...@gmail.com> writes:
>>> >
>>> >> Of course.
>>> >>
>>> >> The gender complement is this guy:
>>> >>
>>> >>
>>> http://www.alliedelec.com/lumberg-automation-hirschmann-rsc-4-7/70050935/
>>> >>
>>> >> They're not cheap at about $20/pr, but they are both IP67 and also
>>> >> field-serviceable (internal screw terminals). This is a rare
>>> combination
>>> >> that customers who do not want to solder really appreciate. I run
>>> >> 5V/Data/Gnd/Shield as a standard pinout.
>>> >>
>>> >> C
>>> >
>>> >
>>> --
>>> > What NetFlow Analyzer can do for you? Monitors network bandwidth and
>>> traffic
>>> > patterns at an interface-level. Reveals which users, apps, and
>>> protocols are
>>> > consuming the most bandwidth. Provides multi-vendor support for
>>> NetFlow,
>>> > J-Flow, sFlow and other flows. Make informed decisions using capacity
>>> > planning reports.
>>> https://ad.doubleclick.net/ddm/clk/305295220;132659582;e
>>> > ___
>>> > Owfs-developers mailing list
>>> > Owfs-developers@lists.sourceforge.net
>>> > https://lists.sourceforge.net/lists/listinfo/owfs-developers
>>>
>>>
>>> --
>>> What NetFlow Analyzer can do for you? Monitors network bandwidth and
>>> traffic
>>> patterns at an interface-level. Reveals which u

Re: [Owfs-developers] New install of OWFS on RPi running Jessie

[Colin Reese]

rc.local still runs. I have it run boot.py and that handles manual startup of 
everything there. Whether owfs is started and on which interface is determined 
by an 'interfaces' table in the 'system' SQLite database, as is which web 
server (if any) is started. This is the reason for the update-rc.d remove 
commands throughout the install script. 

There is also a daemon run from cron periodically to ensure desired Python 
daemon scripts (there are a handful) are running, and dispatch email 
notifications if things appear awry. 

C

> On Jun 6, 2016, at 4:49 PM, Alex Shepherd <list...@ajsystems.co.nz> wrote:
> 
> Hi Colin,
> 
>> On 7/06/2016, at 9:33 AM, Colin Reese <colin.re...@gmail.com> wrote:
>> 
>> I keep 2.9.5 in my repo and give it a make install on every automated build 
>> I do. I am on raspbian and also Jessie and both work great. I use ds2483, 
>> however, not linkusb. See here (swig lib-fuse et al at top and owfs down 
>> below)
>> 
>> https://github.com/iinnovations/iicontrollibs/blob/master/misc/initscript.sh
> 
> Wow! That's a pretty comprehensive install script - obviously everything you 
> have which is awesome.
> 
> I’ll cherry pick all the apt-get stuff that I need. I’ve just downloaded the 
> Jessie-Lite SD Image that doesn’t have the “kitchen sink” in it. 
> 
> What are you doing with the /etc/init.d startup scripts as I am told that the 
> whole start-up sequence has changed on Jessie now? Does the 2.9.5 package 
> still generate all the right init.d start-up scripts and all “just work” 
> still if I do a “make install"?
> 
> Regards
> 
> Alex Shepherd
> 
> 
> --
> What NetFlow Analyzer can do for you? Monitors network bandwidth and traffic
> patterns at an interface-level. Reveals which users, apps, and protocols are 
> consuming the most bandwidth. Provides multi-vendor support for NetFlow, 
> J-Flow, sFlow and other flows. Make informed decisions using capacity 
> planning reports. https://ad.doubleclick.net/ddm/clk/305295220;132659582;e
> ___
> Owfs-developers mailing list
> Owfs-developers@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/owfs-developers

--
What NetFlow Analyzer can do for you? Monitors network bandwidth and traffic
patterns at an interface-level. Reveals which users, apps, and protocols are 
consuming the most bandwidth. Provides multi-vendor support for NetFlow, 
J-Flow, sFlow and other flows. Make informed decisions using capacity 
planning reports. https://ad.doubleclick.net/ddm/clk/305295220;132659582;e
___
Owfs-developers mailing list
Owfs-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/owfs-developers

Re: [Owfs-developers] New install of OWFS on RPi running Jessie

[Colin Reese]

I keep 2.9.5 in my repo and give it a make install on every automated build I 
do. I am on raspbian and also Jessie and both work great. I use ds2483, 
however, not linkusb. See here (swig lib-fuse et al at top and owfs down below)

https://github.com/iinnovations/iicontrollibs/blob/master/misc/initscript.sh

C



> On Jun 6, 2016, at 1:56 PM, Alex Shepherd  wrote:
> 
> Hi Guys,
> 
> I’m giving my OWFS based heating system an update.
> 
> Currently I’m running on a RPi 2 with Wheezy 7.10 and some LinkUSB adaptors 
> and am wanting to reinstall on the latest releases.
> 
> I’m trying to do a clean install onto another RPi running Jessie and using 
> the latest release doing an 'apt-get install owfs’ but it didn’t seem to want 
> to start properly.
> 
> I then went and got the current source code and have done a build (once I git 
> all the dependant libs etc) but just wondering what the current recipe is to 
> get a good stable system on an RPi?
> 
> Any suggestions?
> 
> Regards
> 
> Alex Shepherd
> 
> 
> --
> What NetFlow Analyzer can do for you? Monitors network bandwidth and traffic
> patterns at an interface-level. Reveals which users, apps, and protocols are 
> consuming the most bandwidth. Provides multi-vendor support for NetFlow, 
> J-Flow, sFlow and other flows. Make informed decisions using capacity 
> planning reports. https://ad.doubleclick.net/ddm/clk/305295220;132659582;e
> ___
> Owfs-developers mailing list
> Owfs-developers@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/owfs-developers

--
What NetFlow Analyzer can do for you? Monitors network bandwidth and traffic
patterns at an interface-level. Reveals which users, apps, and protocols are 
consuming the most bandwidth. Provides multi-vendor support for NetFlow, 
J-Flow, sFlow and other flows. Make informed decisions using capacity 
planning reports. https://ad.doubleclick.net/ddm/clk/305295220;132659582;e
___
Owfs-developers mailing list
Owfs-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/owfs-developers

Re: [Owfs-developers] Cable Length

[Colin Reese]

You have a source for ip rated with screw terminals? I never found one. I 
looked at xlr some time ago and was unsatisfied with what I found. Another 
equipment vendor I know uses them, but 'pretty waterproof' is insufficient for 
an end-user product if I sell it on. 

Colin


> On Jun 6, 2016, at 1:29 PM, Steinar Midtskogen <stei...@latinitas.org> wrote:
> 
> I struggled a few years with the most terrible connectors that you can
> use outdoors, rj12 or rj45, then switched to XLR connectors, which are
> cheap and sturdy.  You can get IP67 rated XLR connectors as well, but
> even the cheapest XLR connectors seem to work well with basic humidity
> protection.
> 
> I made a couple of switchboxes using XLR connectors and put them in
> metal mailboxes.  They've worked well for about 10 years now.
> 
> -Steinar
> 
> Colin Reese <colin.re...@gmail.com> writes:
> 
>> Of course.
>> 
>> The gender complement is this guy:
>> 
>> http://www.alliedelec.com/lumberg-automation-hirschmann-rsc-4-7/70050935/
>> 
>> They're not cheap at about $20/pr, but they are both IP67 and also 
>> field-serviceable (internal screw terminals). This is a rare combination 
>> that customers who do not want to solder really appreciate. I run 
>> 5V/Data/Gnd/Shield as a standard pinout.
>> 
>> C
> 
> --
> What NetFlow Analyzer can do for you? Monitors network bandwidth and traffic
> patterns at an interface-level. Reveals which users, apps, and protocols are 
> consuming the most bandwidth. Provides multi-vendor support for NetFlow, 
> J-Flow, sFlow and other flows. Make informed decisions using capacity 
> planning reports. https://ad.doubleclick.net/ddm/clk/305295220;132659582;e
> ___
> Owfs-developers mailing list
> Owfs-developers@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/owfs-developers

--
What NetFlow Analyzer can do for you? Monitors network bandwidth and traffic
patterns at an interface-level. Reveals which users, apps, and protocols are 
consuming the most bandwidth. Provides multi-vendor support for NetFlow, 
J-Flow, sFlow and other flows. Make informed decisions using capacity 
planning reports. https://ad.doubleclick.net/ddm/clk/305295220;132659582;e
___
Owfs-developers mailing list
Owfs-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/owfs-developers

Re: [Owfs-developers] Cable Length

[Colin Reese]

Of course.

The gender complement is this guy:

http://www.alliedelec.com/lumberg-automation-hirschmann-rsc-4-7/70050935/

They're not cheap at about $20/pr, but they are both IP67 and also 
field-serviceable (internal screw terminals). This is a rare combination 
that customers who do not want to solder really appreciate. I run 
5V/Data/Gnd/Shield as a standard pinout.

C

On 6/1/2016 2:34 PM, Peter Hollenbeck wrote:
> Colin,
> Thanks very much, especially for the tip on Lumberg connectors. I have
> been wanting such for a long time.
> Peter
>
> On Wed, Jun 1, 2016 at 1:46 PM, Colin Reese <colin.re...@gmail.com
> <mailto:colin.re...@gmail.com>> wrote:
>
> Something like this is suitable:
>
> 
> http://www.ebay.com/itm/Security-Alarm-Cable-22-3-7-Strand-Riser-CMR-Rated-Shielded-1000-Gray-ASC2-326-/361394994944?hash=item5424d1ff00:g:BYEAAOSw37tWAyLk
>
> For exterior connectors, I avoid at all costs, but if necessary:
>
> http://www.alliedelec.com/lumberg-automation-hirschmann-rkc-4-7/70050957/
>
> C
>
>
>
>
> On 6/1/2016 1:41 PM, Jan Kandziora wrote:
> > Am 01.06.2016 um 22:33 schrieb Peter Hollenbeck:
> >> Any thoughts on outdoor use?
> >>
> > The outdoor circuit has to be insulated tightly. There should be no
> > connection of any wire to earth. That means also no connection through
> > rust stain and water.
> >
> > Kind regards
> >
> >   Jan
> >
> >
> 
> --
> > What NetFlow Analyzer can do for you? Monitors network bandwidth
> and traffic
> > patterns at an interface-level. Reveals which users, apps, and
> protocols are
> > consuming the most bandwidth. Provides multi-vendor support for
> NetFlow,
> > J-Flow, sFlow and other flows. Make informed decisions using capacity
> > planning reports.
> https://ad.doubleclick.net/ddm/clk/305295220;132659582;e
> > ___
> > Owfs-developers mailing list
> > Owfs-developers@lists.sourceforge.net
> <mailto:Owfs-developers@lists.sourceforge.net>
> > https://lists.sourceforge.net/lists/listinfo/owfs-developers
> >
>
> 
> --
> What NetFlow Analyzer can do for you? Monitors network bandwidth and
> traffic
> patterns at an interface-level. Reveals which users, apps, and
> protocols are
> consuming the most bandwidth. Provides multi-vendor support for NetFlow,
> J-Flow, sFlow and other flows. Make informed decisions using capacity
> planning reports.
> https://ad.doubleclick.net/ddm/clk/305295220;132659582;e
> ___
> Owfs-developers mailing list
> Owfs-developers@lists.sourceforge.net
> <mailto:Owfs-developers@lists.sourceforge.net>
> https://lists.sourceforge.net/lists/listinfo/owfs-developers
>
>
>
>
> --
> What NetFlow Analyzer can do for you? Monitors network bandwidth and traffic
> patterns at an interface-level. Reveals which users, apps, and protocols are
> consuming the most bandwidth. Provides multi-vendor support for NetFlow,
> J-Flow, sFlow and other flows. Make informed decisions using capacity
> planning reports. https://ad.doubleclick.net/ddm/clk/305295220;132659582;e
>
>
>
> ___
> Owfs-developers mailing list
> Owfs-developers@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/owfs-developers
>

--
What NetFlow Analyzer can do for you? Monitors network bandwidth and traffic
patterns at an interface-level. Reveals which users, apps, and protocols are 
consuming the most bandwidth. Provides multi-vendor support for NetFlow, 
J-Flow, sFlow and other flows. Make informed decisions using capacity 
planning reports. https://ad.doubleclick.net/ddm/clk/305295220;132659582;e
___
Owfs-developers mailing list
Owfs-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/owfs-developers

Re: [Owfs-developers] Cable Length

[Colin Reese]

Yes, in this case you will need to make your own 8P8C --> three 
conductor pigtail and butt-splice or screw-terminals on a piece of 
protoboard. No biggie.

C

On 6/1/2016 1:44 PM, Peter Hollenbeck wrote:
> Am using a LinkUSB connected to a Raspberry Pi.
> Not 1wire-smart,
> Peter
>
> On Wed, Jun 1, 2016 at 1:37 PM, Jan Kandziora  > wrote:
>
> Am 01.06.2016 um 21:07 schrieb Peter Hollenbeck:
> > My DS18B20 works over 34 feet of Cat5e but not over 160 feet.
> > Resistance for the 160 foot wire is 4.7 ohms, 0.29 ohms per foot.
> > Resistance for the 34 foot wire is 0.9 ohms, 0.26 ohms per foot.
> >
> Resistance is the limiting factor if you are delivering power through
> the cable. Do you?
>
> In all other cases, resistance, inductance, capacitance is the limiting
> factor, at they all lengthen the rise times of signals over the limit.
>
>
> What kind of host circuit do you use? The infamous 4,7k to 3.3V pullup?
>
>
> > I have read that 1wire is good for 100 meters over Catx.
> >
> Simple telephone wire is better for Onewire.
>
> Kind regards
>
> Jan
>
> 
> --
> What NetFlow Analyzer can do for you? Monitors network bandwidth and
> traffic
> patterns at an interface-level. Reveals which users, apps, and
> protocols are
> consuming the most bandwidth. Provides multi-vendor support for NetFlow,
> J-Flow, sFlow and other flows. Make informed decisions using capacity
> planning reports.
> https://ad.doubleclick.net/ddm/clk/305295220;132659582;e
> ___
> Owfs-developers mailing list
> Owfs-developers@lists.sourceforge.net
> 
> https://lists.sourceforge.net/lists/listinfo/owfs-developers
>
>
>
>
> --
> What NetFlow Analyzer can do for you? Monitors network bandwidth and traffic
> patterns at an interface-level. Reveals which users, apps, and protocols are
> consuming the most bandwidth. Provides multi-vendor support for NetFlow,
> J-Flow, sFlow and other flows. Make informed decisions using capacity
> planning reports. https://ad.doubleclick.net/ddm/clk/305295220;132659582;e
>
>
>
> ___
> Owfs-developers mailing list
> Owfs-developers@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/owfs-developers
>

--
What NetFlow Analyzer can do for you? Monitors network bandwidth and traffic
patterns at an interface-level. Reveals which users, apps, and protocols are 
consuming the most bandwidth. Provides multi-vendor support for NetFlow, 
J-Flow, sFlow and other flows. Make informed decisions using capacity 
planning reports. https://ad.doubleclick.net/ddm/clk/305295220;132659582;e
___
Owfs-developers mailing list
Owfs-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/owfs-developers

Re: [Owfs-developers] Cable Length

[Colin Reese]

Something like this is suitable:

http://www.ebay.com/itm/Security-Alarm-Cable-22-3-7-Strand-Riser-CMR-Rated-Shielded-1000-Gray-ASC2-326-/361394994944?hash=item5424d1ff00:g:BYEAAOSw37tWAyLk

For exterior connectors, I avoid at all costs, but if necessary:

http://www.alliedelec.com/lumberg-automation-hirschmann-rkc-4-7/70050957/

C




On 6/1/2016 1:41 PM, Jan Kandziora wrote:
> Am 01.06.2016 um 22:33 schrieb Peter Hollenbeck:
>> Any thoughts on outdoor use?
>>
> The outdoor circuit has to be insulated tightly. There should be no
> connection of any wire to earth. That means also no connection through
> rust stain and water.
>
> Kind regards
>
>   Jan
>
> --
> What NetFlow Analyzer can do for you? Monitors network bandwidth and traffic
> patterns at an interface-level. Reveals which users, apps, and protocols are
> consuming the most bandwidth. Provides multi-vendor support for NetFlow,
> J-Flow, sFlow and other flows. Make informed decisions using capacity
> planning reports. https://ad.doubleclick.net/ddm/clk/305295220;132659582;e
> ___
> Owfs-developers mailing list
> Owfs-developers@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/owfs-developers
>

--
What NetFlow Analyzer can do for you? Monitors network bandwidth and traffic
patterns at an interface-level. Reveals which users, apps, and protocols are 
consuming the most bandwidth. Provides multi-vendor support for NetFlow, 
J-Flow, sFlow and other flows. Make informed decisions using capacity 
planning reports. https://ad.doubleclick.net/ddm/clk/305295220;132659582;e
___
Owfs-developers mailing list
Owfs-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/owfs-developers

Re: [Owfs-developers] Cable Length

[Colin Reese]

There is plenty of industrial quality cable that fits these purposes. 
Furthermore, it's typically stranded, whereas most varieties of spooled 
Cat5/6 will be solid core, which is not as durable and more difficult to 
terminate in, say, terminal blocks -- especially spring-loaded.

I use this stuff all over the place for 1Wire, RTDs, and other sensor 
cabling and IO. It is typically far more durable than your average cat5. 
With only a few conductors, you will get a much thicker, durable, 
weather and fire-proof cable at a smaller diameter.

C



On 6/1/2016 1:33 PM, Peter Hollenbeck wrote:
> Any thoughts on outdoor use? I will look online but thought I would ask.
> Peter
>
>
> On Wed, Jun 1, 2016 at 12:14 PM, Colin Reese <colin.re...@gmail.com
> <mailto:colin.re...@gmail.com>> wrote:
>
> Don't use Cat5. Just get some good 22/3 or 22/4. It's cheap and easy to
> find.
>
> C
>
>
> On 6/1/2016 12:07 PM, Peter Hollenbeck wrote:
> > My DS18B20 works over 34 feet of Cat5e but not over 160 feet.
> > Resistance for the 160 foot wire is 4.7 ohms, 0.29 ohms per foot.
> > Resistance for the 34 foot wire is 0.9 ohms, 0.26 ohms per foot.
> >
> > Both lengths of cable are from the same 200 foot length.
> >
> > Is my 160 foot cable too long or might I have another problem?
> > I have read that 1wire is good for 100 meters over Catx.
> >
> > Thanks,
> > Peter
> >
> >
> >
> 
> --
> > What NetFlow Analyzer can do for you? Monitors network bandwidth
> and traffic
> > patterns at an interface-level. Reveals which users, apps, and
> protocols are
> > consuming the most bandwidth. Provides multi-vendor support for
> NetFlow,
> > J-Flow, sFlow and other flows. Make informed decisions using capacity
> > planning reports.
> https://ad.doubleclick.net/ddm/clk/305295220;132659582;e
> >
> >
> >
> > ___
> > Owfs-developers mailing list
> > Owfs-developers@lists.sourceforge.net
> <mailto:Owfs-developers@lists.sourceforge.net>
> > https://lists.sourceforge.net/lists/listinfo/owfs-developers
> >
>
> 
> --
> What NetFlow Analyzer can do for you? Monitors network bandwidth and
> traffic
> patterns at an interface-level. Reveals which users, apps, and
> protocols are
> consuming the most bandwidth. Provides multi-vendor support for NetFlow,
> J-Flow, sFlow and other flows. Make informed decisions using capacity
> planning reports.
> https://ad.doubleclick.net/ddm/clk/305295220;132659582;e
> ___
> Owfs-developers mailing list
> Owfs-developers@lists.sourceforge.net
> <mailto:Owfs-developers@lists.sourceforge.net>
> https://lists.sourceforge.net/lists/listinfo/owfs-developers
>
>
>
>
> --
> What NetFlow Analyzer can do for you? Monitors network bandwidth and traffic
> patterns at an interface-level. Reveals which users, apps, and protocols are
> consuming the most bandwidth. Provides multi-vendor support for NetFlow,
> J-Flow, sFlow and other flows. Make informed decisions using capacity
> planning reports. https://ad.doubleclick.net/ddm/clk/305295220;132659582;e
>
>
>
> ___
> Owfs-developers mailing list
> Owfs-developers@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/owfs-developers
>

--
What NetFlow Analyzer can do for you? Monitors network bandwidth and traffic
patterns at an interface-level. Reveals which users, apps, and protocols are 
consuming the most bandwidth. Provides multi-vendor support for NetFlow, 
J-Flow, sFlow and other flows. Make informed decisions using capacity 
planning reports. https://ad.doubleclick.net/ddm/clk/305295220;132659582;e
___
Owfs-developers mailing list
Owfs-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/owfs-developers

Re: [Owfs-developers] Cable Length

[Colin Reese]

Don't use Cat5. Just get some good 22/3 or 22/4. It's cheap and easy to 
find.

C


On 6/1/2016 12:07 PM, Peter Hollenbeck wrote:
> My DS18B20 works over 34 feet of Cat5e but not over 160 feet.
> Resistance for the 160 foot wire is 4.7 ohms, 0.29 ohms per foot.
> Resistance for the 34 foot wire is 0.9 ohms, 0.26 ohms per foot.
>
> Both lengths of cable are from the same 200 foot length.
>
> Is my 160 foot cable too long or might I have another problem?
> I have read that 1wire is good for 100 meters over Catx.
>
> Thanks,
> Peter
>
>
> --
> What NetFlow Analyzer can do for you? Monitors network bandwidth and traffic
> patterns at an interface-level. Reveals which users, apps, and protocols are
> consuming the most bandwidth. Provides multi-vendor support for NetFlow,
> J-Flow, sFlow and other flows. Make informed decisions using capacity
> planning reports. https://ad.doubleclick.net/ddm/clk/305295220;132659582;e
>
>
>
> ___
> Owfs-developers mailing list
> Owfs-developers@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/owfs-developers
>

--
What NetFlow Analyzer can do for you? Monitors network bandwidth and traffic
patterns at an interface-level. Reveals which users, apps, and protocols are 
consuming the most bandwidth. Provides multi-vendor support for NetFlow, 
J-Flow, sFlow and other flows. Make informed decisions using capacity 
planning reports. https://ad.doubleclick.net/ddm/clk/305295220;132659582;e
___
Owfs-developers mailing list
Owfs-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/owfs-developers

Re: [Owfs-developers] DS9097E# External Supply

[Colin Reese]

Sorry, the data sheet I meant to reference is here:

https://datasheets.maximintegrated.com/en/ds/DS9097-DS9097E.pdf

C

On Tue, Mar 15, 2016 at 5:47 PM, Colin Reese <colin.re...@gmail.com> wrote:

> Hey all,
>
> This is not an owfs-specific question, but more 1Wire hardware related.
>
> Using the DB25 connector connected to a serial port as here;
>
> http://rosset.org/linux/datasheet/DS9097U.pdf
>
> Everything is fine until I plug in a 12V supply, at which time all devices
> disappear from the bus. The supply is one of those specifically recommended
> in the datasheet, and is putting out close enough to 12V center-ground.
>
> Anybody have any ideas why this would occur?
>
> Thanks,
> Colin
>
--
Transform Data into Opportunity.
Accelerate data analysis in your applications with
Intel Data Analytics Acceleration Library.
Click to learn more.
http://pubads.g.doubleclick.net/gampad/clk?id=278785231=/4140___
Owfs-developers mailing list
Owfs-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/owfs-developers

[Owfs-developers] DS9097E# External Supply

[Colin Reese]

Hey all,

This is not an owfs-specific question, but more 1Wire hardware related.

Using the DB25 connector connected to a serial port as here;

http://rosset.org/linux/datasheet/DS9097U.pdf

Everything is fine until I plug in a 12V supply, at which time all devices
disappear from the bus. The supply is one of those specifically recommended
in the datasheet, and is putting out close enough to 12V center-ground.

Anybody have any ideas why this would occur?

Thanks,
Colin
--
Transform Data into Opportunity.
Accelerate data analysis in your applications with
Intel Data Analytics Acceleration Library.
Click to learn more.
http://pubads.g.doubleclick.net/gampad/clk?id=278785231=/4140___
Owfs-developers mailing list
Owfs-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/owfs-developers

Re: [Owfs-developers] DS18B20 Question

[Colin Reese]

Check your connector. Those Rj12s can get squidgy with enough fussing
about.


On Tue, Mar 1, 2016 at 3:14 PM, Peter Hollenbeck  wrote:

> I must have it wired wrong.
> Really odd that yesterday evening it worked and I got valid ocean
> temperature values.
>
> Back to checking wiring.
>
> Thanks,
> Peter
>
>
> On Tue, Mar 1, 2016 at 1:59 PM, Eric Vickery 
> wrote:
>
>> Definitely sounds like the 1-Wire bus is getting shorted out.
>>
>> On Mar 1, 2016, at 3:56 PM, Peter Hollenbeck  wrote:
>>
>> I must have something else wrong. When I connect the DS18B20 without a
>> resistor the MS-TV disappears.
>>
>> Odd that it worked last night - with a 5K resistor.
>> I do not know electronics.
>>
>> Thanks,
>> Peter
>>
>> On Tue, Mar 1, 2016 at 1:48 PM, Johan Ström  wrote:
>>
>>>
>>>
>>> On 01/03/16 22:38, Peter Hollenbeck wrote:
>>> > Raspberry Pi Ethernet to LinkUSB
>>> > Ethernet from LinkUSB to MS-TV
>>> > Ethernet from MS-TV to DS18B20
>>> >
>>> > Ethernet connections to DS18B20:
>>> > DS18B20 +5V red connected to RJ45 pin 2
>>> > DS18B20 ground blue to RJ45 pin 6
>>> > DS18B20 data yellow to RJ45 pin 4
>>> That looks weird, according to my LinkUSB PDF pin 6 is Auxiliary. Try
>>> pin 1,3 or 5 which is GND.
>>>
>>> There should be no need for a pull-up resistor on a LinkUSB, ever. It
>>> would probably just confuse the active pull-up which the LinkUSB is
>>> equipped with.
>>> The doc you referred to (https://www.adafruit.com/products/381) seems to
>>> assume a direct connection between a Rasberry Pi GPIO pin, and the
>>> device. That makes a non-optimal, but working, 1-wire master. You have a
>>> proper one (the LinkUSB).
>>>
>>>
>>> --
>>> Site24x7 APM Insight: Get Deep Visibility into Application Performance
>>> APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month
>>> Monitor end-to-end web transactions and take corrective actions now
>>> Troubleshoot faster and improve end-user experience. Signup Now!
>>> http://pubads.g.doubleclick.net/gampad/clk?id=272487151=/4140
>>> ___
>>> Owfs-developers mailing list
>>> Owfs-developers@lists.sourceforge.net
>>> https://lists.sourceforge.net/lists/listinfo/owfs-developers
>>>
>>
>>
>> --
>> Site24x7 APM Insight: Get Deep Visibility into Application Performance
>> APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month
>> Monitor end-to-end web transactions and take corrective actions now
>> Troubleshoot faster and improve end-user experience. Signup Now!
>>
>> http://pubads.g.doubleclick.net/gampad/clk?id=272487151=/4140___
>> Owfs-developers mailing list
>> Owfs-developers@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/owfs-developers
>>
>>
>>
>>
>> --
>> Site24x7 APM Insight: Get Deep Visibility into Application Performance
>> APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month
>> Monitor end-to-end web transactions and take corrective actions now
>> Troubleshoot faster and improve end-user experience. Signup Now!
>> http://pubads.g.doubleclick.net/gampad/clk?id=272487151=/4140
>> ___
>> Owfs-developers mailing list
>> Owfs-developers@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/owfs-developers
>>
>>
>
>
> --
> Site24x7 APM Insight: Get Deep Visibility into Application Performance
> APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month
> Monitor end-to-end web transactions and take corrective actions now
> Troubleshoot faster and improve end-user experience. Signup Now!
> http://pubads.g.doubleclick.net/gampad/clk?id=272487151=/4140
> ___
> Owfs-developers mailing list
> Owfs-developers@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/owfs-developers
>
>
--
Site24x7 APM Insight: Get Deep Visibility into Application Performance
APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month
Monitor end-to-end web transactions and take corrective actions now
Troubleshoot faster and improve end-user experience. Signup Now!
http://pubads.g.doubleclick.net/gampad/clk?id=272487151=/4140___
Owfs-developers mailing list
Owfs-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/owfs-developers

Re: [Owfs-developers] To the people willing to look at what I am thinking about for control systems

[Colin Reese]

For what it's worth, I have my own Python sql query abstraction that I find 
infinitely useful. 

I create/edit all action (if this then that) operations from a web interface 
where I reference values using a database value notation that is then 
interpreted by a sanitized Python eval. Pretty simple but powerful. Can send rf 
messages, set db values for squirting into switch io, etc. 

Sure, single point of failure, but stateful and historical (critical for PID), 
which the importance of was already pointed out. I think it's important to have 
stupid devices and one or a few smart nodes for databasing and bringing things 
to a web interface. Computers are quite reliable these days. If you want the 
thing to be networked, you'll need a single node to either get things out or 
determine which of your redundant smart nodes have failed anyway. I guess you 
could make this node a simple micro for no other purpose (or a hacked router), 
but I find SBCs such as the Pi plenty reliable. 

C

> On Feb 23, 2016, at 11:16 AM, Matthias Urlichs  wrote:
> 
> Arley Carter  writes:
> 
>> Have you looked at the work done by the OPC Consortium? 
> 
> Not yet.
> 
> [three hours later] O … K … Skip ahead if you don't want to read me ranting.
> 
> If you want something that's *way* overspecified (I do not want to implement 
> a 
> structured version of SQL queries – among other interesting things – nor do I 
> see any need to do so) and impossible to implement without (a) access to the 
> reference implementation and its test cases and (b) at least a man year for 
> the basics (the Java server example is 430 lines -- more than 70(!) import 
> statements, way too few comments, and a heap of empty handlers most people 
> would find to be somewhat essential), be my guest.
> 
> This eerily reminds me of the X.400 train wreck of the 1980s.
> 
> In any case, this is the OWFS list. I can guarantee that nobody in their 
> right 
> mind would ever connect an 1820 temperature sensor to such a system.
> 
>> They are rather 
>> far down the track in the direction you are headed.
> 
> They also want $3000 for access to their C source code. Redistribution is not 
> permitted, sorry, so any open source implementation will have to be done from 
> scratch.
> 
>> Why replow fields and reinvent wheels?
> 
> Look at how much FHEM or OpenHAB can do. Ultimately I would like to build 
> [the 
> foundation of] something that's as capable, but somewhat more reliable (no 
> single point of failure) and accessible ("if X, do Y" should be three lines 
> of 
> debuggable Python/Perl/whatever, or three Node:Red clicks).
> 
> In any case I am no re-inventing any wheels. The wheels are out there, I can 
> learn how they're built, and decide to use them in a vehicle that is easier 
> to 
> driver than what's already out there and that'll stay on track if one of the 
> wheels gets loose.
> 
>> Site24x7 APM Insight: [yeah, right]
> 
> Adding commercials to emails is not a particularly good idea IMHO.
> --
> Site24x7 APM Insight: Get Deep Visibility into Application Performance
> APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month
> Monitor end-to-end web transactions and take corrective actions now
> Troubleshoot faster and improve end-user experience. Signup Now!
> http://pubads.g.doubleclick.net/gampad/clk?id=272487151=/4140
> ___
> Owfs-developers mailing list
> Owfs-developers@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/owfs-developers

--
Site24x7 APM Insight: Get Deep Visibility into Application Performance
APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month
Monitor end-to-end web transactions and take corrective actions now
Troubleshoot faster and improve end-user experience. Signup Now!
http://pubads.g.doubleclick.net/gampad/clk?id=272487151=/4140
___
Owfs-developers mailing list
Owfs-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/owfs-developers

Re: [Owfs-developers] To the people willing to look at what I am thinking about for control systems

[Colin Reese]

I think that by specifying no center you make the problem hard, and 
unnecessarily so. Otherwise it is infinitely easier. Why must you have no 
center? If necessary, you can make a couple or few gateways that sync and talk 
to other dumb(er) nodes. 

C

> On Feb 7, 2016, at 12:39 PM, Jerry Scharf  
> wrote:
> 
> Hi,
> 
> A while ago I had asked if anyone was interested in working on a new building 
> automation control system. There were some who were willing to review and 
> comment on it. I am going to avail myself of those kind people.
> 
> Here is a problem statement that I wrote up about how to move to what I think 
> of as a distributed building automation system. I would love comments on 
> this. This should probably happen off the list so the spam is kept to a 
> minimum. One of the pieces of this would be a 1-wire gateway to the messaging 
> system.
> 
> thanks,
> jerry
> 
> 
> --
> Site24x7 APM Insight: Get Deep Visibility into Application Performance
> APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month
> Monitor end-to-end web transactions and take corrective actions now
> Troubleshoot faster and improve end-user experience. Signup Now!
> http://pubads.g.doubleclick.net/gampad/clk?id=272487151=/4140
> ___
> Owfs-developers mailing list
> Owfs-developers@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/owfs-developers

--
Site24x7 APM Insight: Get Deep Visibility into Application Performance
APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month
Monitor end-to-end web transactions and take corrective actions now
Troubleshoot faster and improve end-user experience. Signup Now!
http://pubads.g.doubleclick.net/gampad/clk?id=272487151=/4140
___
Owfs-developers mailing list
Owfs-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/owfs-developers

Re: [Owfs-developers] help me in building a next generation HVAC system

[Colin Reese]

Jerry,

I think database is still the way to go. It's not either or with messaging, and 
chronological data is great to have and in some cases necessary (e.g. for PID). 
It allows conditional abstraction for arbitrary logic, so a condition like this 
is automatically parsed and processed: 

[controldb:io:processedvalue:id=28ae436bddccbbaa] > 24 and 
[controldb:io:processedvalue:name=myvalve]==False

For SMS try email to text. I use gmail in Python and it works great. 

C

> On Jan 1, 2016, at 6:20 PM, Jerry Scharf  
> wrote:
> 
> Jan,
> 
> Thanks for pointing this out. I will raise this up the priority in the 
> project.
> 
> I have some ideas for certain things that can happen autonomously, but 
> the issue with a highly integrated system driven by a few critical 
> pieces is that it all runs or dies together. All the valves won't deal 
> with a failed boiler and my experience is that my control hardware and 
> software has been more robust than equipment it drives.
> 
> I also need to get an SMS interface going to tell me when things are amiss.
> 
> I treat life safety stuff very differently from comfort stuff. Where I 
> live, HVAC is rarely a life threatening issue. In very cold places, it 
> is much more critical.
> 
> Happy new year,
> jerry
> 
>> On 12/31/2015 11:46 PM, Jan Kandziora wrote:
>>> Am 31.12.2015 um 21:59 schrieb Jerry Scharf:
>>> I've been lurking for a while. This isn't exactly 1-wire related, but I
>>> know a bunch of people on this list are interested in control systems.
>> As I'm doing a similar thing professionally (with Onewire, OWFS, Tcl,
>> Raspi), I first want to point out the most crucial thing all the
>> existing solutions lacked was proper handling of fault modes. It makes
>> out 1/3 of all my application and I still don't think I have enough code
>> to catch and recover from *all* errors in the finest granularity possible.
>> 
>> So if you want to design something unique and useful, start with
>> thinking about what could happen to the sensor boards when they are
>> power-cycled, as that is the most common fault. Next, what happens on
>> various kinds of lost communication. Which component in the tree should
>> detect it, how is it escalated, who retry/recovers it and so on.
>> 
>> For most important things (outputs controlling beer valves ^_^;) I even
>> have a watchdog timer on the peripherals which turn them off
>> automatically if the board hasn't had communication with the next
>> upstream hop within 10 seconds.
>> 
>> 
>> Another thing is the abstraction needed. I have different generations of
>> boards which may be mixed in any system installed. For me, outputs are
>> mostly valves of different kinds (tap and lock valves for beverages,
>> valves for switching barrels, valves controlling detergent lye and
>> water) and inputs are either switches, counters or buttons. This is
>> already on the lowest level.
>> 
>> Some more abstraction is done on the upper levels, too, but it came to
>> me it is crucial to have support for some basic abstractions on the most
>> lowest levels to implement proper fail-safe behaviour. That is, the
>> Raspi controlling your window blind C3 should know what the fail-safe
>> state for it is - open or closed, so it can reach it without the help of
>> the main program. And if the peripheral has support for configuring and
>> fail-safe state and reacts on it's own subsequently, this should be
>> configureable in an abstracted way.
>> 
>> 
>> In my system, I have done a class hierarchy which covers both aspects.
>> Objects are storing an internal representation of the state of the
>> peripheral and managing it through the line of programmed events, and,
>> to recover from exceptional situations, in two interrupt loops (one
>> timed, one based on conditional search). That way it's able to catch and
>> recover from such things as pulled mains cables at the peripherals
>> within seconds.
>> 
>> 
>> Oh, and I think you are on the edge here. All my system could do is to
>> lock you from beer, yours could lock you up in your house and tell noone.
>> 
>> Kind regards
>> 
>>Jan
>> 
>> --
>> ___
>> Owfs-developers mailing list
>> Owfs-developers@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/owfs-developers
> 
> 
> --
> ___
> Owfs-developers mailing list
> Owfs-developers@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/owfs-developers

--
___
Owfs-developers mailing list
Owfs-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/owfs-developers

Re: [Owfs-developers] Devices listed multiple times

[Colin Reese]

Can somebody explain to me why on earth people use so many 1wire buses? Do many 
use hundreds of devices and need to split them across buses? That thing has 17 
1wire channels. I have never had need for more than 1, even with >100 sensors. 
The whole beauty of 1Wire is extendable single bus multi drop!

Colin


> On Dec 31, 2015, at 12:17 AM, Henrik Östman  wrote:
> 
> Hello!
> 
> I have a question, why does some of my 1-wire devices get listed several 
> times by OWFS? They have the same ID and inode-number, so now my 
> application have to filter out the duplicates.
> I'm running OWSERVER:
> 
> owserver version:
> 2.8p15
> libow version:
> 2.8p15
> 
> On a Raspberry Pi with a AbioWire+ card: 
> https://www.m.nu/pdf/AbioWire_Plus_um_en_us_2015_03_02.pdf
> Some of the 1-wire devices are connected to different connectors on the 
> AbioWire-card.
> 
> When I list the devices with OWFS it look like this (first column is 
> inode number):
> 
> trycoon@dixie:/mnt/1wire$ ls -li
> totalt 0
>  3 drwxrwxrwx 1 root root  8 dec 30 23:56 05.4AEC29CDBAAB
>  6 drwxrwxrwx 1 root root  8 dec 30 23:56 10.0C92B5010800
>  6 drwxrwxrwx 1 root root  8 dec 30 23:56 10.0C92B5010800
> 11 drwxrwxrwx 1 root root  8 dec 30 23:56 10.158DB5010800
>  8 drwxrwxrwx 1 root root  8 dec 30 23:56 10.52A9B5010800
>  8 drwxrwxrwx 1 root root  8 dec 30 23:56 10.52A9B5010800
>  2 drwxrwxrwx 1 root root  8 dec 30 23:56 10.67C6697351FF
> 14 drwxrwxrwx 1 root root  8 dec 30 23:56 10.7F0560010800
> 10 drwxrwxrwx 1 root root  8 dec 30 23:56 10.969D98010800
> 10 drwxrwxrwx 1 root root  8 dec 30 23:56 10.969D98010800
>  7 drwxrwxrwx 1 root root  8 dec 30 23:56 10.AC1A60010800
> 13 drwxrwxrwx 1 root root  8 dec 30 23:56 10.B74C8A010800
>  9 drwxrwxrwx 1 root root  8 dec 30 23:56 10.C9E69E010800
> 12 drwxrwxrwx 1 root root  8 dec 30 23:56 29.3E4D1300
> 12 drwxrwxrwx 1 root root  8 dec 30 23:56 29.3E4D1300
> 15 drwxrwxrwx 1 root root  8 dec 30 23:56 29.4D4D1300
>  5 drwxrwxrwx 1 root root  8 dec 30 23:56 29.54F81BE8E78D
>  4 drwxrwxrwx 1 root root  8 dec 30 23:56 3A.F2FBE3467CC2
> 24 drwxr-xr-x 1 root root  8 dec 30 23:32 alarm
> 17 drwxr-xr-x 1 root root  8 dec 30 23:32 bus.0
> 16 drwxr-xr-x 1 root root  8 dec 30 23:32 bus.1
> 19 drwxr-xr-x 1 root root  8 dec 30 23:32 settings
> 23 drwxrwxrwx 1 root root  8 dec 30 23:56 simultaneous
> 21 drwxr-xr-x 1 root root  8 dec 30 23:32 statistics
> 22 drwxr-xr-x 1 root root 32 dec 30 23:32 structure
> 20 drwxr-xr-x 1 root root  8 dec 30 23:32 system
> 18 drwxr-xr-x 1 root root  8 dec 30 23:32 uncached
> 
> I use this setting in owfs.conf:
> 
> server: i2c = ALL:ALL
> 
> 
> UPDATE:
> 
> I think I solved the problem but I don't know why it's working, maybe 
> someone could explain it for me?
> I changed the settings in owfs.conf to this:
> 
> server: device = /dev/i2c-1
> #server: i2c = ALL:ALL
> 
> Now the list looks like this:
> 
> trycoon@dixie:/mnt/1wire$ ls -li
> totalt 0
>  3 drwxrwxrwx 1 root root  8 dec 31 09:16 05.4AEC29CDBAAB
>  7 drwxrwxrwx 1 root root  8 dec 31 09:16 10.0C92B5010800
> 10 drwxrwxrwx 1 root root  8 dec 31 09:16 10.158DB5010800
>  9 drwxrwxrwx 1 root root  8 dec 31 09:16 10.52A9B5010800
>  2 drwxrwxrwx 1 root root  8 dec 31 09:16 10.67C6697351FF
> 14 drwxrwxrwx 1 root root  8 dec 31 09:16 10.7F0560010800
> 11 drwxrwxrwx 1 root root  8 dec 31 09:16 10.969D98010800
>  6 drwxrwxrwx 1 root root  8 dec 31 09:16 10.AC1A60010800
> 12 drwxrwxrwx 1 root root  8 dec 31 09:16 10.B74C8A010800
>  8 drwxrwxrwx 1 root root  8 dec 31 09:16 10.C9E69E010800
> 13 drwxrwxrwx 1 root root  8 dec 31 09:16 29.3E4D1300
> 15 drwxrwxrwx 1 root root  8 dec 31 09:16 29.4D4D1300
>  5 drwxrwxrwx 1 root root  8 dec 31 09:16 29.54F81BE8E78D
>  4 drwxrwxrwx 1 root root  8 dec 31 09:16 3A.F2FBE3467CC2
> 24 drwxr-xr-x 1 root root  8 dec 31 09:12 alarm
> 17 drwxr-xr-x 1 root root  8 dec 31 09:12 bus.0
> 16 drwxr-xr-x 1 root root  8 dec 31 09:12 bus.1
> 19 drwxr-xr-x 1 root root  8 dec 31 09:12 settings
> 23 drwxrwxrwx 1 root root  8 dec 31 09:16 simultaneous
> 21 drwxr-xr-x 1 root root  8 dec 31 09:12 statistics
> 22 drwxr-xr-x 1 root root 32 dec 31 09:12 structure
> 20 drwxr-xr-x 1 root root  8 dec 31 09:12 system
> 18 drwxr-xr-x 1 root root  8 dec 31 09:12 uncached
> 
> Thanks!
> 
> // Henrik
> 
> --
> ___
> Owfs-developers mailing list
> Owfs-developers@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/owfs-developers

--
___
Owfs-developers mailing list
Owfs-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/owfs-developers

Re: [Owfs-developers] Introduce support for DS28E17 (1-Wire-to-I2C Master Bridge)

[Colin Reese]

I can see no reason for not using moat, aside from differences in failure 
state, if any. 

C

> On Dec 29, 2015, at 10:43 AM, Jan Kandziora  wrote:
> 
>> Am 29.12.2015 um 16:39 schrieb Ursin Soler:
>> 
>> By this year (initial release 7/15) Maxim released the DS28E17 [1]
>> which is in my oppinion a game changer.
> I like to add, the DS28E17 is only available in a very tiny 16TQFN-EP
> package, which is very hard to solder by hand (0.5mm pitch, no leads) so
> I doubt anyone of us hobbyists is going to use that chip unless someone
> sells it on a pinned 2.54mm pitch adapter board.
> 
> For me, I'd rather use Pascal Berten's BAE0911, which has I²C bridging
> functionality, and implement the neccesary logic with the chip's
> automation engine. Or do the same with Matthias' MOAT, I could use an
> arbitrary Atmel AVR chip then.
> 
> Kind regards
> 
>Jan
> 
> 
> 
> 
> 
> --
> ___
> Owfs-developers mailing list
> Owfs-developers@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/owfs-developers

--
___
Owfs-developers mailing list
Owfs-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/owfs-developers

Re: [Owfs-developers] Server side Commands

[Colin Reese]

You will have permissions issues with the user www-data. Attempting to run 
system services from a web application is an attempt to subvert the security 
limitations of this user, which are there for good reason. 

The other issue is that this approach does not have a way of killing services, 
so you will just keep attempting to spawn multiple instances with multiple 
clicks. 

A way to do this in a more sane way (and to avoid the permissions issues) would 
be to store the value of a variable, say 'runowserver' in a database, then have 
a system daemon script handle it. If the variable is 0, you could then have it 
run an owserver stop or pkill. 

I run the start function at boot, which you can see at the top here:

https://github.com/iinnovations/iicontrollibs/blob/master/cupid/boot.py

It doesn't actually pull a db variable, but you can see easily in the script 
how to do that (e.g. see where the web server type is read from the db). 

C

> On Dec 27, 2015, at 7:35 AM, Mike Kalist  wrote:
> 
> Hi All  I know this is probably not the right place for this  but  after 
> hours  of google   thought i wold throw this out there.
> 
> I want to make a local website to send commands to pi all on local server
> 
> push button   on click  send a server side command   /opt/owfs/bin/owserver 
> -a alias.txt -u -p 3000  
> 
> 
> I have a scripts bash and perl   and tried to run them on click with no 
> success 
> 
> Any help would be greatly appreciated.
> 
> 
> Mike
> 
> 
> --
> ___
> Owfs-developers mailing list
> Owfs-developers@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/owfs-developers

--
___
Owfs-developers mailing list
Owfs-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/owfs-developers

Re: [Owfs-developers] 3.1p1 release, anyone?

[Colin Reese]

I see. I did not grasp that the sf repo was in fact a git repo. That is
where I had been grabbing things from, but not with git.

C

On Mon, Nov 23, 2015 at 11:30 AM, Johan Ström <jo...@stromnet.se> wrote:

> On 23/11/15 20:20, Jan Kandziora wrote:
> > Am 23.11.2015 um 19:15 schrieb Colin Reese:
> >> No, I am indeed using:
> >>
> >> https://github.com/M-o-a-T/owfs.git
> >>
> >> Where is the main archive?
> >>
> > $ git clone git://git.code.sf.net/p/owfs/code owfs-code
> >
> >
> Note that it is the main *owfs* repo. There is no moat code there. Yet!
> For moat, the main repo (as far as I know, but as mentioned earlier,
> broken at the moment), is https://github.com/M-o-a-T/owfs.git.
>
>
> --
> Go from Idea to Many App Stores Faster with Intel(R) XDK
> Give your users amazing mobile app experiences with Intel(R) XDK.
> Use one codebase in this all-in-one HTML5 development environment.
> Design, debug & build mobile apps & 2D/3D high-impact games for multiple
> OSs.
> http://pubads.g.doubleclick.net/gampad/clk?id=254741551=/4140
> ___
> Owfs-developers mailing list
> Owfs-developers@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/owfs-developers
>
--
Go from Idea to Many App Stores Faster with Intel(R) XDK
Give your users amazing mobile app experiences with Intel(R) XDK.
Use one codebase in this all-in-one HTML5 development environment.
Design, debug & build mobile apps & 2D/3D high-impact games for multiple OSs.
http://pubads.g.doubleclick.net/gampad/clk?id=254741551=/4140___
Owfs-developers mailing list
Owfs-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/owfs-developers

Re: [Owfs-developers] 3.1p1 release, anyone?

[Colin Reese]

Yes, I'm on master.

Thanks,
Colin


On 11/23/2015 10:15 AM, Jan Kandziora wrote:
> Am 23.11.2015 um 19:01 schrieb Colin Reese:
>> To double check can you point me to it? I've lost things in this pile of 
>> mails.
>>
> I see now Matthias has merged the newest changes from the main
> repository two days ago. So there shouldn't be a problem if you'd
> recompiled the host code yesterday. Double-check you checked out the
> "master" branch of his repository when compiling, not "export".
>
> Kind regards
>
>   Jan
>
>
> --
> Go from Idea to Many App Stores Faster with Intel(R) XDK
> Give your users amazing mobile app experiences with Intel(R) XDK.
> Use one codebase in this all-in-one HTML5 development environment.
> Design, debug & build mobile apps & 2D/3D high-impact games for multiple OSs.
> http://pubads.g.doubleclick.net/gampad/clk?id=254741551=/4140
> ___
> Owfs-developers mailing list
> Owfs-developers@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/owfs-developers


--
Go from Idea to Many App Stores Faster with Intel(R) XDK
Give your users amazing mobile app experiences with Intel(R) XDK.
Use one codebase in this all-in-one HTML5 development environment.
Design, debug & build mobile apps & 2D/3D high-impact games for multiple OSs.
http://pubads.g.doubleclick.net/gampad/clk?id=254741551=/4140
___
Owfs-developers mailing list
Owfs-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/owfs-developers

Re: [Owfs-developers] 3.1p1 release, anyone?

[Colin Reese]

No, I am indeed using:

https://github.com/M-o-a-T/owfs.git

Where is the main archive? I don't think I've even ever pulled from 
that, and a quick google doesn't reveal an obvious location to me. I 
have been rebuilding 2.9 for some time previous to trying to get these 
Moat slaves working.

Colin


On 11/23/2015 9:56 AM, Jan Kandziora wrote:
> Am 23.11.2015 um 18:22 schrieb Colin Reese:
>> I did not rebuild my slave. Everything else is nice and fresh as of last 
>> night.
>>
> Ok, I ask more specifically: Matthias' owfs archive clone is a bit
> dated. Did you use that one or have you exported the moat patch and
> merged it into your main archive clone?
>
> By the way: It would be nice to have a proper moat patch available for
> testing.
>
> Kind regards
>
>   Jan
>
>
>
> --
> Go from Idea to Many App Stores Faster with Intel(R) XDK
> Give your users amazing mobile app experiences with Intel(R) XDK.
> Use one codebase in this all-in-one HTML5 development environment.
> Design, debug & build mobile apps & 2D/3D high-impact games for multiple OSs.
> http://pubads.g.doubleclick.net/gampad/clk?id=254741551=/4140
> ___
> Owfs-developers mailing list
> Owfs-developers@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/owfs-developers


--
Go from Idea to Many App Stores Faster with Intel(R) XDK
Give your users amazing mobile app experiences with Intel(R) XDK.
Use one codebase in this all-in-one HTML5 development environment.
Design, debug & build mobile apps & 2D/3D high-impact games for multiple OSs.
http://pubads.g.doubleclick.net/gampad/clk?id=254741551=/4140
___
Owfs-developers mailing list
Owfs-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/owfs-developers

Re: [Owfs-developers] 3.1p1 release, anyone?

[Colin Reese]

I've got my DS490R up and recognizing my Moat device, with a DS18B20 
also connected I get:

28.246A5005  alarm  F0.18FDE6789C56  simultaneous  structure uncached
81.D39F2D00  bus.0  settings statisticssystem

Reading the directory gives the following:

ls /var/1wire/F0.18FDE6789C56
address  alias   console  family  loader   r_address  r_id
alarmconfig  crc8 id  locator  rawr_locator

It also, however, crashes owserver. Owfs still lives.

Last debug looks like this. Looks like it cycles through all ports, pwm, 
etc.:



CALL: ow_parsename.c:(104) path=[/F0.18FDE6789C56/port.27]
   DEBUG: ow_regex.c:(154) Not found
   DEBUG: ow_regex.c:(201) 0: 0->15 found <><>
   DEBUG: ow_regex.c:(201) 1: 0->2 found <><.18FDE6789C56>
   DEBUG: ow_regex.c:(201) 2: 3->15 found <18FDE6789C56><>
   DEBUG: ow_cache.c:(912) Looking for device F0 18 FD E6 78 9C 56 F6
   DEBUG: ow_cache.c:(1070) Search in cache sn F0 18 FD E6 78 9C 56 F6 
pointer=0xb6f04790 index=0 size=4
   DEBUG: ow_cache.c:(1086) Value found in cache. Remaining life: 79 
seconds.
   DEBUG: ow_presence.c:(75) Found device on bus 0
   DEBUG: ow_regex.c:(201) 0: 4->5 found <.><27>
   DEBUG: ow_regex.c:(201) 0: 4->7 found <.27><>
   DEBUG: ow_cache.c:(941) F0 18 FD E6 78 9C 56 F6 size=12
   DEBUG: ow_cache.c:(1070) Search in cache sn F0 18 FD E6 78 9C 56 F6 
pointer=0xb6f00f70 index=-2 size=12
   DEBUG: ow_cache.c:(1086) Value found in cache. Remaining life: 299 
seconds.
   DEBUG: ow_parsename.c:(63) /F0.18FDE6789C56/port.27
CALL: ow_parsename.c:(104) path=[/F0.18FDE6789C56/port.28]
   DEBUG: ow_regex.c:(154) Not found
   DEBUG: ow_regex.c:(201) 0: 0->15 found <><>
   DEBUG: ow_regex.c:(201) 1: 0->2 found <><.18FDE6789C56>
   DEBUG: ow_regex.c:(201) 2: 3->15 found <18FDE6789C56><>
   DEBUG: ow_cache.c:(912) Looking for device F0 18 FD E6 78 9C 56 F6
   DEBUG: ow_cache.c:(1070) Search in cache sn F0 18 FD E6 78 9C 56 F6 
pointer=0xb6f04790 index=0 size=4
   DEBUG: ow_cache.c:(1086) Value found in cache. Remaining life: 79 
seconds.
   DEBUG: ow_presence.c:(75) Found device on bus 0
   DEBUG: ow_regex.c:(201) 0: 4->5 found <.><28>
   DEBUG: ow_regex.c:(201) 0: 4->7 found <.28><>
   DEBUG: ow_cache.c:(941) F0 18 FD E6 78 9C 56 F6 size=12
   DEBUG: ow_cache.c:(1070) Search in cache sn F0 18 FD E6 78 9C 56 F6 
pointer=0xb6f00f70 index=-2 size=12
   DEBUG: ow_cache.c:(1086) Value found in cache. Remaining life: 299 
seconds.
   DEBUG: ow_parsename.c:(63) /F0.18FDE6789C56/port.28
CALL: ow_parsename.c:(104) path=[/F0.18FDE6789C56/port.29]
   DEBUG: ow_regex.c:(154) Not found
   DEBUG: ow_regex.c:(201) 0: 0->15 found <><>
   DEBUG: ow_regex.c:(201) 1: 0->2 found <><.18FDE6789C56>
   DEBUG: ow_regex.c:(201) 2: 3->15 found <18FDE6789C56><>
   DEBUG: ow_cache.c:(912) Looking for device F0 18 FD E6 78 9C 56 F6
   DEBUG: ow_cache.c:(1070) Search in cache sn F0 18 FD E6 78 9C 56 F6 
pointer=0xb6f04790 index=0 size=4
   DEBUG: ow_cache.c:(1086) Value found in cache. Remaining life: 79 
seconds.
   DEBUG: ow_presence.c:(75) Found device on bus 0
   DEBUG: ow_regex.c:(201) 0: 4->5 found <.><29>
   DEBUG: ow_regex.c:(201) 0: 4->7 found <.29><>
   DEBUG: ow_cache.c:(941) F0 18 FD E6 78 9C 56 F6 size=12
   DEBUG: ow_cache.c:(1070) Search in cache sn F0 18 FD E6 78 9C 56 F6 
pointer=0xb6f00f70 index=-2 size=12
   DEBUG: ow_cache.c:(1086) Value found in cache. Remaining life: 299 
seconds.
   DEBUG: ow_parsename.c:(63) /F0.18FDE6789C56/port.29
CALL: ow_parsename.c:(104) path=[/F0.18FDE6789C56/port.30]
   DEBUG: ow_regex.c:(154) Not found
   DEBUG: ow_regex.c:(201) 0: 0->15 found <><>
   DEBUG: ow_regex.c:(201) 1: 0->2 found <><.18FDE6789C56>
   DEBUG: ow_regex.c:(201) 2: 3->15 found <18FDE6789C56><>
   DEBUG: ow_cache.c:(912) Looking for device F0 18 FD E6 78 9C 56 F6
   DEBUG: ow_cache.c:(1070) Search in cache sn F0 18 FD E6 78 9C 56 F6 
pointer=0xb6f04790 index=0 size=4
   DEBUG: ow_cache.c:(1086) Value found in cache. Remaining life: 79 
seconds.
   DEBUG: ow_presence.c:(75) Found device on bus 0
   DEBUG: ow_regex.c:(201) 0: 4->5 found <.><30>
   DEBUG: ow_regex.c:(201) 0: 4->7 found <.30><>
   DEBUG: ow_cache.c:(941) F0 18 FD E6 78 9C 56 F6 size=12
   DEBUG: ow_cache.c:(1070) Search in cache sn F0 18 FD E6 78 9C 56 F6 
pointer=0xb6f00f70 index=-2 size=12
   DEBUG: ow_cache.c:(1086) Value found in cache. Remaining life: 299 
seconds.
   DEBUG: ow_parsename.c:(63) /F0.18FDE6789C56/port.30
CALL: ow_parsename.c:(104) path=[/F0.18FDE6789C56/port.31]
   DEBUG: ow_regex.c:(154) Not found
   DEBUG: ow_regex.c:(201) 0: 0->15 found <><>
   DEBUG: ow_regex.c:(201) 1: 0->2 found <><.18FDE6789C56>
   DEBUG: ow_regex.c:(201) 2: 3->15 found <18FDE6789C56><>
   DEBUG: ow_cache.c:(912) Looking for device F0 18 FD E6 78 9C 56 F6
   DEBUG: ow_cache.c:(1070) Search in cache sn F0 18 FD E6 78 9C 56 F6 
pointer=0xb6f04790 index=0 size=4
   DEBUG: ow_cache.c:(1086) Value found in cache. Remaining life: 79 
seconds.
   DEBUG: ow_presence.c:(75) 

Re: [Owfs-developers] 3.1p1 release, anyone?

[Colin Reese]

Another datum:

Same result on i2c with DS2483.

C

On 11/23/2015 12:51 AM, Colin Reese wrote:
> I've got my DS490R up and recognizing my Moat device, with a DS18B20 
> also connected I get:
>
> 28.246A5005  alarm  F0.18FDE6789C56  simultaneous  structure uncached
> 81.D39F2D00  bus.0  settings statisticssystem
>
> Reading the directory gives the following:
>
> ls /var/1wire/F0.18FDE6789C56
> address  alias   console  family  loader   r_address  r_id
> alarmconfig  crc8 id  locator  rawr_locator
>
> It also, however, crashes owserver. Owfs still lives.
>
> Last debug looks like this. Looks like it cycles through all ports, 
> pwm, etc.:
>
>
>


--
Go from Idea to Many App Stores Faster with Intel(R) XDK
Give your users amazing mobile app experiences with Intel(R) XDK.
Use one codebase in this all-in-one HTML5 development environment.
Design, debug & build mobile apps & 2D/3D high-impact games for multiple OSs.
http://pubads.g.doubleclick.net/gampad/clk?id=254741551=/4140
___
Owfs-developers mailing list
Owfs-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/owfs-developers

Re: [Owfs-developers] 3.1p1 release, anyone?

[Colin Reese]

I did not rebuild my slave. Everything else is nice and fresh as of last night. 

C

> On Nov 23, 2015, at 5:42 AM, Jan Kandziora <j...@gmx.de> wrote:
> 
>> Am 23.11.2015 um 09:51 schrieb Colin Reese:
>> I've got my DS490R up and recognizing my Moat device, with a DS18B20 
>> also connected I get:
>> 
>> 28.246A5005  alarm  F0.18FDE6789C56  simultaneous  structure uncached
>> 81.D39F2D00  bus.0  settings statisticssystem
>> 
>> Reading the directory gives the following:
>> 
>> ls /var/1wire/F0.18FDE6789C56
>> address  alias   console  family  loader   r_address  r_id
>> alarmconfig  crc8 id  locator  rawr_locator
>> 
>> It also, however, crashes owserver. Owfs still lives.
> Do you use the latest version from the git archive as the base for your
> MOAT tests? There are some quirks with dynamic properties and using a
> two- or more-hop setup. I fixed this for "external" sensors in the
> archive but maybe the MOAT needs similar fixes.
> 
> Kind regards
> 
>Jan
> 
> --
> Go from Idea to Many App Stores Faster with Intel(R) XDK
> Give your users amazing mobile app experiences with Intel(R) XDK.
> Use one codebase in this all-in-one HTML5 development environment.
> Design, debug & build mobile apps & 2D/3D high-impact games for multiple OSs.
> http://pubads.g.doubleclick.net/gampad/clk?id=254741551=/4140
> ___
> Owfs-developers mailing list
> Owfs-developers@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/owfs-developers

--
Go from Idea to Many App Stores Faster with Intel(R) XDK
Give your users amazing mobile app experiences with Intel(R) XDK.
Use one codebase in this all-in-one HTML5 development environment.
Design, debug & build mobile apps & 2D/3D high-impact games for multiple OSs.
http://pubads.g.doubleclick.net/gampad/clk?id=254741551=/4140
___
Owfs-developers mailing list
Owfs-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/owfs-developers

Re: [Owfs-developers] 3.1p1 release, anyone?

[Colin Reese]

I checked out moat and merged. 

> On Nov 23, 2015, at 9:56 AM, Jan Kandziora <j...@gmx.de> wrote:
> 
>> Am 23.11.2015 um 18:22 schrieb Colin Reese:
>> I did not rebuild my slave. Everything else is nice and fresh as of last 
>> night.
> Ok, I ask more specifically: Matthias' owfs archive clone is a bit
> dated. Did you use that one or have you exported the moat patch and
> merged it into your main archive clone?
> 
> By the way: It would be nice to have a proper moat patch available for
> testing.
> 
> Kind regards
> 
>Jan
> 
> 
> 
> --
> Go from Idea to Many App Stores Faster with Intel(R) XDK
> Give your users amazing mobile app experiences with Intel(R) XDK.
> Use one codebase in this all-in-one HTML5 development environment.
> Design, debug & build mobile apps & 2D/3D high-impact games for multiple OSs.
> http://pubads.g.doubleclick.net/gampad/clk?id=254741551=/4140
> ___
> Owfs-developers mailing list
> Owfs-developers@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/owfs-developers

--
Go from Idea to Many App Stores Faster with Intel(R) XDK
Give your users amazing mobile app experiences with Intel(R) XDK.
Use one codebase in this all-in-one HTML5 development environment.
Design, debug & build mobile apps & 2D/3D high-impact games for multiple OSs.
http://pubads.g.doubleclick.net/gampad/clk?id=254741551=/4140
___
Owfs-developers mailing list
Owfs-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/owfs-developers

Re: [Owfs-developers] 3.1p1 release, anyone?

[Colin Reese]

To double check can you point me to it? I've lost things in this pile of mails. 

> On Nov 23, 2015, at 9:56 AM, Jan Kandziora <j...@gmx.de> wrote:
> 
>> Am 23.11.2015 um 18:22 schrieb Colin Reese:
>> I did not rebuild my slave. Everything else is nice and fresh as of last 
>> night.
> Ok, I ask more specifically: Matthias' owfs archive clone is a bit
> dated. Did you use that one or have you exported the moat patch and
> merged it into your main archive clone?
> 
> By the way: It would be nice to have a proper moat patch available for
> testing.
> 
> Kind regards
> 
>Jan
> 
> 
> 
> --
> Go from Idea to Many App Stores Faster with Intel(R) XDK
> Give your users amazing mobile app experiences with Intel(R) XDK.
> Use one codebase in this all-in-one HTML5 development environment.
> Design, debug & build mobile apps & 2D/3D high-impact games for multiple OSs.
> http://pubads.g.doubleclick.net/gampad/clk?id=254741551=/4140
> ___
> Owfs-developers mailing list
> Owfs-developers@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/owfs-developers

--
Go from Idea to Many App Stores Faster with Intel(R) XDK
Give your users amazing mobile app experiences with Intel(R) XDK.
Use one codebase in this all-in-one HTML5 development environment.
Design, debug & build mobile apps & 2D/3D high-impact games for multiple OSs.
http://pubads.g.doubleclick.net/gampad/clk?id=254741551=/4140
___
Owfs-developers mailing list
Owfs-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/owfs-developers

Re: [Owfs-developers] 3.1p1 release, anyone?

[Colin Reese]

I now have moat version built fine on both 14.04LTS and deb armhf and 
will do some testing this afternoon/evening with devices. Surely, 
however, Matthias, has a better idea of whether it's ready for release.

C

On 11/22/2015 12:39 PM, Jan Kandziora wrote:
> Hi all,
>
> we have had some important fixes recently
>
> * Paul merged his regex branch.
> * Johan Ström added support for the LINK aux line.
> * Paul added some basic support for the Hobbyboards Multitemp.
> * Thomasz Torcz and Stephano Miccoli fixed the libusb0 problems
> * I myself fixed the "external" sensor code and added an explicit
>branch selection scheme to the DS2409 code.
>
> Paul doesn't seem to be available for a new release, so I ask who
> currently wields the authority to decide that. I think it's enough stuff
> for a new release, since the last one which was in March.
>
> Matthias, Johan, Colin: do you see merging the MOAT code anytime soon?
>
>
> Kind regards
>
>   Jan
>
>
> --
> ___
> Owfs-developers mailing list
> Owfs-developers@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/owfs-developers


--
___
Owfs-developers mailing list
Owfs-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/owfs-developers

Re: [Owfs-developers] Merging "moat" device specific code

[Colin Reese]

Interestingly, config runs fine on my Raspbian armhf. I'm attempting a 
make right now.

C

On 11/21/2015 5:16 PM, Gregg Levine wrote:
> Hello!
> Aren't we fighting with the moat monsters here regarding the error?
> Why not examine the entire method behind how the token is created. In
> fact how's the entire configuration script written? That should answer
> it.
>
> Meanwhile where's Paul, I'm surprised he hasn't commented by now.
> -
> Gregg C Levine gregg.drw...@gmail.com
> "This signature fought the Time Wars, time and again."
>
>
> On Sat, Nov 21, 2015 at 6:18 PM, Colin Reese <colin.re...@gmail.com> wrote:
>> Looks like same error:
>>
>> ./configure: line 16287: syntax error near unexpected token `LIBUSB,'
>> ./configure: line 16287: `  PKG_CHECK_MODULES(LIBUSB, libusb-1.0 >=
>> 0.9.1, ENABLE_USB=true,ENABLE_USB=false)'
>>
>> C
>>
>>
>> On 11/20/2015 10:46 PM, Colin Reese wrote:
>>
>> standard owfs builds fine on amhf debian, with owfs-moat results previously
>> reported.
>>
>> On ubuntu 14.04 LTS, owfs standard owfs 3.0.2 config is fine. owfs-moat
>> gives:
>>
>> ./configure: line 16305: syntax error near unexpected token `LIBUSB,'
>> ./configure: line 16305: `  PKG_CHECK_MODULES(LIBUSB, libusb-1.0 >=
>> 0.9.1, ENABLE_USB=true,ENABLE_USB=false)'
>>
>> C
>>
>>
>> On 11/16/2015 12:04 AM, Johan Ström wrote:
>>
>> That's not moat-related, nor owfs-related: "Internal compiler error".
>> I'd check for updates on your env, or change Linux dist or something.
>>
>> For the record, line 476 of ow_moat.c is
>>
>> static ZERO_OR_ERROR FS_r_alarm_status(struct one_wire_query *owq)
>>
>> i.e nothing fancy at all.
>>
>>
>> On 16/11/15 01:10, Colin Reese wrote:
>>
>> After bootstrap and configure, I get the following on make:
>>
>> ow_moat.c:476:22: internal compiler error: in set_lattice_value, at
>> tree-ssa-ccp.c:457
>>
>> C
>>
>>
>>
>>
>> --
>> Presto, an open source distributed SQL query engine for big data, initially
>> developed by Facebook, enables you to easily query your data on Hadoop in a
>> more interactive manner. Teradata is also now providing full enterprise
>> support for Presto. Download a free open source copy now.
>> http://pubads.g.doubleclick.net/gampad/clk?id=250295911=/4140
>>
>>
>>
>> ___
>> Owfs-developers mailing list
>> Owfs-developers@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/owfs-developers
>>
>>
>>
>>
>> --
>>
>> ___
>> Owfs-developers mailing list
>> Owfs-developers@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/owfs-developers
>>
> --
> ___
> Owfs-developers mailing list
> Owfs-developers@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/owfs-developers


--
___
Owfs-developers mailing list
Owfs-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/owfs-developers

Re: [Owfs-developers] Merging "moat" device specific code

[Colin Reese]

Looks like same error:

./configure: line 16287: syntax error near unexpected token `LIBUSB,'
./configure: line 16287: `  PKG_CHECK_MODULES(LIBUSB, libusb-1.0 >= 
0.9.1, ENABLE_USB=true,ENABLE_USB=false)'


C

On 11/20/2015 10:46 PM, Colin Reese wrote:
standard owfs builds fine on amhf debian, with owfs-moat results 
previously reported.


On ubuntu 14.04 LTS, owfs standard owfs 3.0.2 config is fine. 
owfs-moat gives:


./configure: line 16305: syntax error near unexpected token `LIBUSB,'
./configure: line 16305: `  PKG_CHECK_MODULES(LIBUSB, libusb-1.0 
>= 0.9.1, ENABLE_USB=true,ENABLE_USB=false)'


C


On 11/16/2015 12:04 AM, Johan Ström wrote:

That's not moat-related, nor owfs-related: "Internal compiler error".
I'd check for updates on your env, or change Linux dist or something.

For the record, line 476 of ow_moat.c is

static ZERO_OR_ERROR FS_r_alarm_status(struct one_wire_query *owq)

i.e nothing fancy at all.


On 16/11/15 01:10, Colin Reese wrote:

After bootstrap and configure, I get the following on make:

ow_moat.c:476:22: internal compiler error: in set_lattice_value, at 
tree-ssa-ccp.c:457


C




--
Presto, an open source distributed SQL query engine for big data, initially
developed by Facebook, enables you to easily query your data on Hadoop in a
more interactive manner. Teradata is also now providing full enterprise
support for Presto. Download a free open source copy now.
http://pubads.g.doubleclick.net/gampad/clk?id=250295911=/4140


___
Owfs-developers mailing list
Owfs-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/owfs-developers




--
___
Owfs-developers mailing list
Owfs-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/owfs-developers

Re: [Owfs-developers] Merging "moat" device specific code

[Colin Reese]

Now this error on make on armhf:

In file included from ../include/ow_devices.h:56:0,
  from ow_daemon.c:14:
../include/ow_moat.h:93:1: error: expected identifier before '<<' token
../include/ow_moat.h:104:20: warning: 's_names' defined but not used 
[-Wunused-variable]
Makefile:1001: recipe for target 'ow_daemon.lo' failed


C

On 11/21/2015 6:29 AM, Matthias Urlichs wrote:
> On 21.11.2015 07:46, Colin Reese wrote:
>> standard owfs builds fine on amhf debian, with owfs-moat results
>> previously reported.
>>
>> On ubuntu 14.04 LTS, owfs standard owfs 3.0.2 config is fine. owfs-moat
>> gives:
>>
> MoaT patch is based on 3.1, which has/had some issues with libusb.
>
> I have pushed a merge to the current main branch to
> github/m-o-a-t/owfs, which hopefully fixes this.
>


--
___
Owfs-developers mailing list
Owfs-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/owfs-developers

Re: [Owfs-developers] Merging "moat" device specific code

[Colin Reese]

standard owfs builds fine on amhf debian, with owfs-moat results 
previously reported.


On ubuntu 14.04 LTS, owfs standard owfs 3.0.2 config is fine. owfs-moat 
gives:


./configure: line 16305: syntax error near unexpected token `LIBUSB,'
./configure: line 16305: `  PKG_CHECK_MODULES(LIBUSB, libusb-1.0 >= 
0.9.1, ENABLE_USB=true,ENABLE_USB=false)'


C


On 11/16/2015 12:04 AM, Johan Ström wrote:

That's not moat-related, nor owfs-related: "Internal compiler error".
I'd check for updates on your env, or change Linux dist or something.

For the record, line 476 of ow_moat.c is

static ZERO_OR_ERROR FS_r_alarm_status(struct one_wire_query *owq)

i.e nothing fancy at all.


On 16/11/15 01:10, Colin Reese wrote:

After bootstrap and configure, I get the following on make:

ow_moat.c:476:22: internal compiler error: in set_lattice_value, at 
tree-ssa-ccp.c:457


C




--
Presto, an open source distributed SQL query engine for big data, initially
developed by Facebook, enables you to easily query your data on Hadoop in a
more interactive manner. Teradata is also now providing full enterprise
support for Presto. Download a free open source copy now.
http://pubads.g.doubleclick.net/gampad/clk?id=250295911=/4140


___
Owfs-developers mailing list
Owfs-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/owfs-developers


--
___
Owfs-developers mailing list
Owfs-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/owfs-developers

[Owfs-developers] Programming pulse

[Colin Reese]

While we are on adapter compatibility, I was looking at some DS1982 by request 
and noticed that it and a few other of its ilk (1985,1986) require a 
programming pulse of 12V. 

I also noted that the DS9490R, linkusb, and anything else without access to 12V 
are not compatible with this command. The DS2480B via Vpp and 9097 (2480B 
based) on DB25 with power jack appear to be capable. Any other masters that can 
do this?

C
--
Presto, an open source distributed SQL query engine for big data, initially
developed by Facebook, enables you to easily query your data on Hadoop in a 
more interactive manner. Teradata is also now providing full enterprise
support for Presto. Download a free open source copy now.
http://pubads.g.doubleclick.net/gampad/clk?id=250295911=/4140
___
Owfs-developers mailing list
Owfs-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/owfs-developers

Re: [Owfs-developers] Merging "moat" device specific code

[Colin Reese]

Thanks Johan,

My goal isn't to write an alternate master -- I just want to use the 
Atmega328 as a 1Wire slave, reading the ports (and preferably 
configuring them). My understanding is that most of this legwork is 
done, but that the support isn't merged into owfs just yet.


In the meantime, I was just trying to test out the slave devices using 
my DS9490R and some LabVIEW code I use all the time with the typical 
read/write commands. For a read scratchpad, I send in whatever byte is 
necessary to initiate the command, e.g. xBE for a DS18B20, along with a 
data buffer that is returned with the data. I was hoping I could insert 
the xF2 read byte and get data back, but I don't. I successfully find 
the ROM on the bus, and get successful returns from TMAccess and TMRom, 
but no data on TMBlockstream. My main question was whether the default 
configuration I (and you) used for compilation will return data when 
sent xF2, and if not, how that is configured. I will surely do some 
poking, but it will be uphill.


C

On 11/13/2015 11:05 AM, Johan Ström wrote:
Not sure if there is any good docs on this yet, don't think so, and 
the code has a quite a few "clever tricks" which minimizes size & 
enhances customability but makes it a bit tricky to follow for the 
uninitiated.


Basically, all reads & writes (owfs-side) goes through OW_r_std and 
OW_w_std, and have a type and subtype parameter. Ultimately they end 
up in moat_read(1) or moat_write (2) in the slave, which delegates 
(based on type param) to a specific read/write method.
The type parameter matches one of the "types" defined in the config 
file, such as adc/count etc, as defined in in ow_moat.h (3).

The subtype usually identifies a channel (i.e. port 1, port 2 and so on).

For reads, the master reads 1 byte of length data, followed by data + 
crc (and some special cases, see OW_r_std). It finishes with writing 
back an inverter CRC to acknowledge to the slave that the read went 
through properly.
For writes, the master writes size + data + crc, and reads back a 
confirmation CRC.

The actual data bytes depends on the different methods.

This should provide a good start to start digging. If unsure, I'd 
recommend running owfs with --debug --traffic to dump all bytes 
sent/received (recompile might be required, don't remember).
Besides that, you probably need to spend some time familiarizing 
yourself with the code, if your goal is to write an alternative master 
:) But once you get a hang of it, it's quite easy to follow.


Johan


1) https://github.com/M-o-a-T/owslave/blob/master/moat.c#L84
2) https://github.com/M-o-a-T/owslave/blob/master/moat.c#L142
3) 
https://github.com/M-o-a-T/owfs/blob/moat/module/owlib/src/include/ow_moat.h#L40


On 13/11/15 19:26, Colin Reese wrote:

Super.

So MOAT read and write are F2 and F4, respectively. Is there yet any 
documentation on what these will return by default, what additional 
data are required to specify what to read and write, and how to 
specify such details in the config file? I apologize if this is clear 
from the code; it isn't to me.


I run the xF2 here with my LV library and do not receive a response.

Is uart debug as simple as enabling it and then inserting uart_putc() 
and uart_puts() statements where I see fit?


C

On 11/13/2015 12:05 AM, Johan Ström wrote:

Ah, using the latest code is always a good start.. :)

Yes, the 'moat' device uses custom ROM commands. To communicate with 
the moat from any other non-owfs master you'd need to implement the 
custom ROM commands there.
See 
https://github.com/M-o-a-T/owfs/blob/moat/module/owlib/src/c/ow_moat.c 
for details.



And to get back where this thread started, this is the actual code 
which this thread revolves around, adding support for those special 
ROM commands to the official owfs branch.



On 13/11/15 06:53, Colin Reese wrote:
First, I just noticed the HOWTO is much improved and has some 
details about using the uart. Thanks Matthias.


I assume all of the data appears somewhat transparently via owfs as 
indicated in the HOWTO, which is how I plan to use it typically. 
Using other code, e.g. through LabVIEW or otherwise, how would one 
read this data? Is there a modified command set?


Thanks,
C

On 11/12/2015 9:06 PM, Colin Reese wrote:

Understood.

From what I can see, 1Wire should be on INT0 (D2) per 152 in 
world.cfg. With the world.cfg below, everything compiles fine and 
loads from my USBTiny. I verified my fuses are xFF, xDE, x05, 
which looks good. I still don't see anything on my DS9490R.


One more thing -- anybody know what I need to do to select and 
enable the debug UART? I can see that the default baudrate is 
38400; I just need to select a port, pin and enable it. I can't 
quite see what needs to be defined to do it.


C

_include: world.cfg
devices:
  _default:
_ref: defaults.target.m88
types:
  _ref: defaults.types
code: []
  m328test:
_ref: mcu.mega328
defs:
  

Re: [Owfs-developers] Merging "moat" device specific code

[Colin Reese]

Super.

So MOAT read and write are F2 and F4, respectively. Is there yet any 
documentation on what these will return by default, what additional data 
are required to specify what to read and write, and how to specify such 
details in the config file? I apologize if this is clear from the code; 
it isn't to me.


I run the xF2 here with my LV library and do not receive a response.

Is uart debug as simple as enabling it and then inserting uart_putc() 
and uart_puts() statements where I see fit?


C

On 11/13/2015 12:05 AM, Johan Ström wrote:

Ah, using the latest code is always a good start.. :)

Yes, the 'moat' device uses custom ROM commands. To communicate with 
the moat from any other non-owfs master you'd need to implement the 
custom ROM commands there.
See 
https://github.com/M-o-a-T/owfs/blob/moat/module/owlib/src/c/ow_moat.c 
for details.



And to get back where this thread started, this is the actual code 
which this thread revolves around, adding support for those special 
ROM commands to the official owfs branch.



On 13/11/15 06:53, Colin Reese wrote:
First, I just noticed the HOWTO is much improved and has some details 
about using the uart. Thanks Matthias.


I assume all of the data appears somewhat transparently via owfs as 
indicated in the HOWTO, which is how I plan to use it typically. 
Using other code, e.g. through LabVIEW or otherwise, how would one 
read this data? Is there a modified command set?


Thanks,
C

On 11/12/2015 9:06 PM, Colin Reese wrote:

Understood.

From what I can see, 1Wire should be on INT0 (D2) per 152 in 
world.cfg. With the world.cfg below, everything compiles fine and 
loads from my USBTiny. I verified my fuses are xFF, xDE, x05, which 
looks good. I still don't see anything on my DS9490R.


One more thing -- anybody know what I need to do to select and 
enable the debug UART? I can see that the default baudrate is 38400; 
I just need to select a port, pin and enable it. I can't quite see 
what needs to be defined to do it.


C

_include: world.cfg
devices:
  _default:
_ref: defaults.target.m88
types:
  _ref: defaults.types
code: []
  m328test:
_ref: mcu.mega328
defs:
  f_cpu: 1600
port:
  1: B0~
  2: B1~
onewire_id: x0f361b8bff8a


On 11/12/2015 12:28 PM, Johan Ström wrote:
You'd have to step through the "_ref" in your def, and the 
"default" section in world.cfg to found out any defaults.


In my example, I only have specifically 'ref: mcu.mega328'. 
Checking the mcu.mega328 section in world.cfg (included) we do not 
have a f_cpu def.
So continue to global 'defaults' section, check defs. no f_cpu 
there either.
So for this target, there is no "default". In my example, it was 
explicitly set to 8Mhz though.


If we would instead use 'ref: defaults.target.m88' we would find 
_ref 'defaults.target.m8x_base' which contains the f_cpu def.


The reason it is not in code is that world.cfg controls all 
dynamic/configurable properties. During build, it will write a 
device/$TARGET/dev_config.h which is then included in the actual code.




On 12/11/15 18:17, Colin Reese wrote:
I understand, but if not already defined, what is the default 
value? Or, why is this not defined in the code already?


On Thu, Nov 12, 2015 at 9:13 AM, Johan Ström <jo...@stromnet.se> 
wrote:


Yes, the f_cpu define only controls timing calculations, which
must match the clock speed. If incorrectly configured, it
won't be able to talk on the 1wire net.


On 12/11/15 18:04, Colin Reese wrote:

I see this in main:

#elif defined (__AVR_ATmega168__) || defined
(__AVR_ATmega88__) || defined(__AVR_ATmega328__)



// Clock is set via fuse

is the f_cpu definition necessary here?

C

On Thu, Nov 12, 2015 at 8:44 AM, Johan Ström
<jo...@stromnet.se> wrote:

As long as your built it for 16MHz it should probably be
compatible (I'm
not familiar with any specific fuses the m328 might have).

Thus, f_cpu: 1600

On 12/11/15 03:39, Colin Reese wrote:
> So to avoid trying to get WinAVR to behave, on a
windows machine with
> avrdude I would do something like:
>
> avrdude -c usbtiny -p m328p -U flash:w:image.hex -U
eeprom:w:eprom.hex
>
> That should do the trick? Do I really need to set the
fuses? I have it
> set up as external 16Mhz. I assume this is compatible.
>
> C
>
> On 11/11/2015 12:34 PM, Matthias Urlichs wrote:
>> On 11.11.2015 20:45, Colin Reese wrote:
>>> In the meantime, getting an updated libc from
elsewhere than the apt repos is an option?
>> I'd be wary of compiler/libc or libc/header
incompatibilities when
>> upgrading partially. IMHO it'd be safer to examine
your existing
   

Re: [Owfs-developers] Merging "moat" device specific code

[Colin Reese]

Great. So last question:

Where did the information below come from regarding 04 and 01 bytes? 
I'll gladly dig through that part!


I am good to go with git (https://github.com/iinnovations)

I'll give the owfs a build and throw it on a machine and see what I see.

Thanks for the help!
C

On 11/13/2015 11:50 AM, Johan Ström wrote:
Just sending F2 does not work, no. You need to send F2, then two more 
bytes identifying what you want to read For example, sending F2, 04, 
01 and then two read  timeslots would give you the return value 01 0x 
where the last x indicates the value of port 1. (Unless I got 
something wrong here.. but something like that).


If you do not want to spend time diving down into the code, I suggest 
you just build the moat-enabled owfs, by checking out the code and 
build it.

If you are unfamiliar with git & manual building, here's a short intro:

git clone https://github.com/M-o-a-T/owfs.git
cd owfs
git checkout moat

then regular ./configure ...  make .. make install (if desired, beware 
that make install may interfere your packaged version). I usally just 
run owserver after 'make' using ./modules/owserver/src/c/owserver 
--debug --foreground ..etc.. instead of doing install.


Hopefully we can get some positive votes on merging this to mainline, 
and the above won't be necessary :)


Johan

On 13/11/15 20:35, Colin Reese wrote:

Thanks Johan,

My goal isn't to write an alternate master -- I just want to use the 
Atmega328 as a 1Wire slave, reading the ports (and preferably 
configuring them). My understanding is that most of this legwork is 
done, but that the support isn't merged into owfs just yet.


In the meantime, I was just trying to test out the slave devices 
using my DS9490R and some LabVIEW code I use all the time with the 
typical read/write commands. For a read scratchpad, I send in 
whatever byte is necessary to initiate the command, e.g. xBE for a 
DS18B20, along with a data buffer that is returned with the data. I 
was hoping I could insert the xF2 read byte and get data back, but I 
don't. I successfully find the ROM on the bus, and get successful 
returns from TMAccess and TMRom, but no data on TMBlockstream. My 
main question was whether the default configuration I (and you) used 
for compilation will return data when sent xF2, and if not, how that 
is configured. I will surely do some poking, but it will be uphill.


C

On 11/13/2015 11:05 AM, Johan Ström wrote:
Not sure if there is any good docs on this yet, don't think so, and 
the code has a quite a few "clever tricks" which minimizes size & 
enhances customability but makes it a bit tricky to follow for the 
uninitiated.


Basically, all reads & writes (owfs-side) goes through OW_r_std and 
OW_w_std, and have a type and subtype parameter. Ultimately they end 
up in moat_read(1) or moat_write (2) in the slave, which delegates 
(based on type param) to a specific read/write method.
The type parameter matches one of the "types" defined in the config 
file, such as adc/count etc, as defined in in ow_moat.h (3).
The subtype usually identifies a channel (i.e. port 1, port 2 and so 
on).


For reads, the master reads 1 byte of length data, followed by data 
+ crc (and some special cases, see OW_r_std). It finishes with 
writing back an inverter CRC to acknowledge to the slave that the 
read went through properly.
For writes, the master writes size + data + crc, and reads back a 
confirmation CRC.

The actual data bytes depends on the different methods.

This should provide a good start to start digging. If unsure, I'd 
recommend running owfs with --debug --traffic to dump all bytes 
sent/received (recompile might be required, don't remember).
Besides that, you probably need to spend some time familiarizing 
yourself with the code, if your goal is to write an alternative 
master :) But once you get a hang of it, it's quite easy to follow.


Johan


1) https://github.com/M-o-a-T/owslave/blob/master/moat.c#L84
2) https://github.com/M-o-a-T/owslave/blob/master/moat.c#L142
3) 
https://github.com/M-o-a-T/owfs/blob/moat/module/owlib/src/include/ow_moat.h#L40


On 13/11/15 19:26, Colin Reese wrote:

Super.

So MOAT read and write are F2 and F4, respectively. Is there yet 
any documentation on what these will return by default, what 
additional data are required to specify what to read and write, and 
how to specify such details in the config file? I apologize if this 
is clear from the code; it isn't to me.


I run the xF2 here with my LV library and do not receive a response.

Is uart debug as simple as enabling it and then inserting 
uart_putc() and uart_puts() statements where I see fit?


C

On 11/13/2015 12:05 AM, Johan Ström wrote:

Ah, using the latest code is always a good start.. :)

Yes, the 'moat' device uses custom ROM commands. To communicate 
with the moat from any other non-owfs master you'd need to 
implement the custom ROM commands there.
See 
https://github.com/M-o-a-T/o

Re: [Owfs-developers] Merging "moat" device specific code

[Colin Reese]

Finally got it. Built it on a machine without the updated code. Thanks.

C

On 11/12/2015 9:06 PM, Colin Reese wrote:

Understood.

From what I can see, 1Wire should be on INT0 (D2) per 152 in 
world.cfg. With the world.cfg below, everything compiles fine and 
loads from my USBTiny. I verified my fuses are xFF, xDE, x05, which 
looks good. I still don't see anything on my DS9490R.


One more thing -- anybody know what I need to do to select and enable 
the debug UART? I can see that the default baudrate is 38400; I just 
need to select a port, pin and enable it. I can't quite see what needs 
to be defined to do it.


C

_include: world.cfg
devices:
  _default:
_ref: defaults.target.m88
types:
  _ref: defaults.types
code: []
  m328test:
_ref: mcu.mega328
defs:
  f_cpu: 1600
port:
  1: B0~
  2: B1~
onewire_id: x0f361b8bff8a


On 11/12/2015 12:28 PM, Johan Ström wrote:
You'd have to step through the "_ref" in your def, and the "default" 
section in world.cfg to found out any defaults.


In my example, I only have specifically 'ref: mcu.mega328'. Checking 
the mcu.mega328 section in world.cfg (included) we do not have a 
f_cpu def.
So continue to global 'defaults' section, check defs. no f_cpu there 
either.
So for this target, there is no "default". In my example, it was 
explicitly set to 8Mhz though.


If we would instead use 'ref: defaults.target.m88' we would find _ref 
'defaults.target.m8x_base' which contains the f_cpu def.


The reason it is not in code is that world.cfg controls all 
dynamic/configurable properties. During build, it will write a 
device/$TARGET/dev_config.h which is then included in the actual code.




On 12/11/15 18:17, Colin Reese wrote:
I understand, but if not already defined, what is the default value? 
Or, why is this not defined in the code already?


On Thu, Nov 12, 2015 at 9:13 AM, Johan Ström <jo...@stromnet.se 
<mailto:jo...@stromnet.se>> wrote:


Yes, the f_cpu define only controls timing calculations, which
must match the clock speed. If incorrectly configured, it won't
be able to talk on the 1wire net.


On 12/11/15 18:04, Colin Reese wrote:

I see this in main:

#elif defined (__AVR_ATmega168__) || defined (__AVR_ATmega88__)
|| defined(__AVR_ATmega328__)



// Clock is set via fuse

is the f_cpu definition necessary here?

C

On Thu, Nov 12, 2015 at 8:44 AM, Johan Ström
<jo...@stromnet.se> wrote:

As long as your built it for 16MHz it should probably be
compatible (I'm
not familiar with any specific fuses the m328 might have).

Thus, f_cpu: 1600

On 12/11/15 03:39, Colin Reese wrote:
> So to avoid trying to get WinAVR to behave, on a windows
machine with
> avrdude I would do something like:
>
> avrdude -c usbtiny -p m328p -U flash:w:image.hex -U
eeprom:w:eprom.hex
>
> That should do the trick? Do I really need to set the
fuses? I have it
> set up as external 16Mhz. I assume this is compatible.
>
> C
>
> On 11/11/2015 12:34 PM, Matthias Urlichs wrote:
>> On 11.11.2015 20:45, Colin Reese wrote:
>>> In the meantime, getting an updated libc from elsewhere
than the apt repos is an option?
>> I'd be wary of compiler/libc or libc/header
incompatibilities when
>> upgrading partially. IMHO it'd be safer to examine your
existing
>> pgmspace.h and add a patch to MoaT that works around not
having the
>> current version of pgmspace.h. (I already tried that,
but apparently not
>> quite successfully.)
>>
>> In fact you might just email your version to me, I can
certainly take a
>> look.
>>
>>
>> -- Matthias Urlichs
>>
>>
>>

--
>> ___
>> Owfs-developers mailing list
>> Owfs-developers@lists.sourceforge.net
<mailto:Owfs-developers@lists.sourceforge.net>
>> https://lists.sourceforge.net/lists/listinfo/owfs-developers
>
>

--
> ___
> Owfs-developers mailing list
> Owfs-developers@lists.sourceforge.net
<mailto:Owfs-developers@lists.sourceforge.net>
> https://lists.sourceforge.net/lists/listinfo/owfs-developers

Re: [Owfs-developers] Merging "moat" device specific code

[Colin Reese]

First, I just noticed the HOWTO is much improved and has some details 
about using the uart. Thanks Matthias.


I assume all of the data appears somewhat transparently via owfs as 
indicated in the HOWTO, which is how I plan to use it typically. Using 
other code, e.g. through LabVIEW or otherwise, how would one read this 
data? Is there a modified command set?


Thanks,
C

On 11/12/2015 9:06 PM, Colin Reese wrote:

Understood.

From what I can see, 1Wire should be on INT0 (D2) per 152 in 
world.cfg. With the world.cfg below, everything compiles fine and 
loads from my USBTiny. I verified my fuses are xFF, xDE, x05, which 
looks good. I still don't see anything on my DS9490R.


One more thing -- anybody know what I need to do to select and enable 
the debug UART? I can see that the default baudrate is 38400; I just 
need to select a port, pin and enable it. I can't quite see what needs 
to be defined to do it.


C

_include: world.cfg
devices:
  _default:
_ref: defaults.target.m88
types:
  _ref: defaults.types
code: []
  m328test:
_ref: mcu.mega328
defs:
  f_cpu: 1600
port:
  1: B0~
  2: B1~
onewire_id: x0f361b8bff8a


On 11/12/2015 12:28 PM, Johan Ström wrote:
You'd have to step through the "_ref" in your def, and the "default" 
section in world.cfg to found out any defaults.


In my example, I only have specifically 'ref: mcu.mega328'. Checking 
the mcu.mega328 section in world.cfg (included) we do not have a 
f_cpu def.
So continue to global 'defaults' section, check defs. no f_cpu there 
either.
So for this target, there is no "default". In my example, it was 
explicitly set to 8Mhz though.


If we would instead use 'ref: defaults.target.m88' we would find _ref 
'defaults.target.m8x_base' which contains the f_cpu def.


The reason it is not in code is that world.cfg controls all 
dynamic/configurable properties. During build, it will write a 
device/$TARGET/dev_config.h which is then included in the actual code.




On 12/11/15 18:17, Colin Reese wrote:
I understand, but if not already defined, what is the default value? 
Or, why is this not defined in the code already?


On Thu, Nov 12, 2015 at 9:13 AM, Johan Ström <jo...@stromnet.se 
<mailto:jo...@stromnet.se>> wrote:


Yes, the f_cpu define only controls timing calculations, which
must match the clock speed. If incorrectly configured, it won't
be able to talk on the 1wire net.


On 12/11/15 18:04, Colin Reese wrote:

I see this in main:

#elif defined (__AVR_ATmega168__) || defined (__AVR_ATmega88__)
|| defined(__AVR_ATmega328__)



// Clock is set via fuse

is the f_cpu definition necessary here?

C

On Thu, Nov 12, 2015 at 8:44 AM, Johan Ström
<jo...@stromnet.se> wrote:

As long as your built it for 16MHz it should probably be
compatible (I'm
not familiar with any specific fuses the m328 might have).

Thus, f_cpu: 1600

On 12/11/15 03:39, Colin Reese wrote:
> So to avoid trying to get WinAVR to behave, on a windows
machine with
> avrdude I would do something like:
>
> avrdude -c usbtiny -p m328p -U flash:w:image.hex -U
eeprom:w:eprom.hex
>
> That should do the trick? Do I really need to set the
fuses? I have it
> set up as external 16Mhz. I assume this is compatible.
>
> C
>
> On 11/11/2015 12:34 PM, Matthias Urlichs wrote:
>> On 11.11.2015 20:45, Colin Reese wrote:
>>> In the meantime, getting an updated libc from elsewhere
than the apt repos is an option?
>> I'd be wary of compiler/libc or libc/header
incompatibilities when
>> upgrading partially. IMHO it'd be safer to examine your
existing
>> pgmspace.h and add a patch to MoaT that works around not
having the
>> current version of pgmspace.h. (I already tried that,
but apparently not
>> quite successfully.)
>>
>> In fact you might just email your version to me, I can
certainly take a
>> look.
>>
>>
>> -- Matthias Urlichs
>>
>>
>>

--
>> ___
>> Owfs-developers mailing list
>> Owfs-developers@lists.sourceforge.net
<mailto:Owfs-developers@lists.sourceforge.net>
>> https://lists.sourceforge.net/lists/listinfo/owfs-developers
>
>

--
> _

Re: [Owfs-developers] Merging "moat" device specific code

[Colin Reese]

Understood.

From what I can see, 1Wire should be on INT0 (D2) per 152 in world.cfg. 
With the world.cfg below, everything compiles fine and loads from my 
USBTiny. I verified my fuses are xFF, xDE, x05, which looks good. I 
still don't see anything on my DS9490R.


One more thing -- anybody know what I need to do to select and enable 
the debug UART? I can see that the default baudrate is 38400; I just 
need to select a port, pin and enable it. I can't quite see what needs 
to be defined to do it.


C

_include: world.cfg
devices:
  _default:
_ref: defaults.target.m88
types:
  _ref: defaults.types
code: []
  m328test:
_ref: mcu.mega328
defs:
  f_cpu: 1600
port:
  1: B0~
  2: B1~
onewire_id: x0f361b8bff8a


On 11/12/2015 12:28 PM, Johan Ström wrote:
You'd have to step through the "_ref" in your def, and the "default" 
section in world.cfg to found out any defaults.


In my example, I only have specifically 'ref: mcu.mega328'. Checking 
the mcu.mega328 section in world.cfg (included) we do not have a f_cpu 
def.
So continue to global 'defaults' section, check defs. no f_cpu there 
either.
So for this target, there is no "default". In my example, it was 
explicitly set to 8Mhz though.


If we would instead use 'ref: defaults.target.m88' we would find _ref 
'defaults.target.m8x_base' which contains the f_cpu def.


The reason it is not in code is that world.cfg controls all 
dynamic/configurable properties. During build, it will write a 
device/$TARGET/dev_config.h which is then included in the actual code.




On 12/11/15 18:17, Colin Reese wrote:
I understand, but if not already defined, what is the default value? 
Or, why is this not defined in the code already?


On Thu, Nov 12, 2015 at 9:13 AM, Johan Ström <jo...@stromnet.se 
<mailto:jo...@stromnet.se>> wrote:


Yes, the f_cpu define only controls timing calculations, which
must match the clock speed. If incorrectly configured, it won't
be able to talk on the 1wire net.


On 12/11/15 18:04, Colin Reese wrote:

I see this in main:

#elif defined (__AVR_ATmega168__) || defined (__AVR_ATmega88__)
|| defined(__AVR_ATmega328__)



// Clock is set via fuse

is the f_cpu definition necessary here?

C

On Thu, Nov 12, 2015 at 8:44 AM, Johan Ström <jo...@stromnet.se>
wrote:

As long as your built it for 16MHz it should probably be
compatible (I'm
not familiar with any specific fuses the m328 might have).

Thus, f_cpu: 1600

On 12/11/15 03:39, Colin Reese wrote:
> So to avoid trying to get WinAVR to behave, on a windows
machine with
> avrdude I would do something like:
>
> avrdude -c usbtiny -p m328p -U flash:w:image.hex -U
eeprom:w:eprom.hex
>
> That should do the trick? Do I really need to set the
fuses? I have it
> set up as external 16Mhz. I assume this is compatible.
>
> C
>
> On 11/11/2015 12:34 PM, Matthias Urlichs wrote:
>> On 11.11.2015 20:45, Colin Reese wrote:
>>> In the meantime, getting an updated libc from elsewhere
than the apt repos is an option?
>> I'd be wary of compiler/libc or libc/header
incompatibilities when
>> upgrading partially. IMHO it'd be safer to examine your
existing
>> pgmspace.h and add a patch to MoaT that works around not
having the
>> current version of pgmspace.h. (I already tried that, but
apparently not
>> quite successfully.)
>>
>> In fact you might just email your version to me, I can
certainly take a
>> look.
>>
>>
>> -- Matthias Urlichs
>>
>>
>>

--
>> ___
>> Owfs-developers mailing list
>> Owfs-developers@lists.sourceforge.net
<mailto:Owfs-developers@lists.sourceforge.net>
>> https://lists.sourceforge.net/lists/listinfo/owfs-developers
>
>

--
> ___
> Owfs-developers mailing list
> Owfs-developers@lists.sourceforge.net
<mailto:Owfs-developers@lists.sourceforge.net>
> https://lists.sourceforge.net/lists/listinfo/owfs-developers



--

Re: [Owfs-developers] Merging "moat" device specific code

[Colin Reese]

I understand, but if not already defined, what is the default value? Or,
why is this not defined in the code already?

On Thu, Nov 12, 2015 at 9:13 AM, Johan Ström <jo...@stromnet.se> wrote:

> Yes, the f_cpu define only controls timing calculations, which must match
> the clock speed. If incorrectly configured, it won't be able to talk on the
> 1wire net.
>
>
> On 12/11/15 18:04, Colin Reese wrote:
>
> I see this in main:
>
> #elif defined (__AVR_ATmega168__) || defined (__AVR_ATmega88__) ||
> defined(__AVR_ATmega328__)
> // Clock is set via fuse
>
> is the f_cpu definition necessary here?
>
> C
>
> On Thu, Nov 12, 2015 at 8:44 AM, Johan Ström <jo...@stromnet.se> wrote:
>
>> As long as your built it for 16MHz it should probably be compatible (I'm
>> not familiar with any specific fuses the m328 might have).
>>
>> Thus, f_cpu: 1600
>>
>> On 12/11/15 03:39, Colin Reese wrote:
>> > So to avoid trying to get WinAVR to behave, on a windows machine with
>> > avrdude I would do something like:
>> >
>> > avrdude -c usbtiny -p m328p -U flash:w:image.hex -U eeprom:w:eprom.hex
>> >
>> > That should do the trick? Do I really need to set the fuses? I have it
>> > set up as external 16Mhz. I assume this is compatible.
>> >
>> > C
>> >
>> > On 11/11/2015 12:34 PM, Matthias Urlichs wrote:
>> >> On 11.11.2015 20:45, Colin Reese wrote:
>> >>> In the meantime, getting an updated libc from elsewhere than the apt
>> repos is an option?
>> >> I'd be wary of compiler/libc or libc/header incompatibilities when
>> >> upgrading partially. IMHO it'd be safer to examine your existing
>> >> pgmspace.h and add a patch to MoaT that works around not having the
>> >> current version of pgmspace.h. (I already tried that, but apparently
>> not
>> >> quite successfully.)
>> >>
>> >> In fact you might just email your version to me, I can certainly take a
>> >> look.
>> >>
>> >>
>> >> -- Matthias Urlichs
>> >>
>> >>
>> >>
>> --
>> >> ___
>> >> Owfs-developers mailing list
>> >> Owfs-developers@lists.sourceforge.net
>> >> https://lists.sourceforge.net/lists/listinfo/owfs-developers
>> >
>> >
>> --
>> > ___
>> > Owfs-developers mailing list
>> > Owfs-developers@lists.sourceforge.net
>> > https://lists.sourceforge.net/lists/listinfo/owfs-developers
>>
>>
>>
>> --
>> ___
>> Owfs-developers mailing list
>> Owfs-developers@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/owfs-developers
>>
>
>
>
> --
>
>
>
> ___
> Owfs-developers mailing 
> listOwfs-developers@lists.sourceforge.nethttps://lists.sourceforge.net/lists/listinfo/owfs-developers
>
>
>
>
> --
>
> ___
> Owfs-developers mailing list
> Owfs-developers@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/owfs-developers
>
>
--
___
Owfs-developers mailing list
Owfs-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/owfs-developers

Re: [Owfs-developers] Merging "moat" device specific code

[Colin Reese]

I see this in main:

#elif defined (__AVR_ATmega168__) || defined (__AVR_ATmega88__) ||
defined(__AVR_ATmega328__)// Clock is set via fuse

is the f_cpu definition necessary here?

C

On Thu, Nov 12, 2015 at 8:44 AM, Johan Ström <jo...@stromnet.se> wrote:

> As long as your built it for 16MHz it should probably be compatible (I'm
> not familiar with any specific fuses the m328 might have).
>
> Thus, f_cpu: 1600
>
> On 12/11/15 03:39, Colin Reese wrote:
> > So to avoid trying to get WinAVR to behave, on a windows machine with
> > avrdude I would do something like:
> >
> > avrdude -c usbtiny -p m328p -U flash:w:image.hex -U eeprom:w:eprom.hex
> >
> > That should do the trick? Do I really need to set the fuses? I have it
> > set up as external 16Mhz. I assume this is compatible.
> >
> > C
> >
> > On 11/11/2015 12:34 PM, Matthias Urlichs wrote:
> >> On 11.11.2015 20:45, Colin Reese wrote:
> >>> In the meantime, getting an updated libc from elsewhere than the apt
> repos is an option?
> >> I'd be wary of compiler/libc or libc/header incompatibilities when
> >> upgrading partially. IMHO it'd be safer to examine your existing
> >> pgmspace.h and add a patch to MoaT that works around not having the
> >> current version of pgmspace.h. (I already tried that, but apparently not
> >> quite successfully.)
> >>
> >> In fact you might just email your version to me, I can certainly take a
> >> look.
> >>
> >>
> >> -- Matthias Urlichs
> >>
> >>
> >>
> --
> >> ___
> >> Owfs-developers mailing list
> >> Owfs-developers@lists.sourceforge.net
> >> https://lists.sourceforge.net/lists/listinfo/owfs-developers
> >
> >
> --
> > ___
> > Owfs-developers mailing list
> > Owfs-developers@lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/owfs-developers
>
>
>
> --
> ___
> Owfs-developers mailing list
> Owfs-developers@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/owfs-developers
>
--
___
Owfs-developers mailing list
Owfs-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/owfs-developers

Re: [Owfs-developers] Merging "moat" device specific code

[Colin Reese]

I have tried on deb Linux (Ubuntu 14.04) with apt distros, also winavr. Just 
downloaded owslave and tried fresh with the exact cfg you listed. 

C

> On Nov 11, 2015, at 1:57 AM, Johan Ström <jo...@stromnet.se> wrote:
> 
> Hm, first this was commited:
> https://github.com/M-o-a-T/owslave/commit/960a7decb26ee1aa792ef41400c306ec563e77ab
> 
> but then this:
> https://github.com/M-o-a-T/owslave/commit/e573863d5a62072945dd6c07eb4e6109a6108c16
> 
> Are you perhaps using either old revision of the owslave code, or
> perhaps old AVR-libc headers?
> 
> Johan
> 
>> On 11/11/15 09:09, Colin Reese wrote:
>> I get a number of errors on compile similar to:
>> 
>> /moat.c:182: undefined reference to `pgm_read_ptr_near'
>> 
>> C
>> 
>>> On 11/10/2015 1:07 PM, Johan Ström wrote:
>>> _include: world.cfg
>>> devices:
>>>_default:
>>>  _ref: defaults.target.m88
>>>  types:
>>>_ref: defaults.types
>>>  code: []
>>>m328test:
>>>  _ref: mcu.mega328
>>>  defs:
>>>f_cpu: 800
>>>  port:
>>>1: B0~
>>>2: B1~
>> 
>> --
>> ___
>> Owfs-developers mailing list
>> Owfs-developers@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/owfs-developers
> 
> 
> --
> ___
> Owfs-developers mailing list
> Owfs-developers@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/owfs-developers

--
___
Owfs-developers mailing list
Owfs-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/owfs-developers

Re: [Owfs-developers] Merging "moat" device specific code

[Colin Reese]

The header files seem to be installed to primarily:

/usr/lib/avr/include/avr

Cat/grep on all in the directory yields nothing for pgm_read_ptr, and a 
number of functions, e.g. pgm_read_byte, pgm_read_word, float, etc., 
which are all present in pgmspace.h

I included the code provided by Matthias for pgm_read_ptr_near in the 
pgmspace.h, and also added the code below to a pgm.h file that now 
consists of:

#include 
#define pgm_read_ptr(address_short) pgm_read_ptr_near(address_short)

It now compiles.

I assume the code Matthias posted could be added to the pgm.h with some 
thoughtful IFNDEFs to make this complete.

C

On 11/11/2015 4:42 AM, Johan Ström wrote:
> It would help if you can post specific version numbers of avr-libc (or
> whatever it is named in Ubuntu), and winavr.
> Also try to search for pgm_read_ptr_near and/or pgm_read* in the include
> files which your avr-libc package installs (check with your package
> manager how to list installed files).
>
> On 11/11/15 11:04, Colin Reese wrote:
>> I have tried on deb Linux (Ubuntu 14.04) with apt distros, also winavr. Just 
>> downloaded owslave and tried fresh with the exact cfg you listed.
>>
>> C
>>
>>> On Nov 11, 2015, at 1:57 AM, Johan Ström <jo...@stromnet.se> wrote:
>>>
>>> Hm, first this was commited:
>>> https://github.com/M-o-a-T/owslave/commit/960a7decb26ee1aa792ef41400c306ec563e77ab
>>>
>>> but then this:
>>> https://github.com/M-o-a-T/owslave/commit/e573863d5a62072945dd6c07eb4e6109a6108c16
>>>
>>> Are you perhaps using either old revision of the owslave code, or
>>> perhaps old AVR-libc headers?
>>>
>>> Johan
>>>
>>>> On 11/11/15 09:09, Colin Reese wrote:
>>>> I get a number of errors on compile similar to:
>>>>
>>>> /moat.c:182: undefined reference to `pgm_read_ptr_near'
>>>>
>>>> C
>>>>
>>>>> On 11/10/2015 1:07 PM, Johan Ström wrote:
>>>>> _include: world.cfg
>>>>> devices:
>>>>> _default:
>>>>>   _ref: defaults.target.m88
>>>>>   types:
>>>>> _ref: defaults.types
>>>>>   code: []
>>>>> m328test:
>>>>>   _ref: mcu.mega328
>>>>>   defs:
>>>>> f_cpu: 800
>>>>>   port:
>>>>> 1: B0~
>>>>> 2: B1~
>>>> --
>>>> ___
>>>> Owfs-developers mailing list
>>>> Owfs-developers@lists.sourceforge.net
>>>> https://lists.sourceforge.net/lists/listinfo/owfs-developers
>>> --
>>> ___
>>> Owfs-developers mailing list
>>> Owfs-developers@lists.sourceforge.net
>>> https://lists.sourceforge.net/lists/listinfo/owfs-developers
>> --
>> ___
>> Owfs-developers mailing list
>> Owfs-developers@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/owfs-developers
>
> --
> ___
> Owfs-developers mailing list
> Owfs-developers@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/owfs-developers


--
___
Owfs-developers mailing list
Owfs-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/owfs-developers

Re: [Owfs-developers] Merging "moat" device specific code

[Colin Reese]

So to avoid trying to get WinAVR to behave, on a windows machine with 
avrdude I would do something like:

avrdude -c usbtiny -p m328p -U flash:w:image.hex -U eeprom:w:eprom.hex

That should do the trick? Do I really need to set the fuses? I have it 
set up as external 16Mhz. I assume this is compatible.

C

On 11/11/2015 12:34 PM, Matthias Urlichs wrote:
> On 11.11.2015 20:45, Colin Reese wrote:
>> In the meantime, getting an updated libc from elsewhere than the apt repos 
>> is an option?
> I'd be wary of compiler/libc or libc/header incompatibilities when
> upgrading partially. IMHO it'd be safer to examine your existing
> pgmspace.h and add a patch to MoaT that works around not having the
> current version of pgmspace.h. (I already tried that, but apparently not
> quite successfully.)
>
> In fact you might just email your version to me, I can certainly take a
> look.
>
>
> -- Matthias Urlichs
>
>
> --
> ___
> Owfs-developers mailing list
> Owfs-developers@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/owfs-developers


--
___
Owfs-developers mailing list
Owfs-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/owfs-developers

Re: [Owfs-developers] Merging "moat" device specific code

[Colin Reese]

In the meantime, getting an updated libc from elsewhere than the apt repos is 
an option?

C

> On Nov 11, 2015, at 11:40 AM, Matthias Urlichs  wrote:
> 
>> On 11.11.2015 13:42, Johan Ström wrote:
>> Also try to search for pgm_read_ptr_near and/or pgm_read* in the include
>> files which your avr-libc package installs (check with your package
>> manager how to list installed files).
> 
> There seem to be some somewhat-incompatible and probably incompletely
> updated/patched AVR libc packages floating around, and Ubuntu LTR14
> appears to have caught one of them.
> 
> It's all in /usr/lib/avr/include/avr/pgmspace.h.
> 
> The complete code from that file, as far as pgm_read_ptr_near is
> concerned, is this:
> 
> #define __LPM_word_classic__(addr)  \
> (__extension__({\
>uint16_t __addr16 = (uint16_t)(addr);   \
>uint16_t __result;  \
>__asm__ __volatile__\
>(   \
>"lpm"   "\n\t"  \
>"mov %A0, r0"   "\n\t"  \
>"adiw r30, 1"   "\n\t"  \
>"lpm"   "\n\t"  \
>"mov %B0, r0"   "\n\t"  \
>: "=r" (__result), "=z" (__addr16)  \
>: "1" (__addr16)\
>: "r0"  \
>);  \
>__result;   \
> }))
> 
> #define __LPM_word_tiny__(addr) \
> (__extension__({\
>uint16_t __addr16 = (uint16_t)(addr) + __AVR_TINY_PM_BASE_ADDRESS__; \
>uint16_t __result;  \
>__asm__ \
>(   \
>"ld %A0, z+" "\n\t" \
>"ld %B0, z"  "\n\t" \
>: "=r" (__result), "=z" (__addr16)  \
>: "1" (__addr16)\
>);  \
>__result;   \
> }))
> 
> #define __LPM_word_enhanced__(addr) \
> (__extension__({\
>uint16_t __addr16 = (uint16_t)(addr);   \
>uint16_t __result;  \
>__asm__ __volatile__\
>(   \
>"lpm %A0, Z+"   "\n\t"  \
>"lpm %B0, Z""\n\t"  \
>: "=r" (__result), "=z" (__addr16)  \
>: "1" (__addr16)\
>);  \
>__result;   \
> }))
> 
> #if defined (__AVR_HAVE_LPMX__)
> #define __LPM_word(addr)__LPM_word_enhanced__(addr)
> #elif defined (__AVR_TINY__)
> #define __LPM_word(addr)__LPM_word_tiny__(addr)
> #else
> #define __LPM_word(addr)__LPM_word_classic__(addr)
> #endif
> 
> #define pgm_read_ptr_near(address_short) \
>(void*)__LPM_word((uint16_t)(address_short))
> 
> Thus if somebody could build a patch for MoaT that can work around
> whatever is missing from your avr libc (preferably without duplicating
> anything that _is_ there), please go ahead and submit a pull request.
> Thank you.
> 
> -- 
> -- Matthias Urlichs
> 
> 
> 
> --
> ___
> Owfs-developers mailing list
> Owfs-developers@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/owfs-developers

--
___
Owfs-developers mailing list
Owfs-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/owfs-developers

Re: [Owfs-developers] Merging "moat" device specific code

[Colin Reese]

I get a number of errors on compile similar to:

/moat.c:182: undefined reference to `pgm_read_ptr_near'

C

On 11/10/2015 1:07 PM, Johan Ström wrote:
> _include: world.cfg
> devices:
> _default:
>   _ref: defaults.target.m88
>   types:
> _ref: defaults.types
>   code: []
> m328test:
>   _ref: mcu.mega328
>   defs:
> f_cpu: 800
>   port:
> 1: B0~
> 2: B1~


--
___
Owfs-developers mailing list
Owfs-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/owfs-developers

Re: [Owfs-developers] Merging "moat" device specific code

[Colin Reese]

I will look again as I did not see this. I did not have success with the attiny 
moat. Using another owslave (by youen) I needed to run at 16mhz to get it 
working. Rather than rewrite to expose local IO (and other arbitrary values 
like serial), my end goal, I'd much rather get moat working. 

C

> On Nov 10, 2015, at 12:16 PM, Johan Ström <jo...@stromnet.se> wrote:
> 
> While I haven't tested it myself, there are specific code for mega328 
> (and 168, 88 and 8), besides tiny84/85 (which is marked "untested for 
> some time" though).
> I've only used it on the mega8 and mega88 so far, running at 8Mhz with 
> internal oscillator with great success.
> 
>> On 10/11/15 20:32, Colin Reese wrote:
>> Is this still only for attiny? I've been limping along with code for 
>> atmega328 from elsewhere and would love if someone has time to help me port 
>> it. I love the idea.
>> 
>>> On Nov 10, 2015, at 11:10 AM, Johan Ström <jo...@stromnet.se> wrote:
>>> 
>>> Hi,
>>> 
>>> a ticket was opened a few days ago regarding merging the "moat" device
>>> specific owfs code into master:
>>> 
>>> http://sourceforge.net/p/owfs/feature-requests/9/
>>> 
>>> Does anyone object that I merge this? I've run this code myself for
>>> months without any issues.
>>> The only reason I can come to think of is that it uses the family code
>>> 'F0' (re older discussion:
>>> http://sourceforge.net/p/owfs/mailman/message/33029728/).
>>> Paul's last comment regarding type/version fields is almost fulfilled;
>>> there is no version field, but the device advertises which different
>>> data types (adc, counter etc) it has support for.
>>> 
>>> I don't know about Matthias Urlichs' ideas regarding any
>>> commercialization, for me it is for private use. But as he (I assume it
>>> his him) mentions in the ticket, it apparently has a few users now.
>>> 
>>> As this is a well-working and pretty easy-to-use open-source variant of
>>> a custom owslave, I'd love to see "official" support for it!
>>> 
>>> Regards
>>> Johan
>>> 
>>> --
>>> ___
>>> Owfs-developers mailing list
>>> Owfs-developers@lists.sourceforge.net
>>> https://lists.sourceforge.net/lists/listinfo/owfs-developers
>> --
>> ___
>> Owfs-developers mailing list
>> Owfs-developers@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/owfs-developers
> 
> 
> --
> ___
> Owfs-developers mailing list
> Owfs-developers@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/owfs-developers

--
___
Owfs-developers mailing list
Owfs-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/owfs-developers

Re: [Owfs-developers] Merging "moat" device specific code

[Colin Reese]

Is this still only for attiny? I've been limping along with code for atmega328 
from elsewhere and would love if someone has time to help me port it. I love 
the idea. 

> On Nov 10, 2015, at 11:10 AM, Johan Ström  wrote:
> 
> Hi,
> 
> a ticket was opened a few days ago regarding merging the "moat" device 
> specific owfs code into master:
> 
> http://sourceforge.net/p/owfs/feature-requests/9/
> 
> Does anyone object that I merge this? I've run this code myself for 
> months without any issues.
> The only reason I can come to think of is that it uses the family code 
> 'F0' (re older discussion: 
> http://sourceforge.net/p/owfs/mailman/message/33029728/).
> Paul's last comment regarding type/version fields is almost fulfilled; 
> there is no version field, but the device advertises which different 
> data types (adc, counter etc) it has support for.
> 
> I don't know about Matthias Urlichs' ideas regarding any 
> commercialization, for me it is for private use. But as he (I assume it 
> his him) mentions in the ticket, it apparently has a few users now.
> 
> As this is a well-working and pretty easy-to-use open-source variant of 
> a custom owslave, I'd love to see "official" support for it!
> 
> Regards
> Johan
> 
> --
> ___
> Owfs-developers mailing list
> Owfs-developers@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/owfs-developers

--
___
Owfs-developers mailing list
Owfs-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/owfs-developers