Re: [Owfs-developers] Raspberry Pi busmaster GPIO connector
Am 02.04.24 um 06:16 schrieb Gregg Levine: Hello! I've a new project taking shape at the moment. And it involves making use of OWFS on the Raspberry Pi, a Pi Zero Wifi WH device in fact. And I recalled that when I enabled the GPIO settings such as the Serial port there, and typically the I2C settings, I would see but not enable the one for One-Wire. Now the question is one of which GPIO one that the system selected. The website makes a reference to someone's work, but does not provide references. The bitbanging onewire host works with GPIO4 (pin 7 on the 40-pin connector) by default on the Raspberry Pi. Use dtoverlay=w1-gpio in /boot/config.txt. You can also select a different GPIO with dtoverlay=w1-gpio,gpiopin=4 with 4 being the GPIO you want. (Note those are called "gpiopin" but it's not the pin numbers on the 40-pin connector but the GPIO numbers.) The additional option pullup=1 may be used to enable the high-side transistor of the GPIO for a strong pullup during some operations. Note that the Raspberry Pi is a 3.3V device, so that Onewire is going to be a 3.3V Onewire. You have to wire a 1.5kΩ resistor to +3.3V to make it work correctly. If you need a 5V Onewire instead, use a level shifter as this one: | |+5V . ,-+ +3.3V || | | |\ G | \ |/ –' / |\––– – –––\ || | ^ | | | 5V bus line ---+-' '--+-+ 3.3V bus line | D S | The transistor is a small signal N-channel enhancement mode MOSFET, e.g. a 2N7000, BS170 or MMBF170. The +5V pullup must be around 2.7kΩ. Kind regards Jan ___ Owfs-developers mailing list Owfs-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/owfs-developers
Re: [Owfs-developers] OWFS 3.2P4 will build on Raspberry Pi
Am 24.10.20 um 06:31 schrieb hansolofal...@att.net: > > Right now I'm working with Maxim to make arrangements to send a pair of > DS2484 devices, and then a pair of DS28E17 devices as well. (I might have > those.) > Be aware the DS28E17 is a 3.3V only device. It's not 5V tolerant. At first it appears to be but you will fry it instantly if a 5V onewire is connected while the power is disconnected. > We know from earlier discussions that the Pi will work to talk to a device > that uses the I2C methods. But what about those two? > The DS28E17 is only supported by the kernel driver. So you need to use it with one of the Onewire host adapters that is supported by the kernel. OWFS isn't involved but may be run in parallel with the --w1 option, or independently on other host adapters. Do not use both the ds2482 kernel driver and the --i2c option of OWFS on the same I²C Onewire hostadapter. This meant concurrent access on the DS2484 chip and leads to all kind of tricky malfunctions. Kind regards Jan ___ Owfs-developers mailing list Owfs-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/owfs-developers
Re: [Owfs-developers] Reading latesttemp
Am 08.10.20 um 15:07 schrieb Mick Sulley: > > But owwrite /simultaneous/temperature 1 should trigger a conversion? and > reading latesttemp should then be correct. Here is another. Latesttemp > returns 85 even after owwrite /simultaneous/temperature 1, but read > temperature12 and it works again. I don't understand why! > Most likely it's a problem with power. Do you power each chip separately, or do they all pull, from the same +5V line? > > I have a few more in this state at the moment, I am sure I could fix > them all with a single temperature12 read to each and they would then be > fine, but I would really like to understand what the problem is > You could try to find out if the simultaneous command is not going through to all chips (chips never read 85°C on latesttemp) or if you still get those spurious resets. But it's only a debugging tool. In a production setup, it would only ever mask the underlying problem and return a wrong ages-old temperature instead. Kind regards Jan ___ Owfs-developers mailing list Owfs-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/owfs-developers
Re: [Owfs-developers] Reading latesttemp
Am 08.10.20 um 00:31 schrieb Mick Sulley: > On my test system I have 20 DS18B20 temperature sensors (all powered) to > test out various things. I am setting /simultaneous/temperature waiting > 2 seconds then reading latesttemp from all of them. > > I have just noticed that several are giving 85 reads. If I look with > owhttpd this is what I see - > > owhttpd screen > > Also owread /uncached/DHW_Mid_Btm/latesttemp returns 85. This is after > many cycles of simultaneous/voltage and latesttemp reads. > Reading /uncached//latesttemp reads the contents of the temperature register from the chip. It never triggers a temperature conversion. If you read 85°C from latesttemp, it means the latest conversion either 85°C (unlikely) or the chip has been power-cycled since the latest conversion (likely). As 85°C is the power-on value of that register. > > It seems to me that it is a useful safeguard to run a single > temperature12 read on each sensor during the initialisation of the > system. I cannot see any downside to this but just thought I would ask > for your thoughts. > That doesn't make any sense as you will read back the value from that initial conversion again and again if your simultaneous trigger isn't working. You mask the error that way, which is likely not what you want. If a sensor reports a spurious 85°C, treat that as a power-cycle on that sensor – check your hardware! Kind regards Jan ___ Owfs-developers mailing list Owfs-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/owfs-developers
Re: [Owfs-developers] Release 3.2p4
Am 12.08.20 um 10:50 schrieb Stefano Miccoli via Owfs-developers: > > Having some spare time in may staycation, I’m drafting owfs release 3.2p4. > Thank you so much, Stefano. Kind regards Jan ___ Owfs-developers mailing list Owfs-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/owfs-developers
Re: [Owfs-developers] Simultaneous not working
Am 05.08.20 um 00:39 schrieb Mick Sulley:
> Running v3.2p3 on Raspberry Pi, I have set up some DS18B20 sensors on a
> test system, all of them are powered, but simultaneous does not seem to
> be working
>
Triggering /temperature/simultaneous just sends "Skip ROM, Convert T" on
the bus.
If you never ever read ...//temperature nodes, there's no waiting
time imposed by ofws. Reading /uncached//latesttemp reads the
current scratchpad from the sensor.
However, I'm not sure if the sensor itself imposes a waiting time for
reading the scratchpad while a conversion is active. In that case, owfs
would wait for it to respond.
>
> The code is below, when I run it the first loop takes 16 seconds then it
> loops at 3 seconds for a while, then a 16 second etc. so it looks like
> it does slow individual conversions, then uses cached values until they
> expire, then another slow individual conversion, etc. Have I got
> something wrong here?
>
> #!/usr/bin/python3
>
> # sensor_read.py
>
> import pyownet
> import time
>
> def main():
> owp = pyownet.protocol.proxy()
> while True:
> start = time.time()
> owp.write('/simultaneous/temperature', b'1')
> time.sleep(1)
> print('start of sensor_read.py')
> sen_lst = ['Solar_Pnl_1A', 'Solar_Pnl_2A','Solar_Pnl_1B',
> 'Pool_Sol_X', 'Pool_CH_X', 'DHW_Mid_Top', 'DHW_Mid_Btm',
> 'DHW_Top','Temp5', 'Temp19', 'Temp20','Temp21', 'Temp22', 'Temp23',
> 'Temp25', 'Temp26', 'Temp27', 'Temp29', 'Temp30']
> prop_lst = ['/type', '/power', '/latesttemp']
> for p in prop_lst:
> print('%s ' %p, end = '')
> print('')
> for sen in sen_lst:
> print('\n%s ' %sen, end = '')
> for prop in prop_lst:
> try:
> print('%s ' %(owp.read('/uncached/' + sen +
> prop).decode()), end = '')
> except:
> print('failed! ',end = '')
> endt = time.time() - start
> print('\nTime = %f' %endt)
>
> if __name__ == "__main__":
> main()
>
>
I'm not too familiar with Python but this looks straightforward and okay.
From what you write it seems there's another process accessing the
sensors concurrently. Maybe a kernel driver? Check that first.
Kind regards
Jan
___
Owfs-developers mailing list
Owfs-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/owfs-developers
Re: [Owfs-developers] Bugfixed release not the one for download?
Am 23.06.20 um 00:15 schrieb Gregg Levine: > Hello! > Okay group, I'll defer to all of you on this. Something else, do any > of you know who does the packaging for Debian? > Vincent Danjean You can find out such things on the official Debian packages documentation: https://packages.debian.org/en/sid/owfs Kind regards Jan ___ Owfs-developers mailing list Owfs-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/owfs-developers
Re: [Owfs-developers] Bugfixed release not the one for download?
Am 22.06.20 um 18:27 schrieb Gregg Levine: > > I decided to check to see if the project page for OWFS had anything > new, that is newer than the OWFS-3.2P2 one that I'm busy building. > The release device from the page wanted to send me the previous > release. Since I'm still down as an admin I decided to see if I could > change things to reflect that version. I decided against it because I > did not want to break any of the pages on the site. > Last release was October 2018, so yes, we should have a new version. I do some test compiles at the moment and found warnings and bugs. Kind regards Jan ___ Owfs-developers mailing list Owfs-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/owfs-developers
Re: [Owfs-developers] Caching for I/O modules
Am 09.05.20 um 14:42 schrieb Mick Sulley: > I understand how caching works for temperature sensors, use of > simultaneous etc, but how do I/O modules work in that respect? > > I am particularly interested in DS2413. Is there any difference between > "owwrite /TestIO/PIO.A 1" and "owwrite /uncached/TestIO/PIO.A 1", > They both write to the chip. No difference. > similarly with reading, is it safer to use "owread > /uncached/TestIO/PIO.A" rather than "owread /TestIO/PIO.A" > Only reading /uncached will give you the current value the chip read each time. The cached one may be seconds old, depending on when you read it from the chip last time. > and is there > a performance hit? > Reading a cached value does not introduce any bus transfer. Kind regards Jan ___ Owfs-developers mailing list Owfs-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/owfs-developers
Re: [Owfs-developers] Protocol Error Starting owserver
Am 05.05.20 um 21:17 schrieb Dennis Putnam:
> *Hi Jan,** ** **Here is the requested info:*
>
> *systemctl show owserver.service|grep ExecStart*
>
> ExecStart={ path=/usr/bin/owserver ; argv[]=/usr/bin/owserver -c
> /etc/owfs.conf ; ignore_errors=no ; start_time=[Mon 2020-05-04
> 17:17:17 EDT] ; stop_time=[Mon 2020-05-04 17:17:17 EDT] ; pid=485 ;
> code=exited ; status=0 }
>
That means owserver reads /etc/owfs.conf for its configuration
options. As I wrote, we also need to see the contents of that file.
> *I'm not sure how to tell what adapter I'm using (not a hardware
> guy) but I think I was told it is DS2480 as the busmaster and the
> device is DS2413.*
>
You must find out for sure which busmaster you use, and if it is
indeed a DS2480, at which RS232 port it is connected. The Raspi's
internal one? Or one on an USB-RS232 adapter?
> *cat /boot/config.txt*
>>
> # Uncomment some or all of these to enable the optional hardware
> interfaces dtparam=i2c_arm=on
>
I²C is enabled which may mean the host might use an DS2482
hostadapter. W1 on GPIO is not enabled so it can't be that hostadapter.
Kind regards
Jan
___
Owfs-developers mailing list
Owfs-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/owfs-developers
Re: [Owfs-developers] Protocol Error Starting owserver
Am 03.05.20 um 23:55 schrieb Dennis Putnam: > I've installed owfs on my Pi4 but cannot start owserver. I get the > following in journalctl: > > -- Defined-By: systemd -- Support: https://www.debian.org/support > > [...] > That log is not too helpful. We need the output of $ systemctl show owserver.service|grep ExecStart $ cat /etc/owfs.conf Also, we need to know what Onewire hostadapter you use. Is it the bitbanging host on GPIO4? Is it an I²C connected DS2482 or similar? If yes, also show us $ cat /boot/config.txt Kind regards Jan ___ Owfs-developers mailing list Owfs-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/owfs-developers
Re: [Owfs-developers] How to Use Simultaneous
Am 24.03.20 um 11:03 schrieb Mick Sulley: > There have been times when using the owhttpd interface page to look at > the various temperatures I have seen 85 at some resolutions and > apparently valid values at other resolutions. > 85°C isn't an error value but the power-on value. If you get bogus 85°C readings, check the power to the sensors, and also the bus for shorts. > Does it therefore make > sense when reading values within my program to check for a valid read at > 12 bit (my normal resolution) and if it is not valid to then check for a > valid value at lower resolutions? > > I do set /simultaneous/temperature and sleep 1 sec at the start of the > loop, > Don't mix [/uncached]//temperature[X] and /simultaneous/temperature. Use the latter only in combination with [/uncached]//latesttemp > Will this increase the robustness of the system or is it just an added > complication for no real benefit? > Mixing both the single-target and the simultaneous method on the same bus has no benefit but a negative impact. The only reason to use the single-target method is when your sensors aren't powered. Kind regards Jan ___ Owfs-developers mailing list Owfs-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/owfs-developers
Re: [Owfs-developers] How to Use Simultaneous
Am 13.03.20 um 17:05 schrieb zeitvertreib.wiss...@web.de:
> Hello Jan,
> I'm sorry, you are right.
> I do not use bash commands, I do read and write operations from a Python3
> program. I do it step by step, as I'm not used to Python.
> I had a version with uncached, but there was another program error and I
> forgot
> adjusting the file path.
> PATH = "/mnt/1wire/bus.0/"
> *initiation of conversion:*
>
> while True: # Hauptprogramm
> t1 = time()
> fw = open(PATH + "simultaneous" + "/temperature", "w")
> fw.write("1")
> fw.close()
> *reading values:*
> for i in tempList:
> deviceFile = PATH + "uncached/" + temps[i] + "/latesttemp"
> f = open(deviceFile, "r")
> tempBuffer = float(f.read())
> f.close()
> if tempBuffer != 85.0:
> tempw[i] = tempBuffer
> print(temps[i], tempw[i])
> break
> t2 = time()
> print(t2 - t1)
> However, now I wonder about very short conversion times, shorter than 700 ms a
> single 12bit conversion shoul take.
>
Writing to /simultaneous/temperature does not wait for the end of
conversion. You have to do this by hand in case you have nothing better
to do in your program.
Also, I recommend not to use the FUSE binding of OWFS, as it has
unfixable race conditions. Use OWFS' owserver and pyownet instead.
> Actually there is a problem when installing OWFS on Raspian Buster on PIs.
> File
> system an sensors appear in duplicates. I give you a link to the forum of the
> manufacturer of the used DS2482-100 adapter:
> https://www.abelectronics.co.uk/forums/thread/303/owfs-duplicates
>
Honestly, no idea. May be a FUSE bug.
It's best to forget about the FUSE binding at all.
Kind regards
Jan
___
Owfs-developers mailing list
Owfs-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/owfs-developers
Re: [Owfs-developers] How to Use Simultaneous
Am 13.03.20 um 15:12 schrieb hwissing: > Hello, > > I think one issue from the primary question is not answered.. > > /" If I read from '/temperature' then I get them read in much faster > *but I don't get a fresh conversion each time."*/ > This is a very old question, and the mechanism has changed a bit since 2008. > > I have the same issue. First conversion with 8 DS18B20 sensors takes > about 1 sec, immediately following requests take about 40 ms, but > values are not updated. It takes a while till updated values are > acquired, then conversion takes longer. > That is because you read //temperature instead of /uncached//temperature But don't do this either. If you want simultaneos conversions, do instead $ owwrite /simultaneous/temperature 1 $ sleep 1s $ owread /uncached//latesttemp $ owread /uncached//latesttemp $ owread /uncached//latesttemp $ owread /uncached//latesttemp $ owread /uncached//latesttemp $ owread /uncached//latesttemp $ owread /uncached//latesttemp $ owread /uncached//latesttemp Latesttemp has the resolution of the previous non-simultaneous conversion, or, after power-up of the sensor, the resolution set in the sensor's EEPROM. You can adjust the through //tempres. See the manpage: https://github.com/owfs/owfs-doc/wiki/DS18B20 Kind regards Jan ___ Owfs-developers mailing list Owfs-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/owfs-developers
Re: [Owfs-developers] owfs on Raspberry Buster
Am 17.09.19 um 20:58 schrieb Robert Lagus: > That worked! I changed to "server: w1"- And owserver starts, however... > I'm not seeing any sensors: > *owdir* > /bus.0 > /uncached > /settings > /system > /statistics > /structure > > Is this a result of using the module from userspace and not accessing it > directly on the i2c bus? > As soon you use the --w1 option to owserver (or the w1 config option), it doesn't care if there is any onewire hardware connected. That's now the task of the kernel. What you are seeing there is a blank listing. That one /bus.0 is the owserver itself. Please check if the ds2482 module is loaded. If it is loaded and there are slaves connected to the DS2482, they should appear at /sys/bus/w1/devices. You don't need to run owserver for checking that. Kind regards Jan ___ Owfs-developers mailing list Owfs-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/owfs-developers
Re: [Owfs-developers] owfs on Raspberry Buster
Am 17.09.19 um 08:52 schrieb Robert Lagus: > > *ofws.conf:* > ! server: server = localhost:4304 > server: i2c = /dev/i2c-1 > Please check if you have the ds2482 kernel module loaded. What you are doing here is accessing the ds2482 directly from user space. This is ok, but it creates a mess on the I²C bus if the ds2482 module is loaded, as that module access the ds2482 at the same time. So either unload and blacklist that module, or change the owfs.conf line to server: w1 This makes owserver use the kernel modules instead of accessing the I²C hardware by itself. Kind regards Jan ___ Owfs-developers mailing list Owfs-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/owfs-developers
Re: [Owfs-developers] New faulty DS18B20
Am 04.08.19 um 10:02 schrieb Mick Sulley: > Yes it does. I also have a DS18S20 inside the test box that I use, that > shows as well. I have just tried a different DS2401 and get the same > results. > Please take a photo from the label side of the DS18B20, as well as the front and bottom side so we can check if it's obviously counterfeit. Kind regards Jan ___ Owfs-developers mailing list Owfs-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/owfs-developers
Re: [Owfs-developers] New faulty DS18B20
Am 03.08.19 um 22:57 schrieb Mick Sulley: > I recently bought 4 DS18B20 sensors from eBay. When I received them > they did not work, that is they did not show up on the bus when > connected to a DS9490 USB adapter. I reported it to the seller and got > a refund. I then ordered 10 from another seller on eBay, just tested > those and none of them work. I have tried testing a known good sensor > and that shows up as expected. > > Have I just been unlucky? Has anyone else bought sensors which do not > work? Can anyone recommend a supplier whose sensors do work? > Does the DS2401 iButton inside the DS9490 adapter show up? Chances are you blew up the DS9403 protection diode or the EMI choke in the GND line. Kind regards Jan ___ Owfs-developers mailing list Owfs-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/owfs-developers
Re: [Owfs-developers] 1-wire hubs
Am 20.07.19 um 16:52 schrieb Jim Duda: > Hello, > > I have a 6 port 1-wire HUB that I purchased years ago from hobbyboards.com > I think the device has finally stopped working. > Hobbyboards hasn't come back online yet. > > Can anyone offer any advice on any available 1-wire hub devices for sale? > > The only one I can find is from unipi. > https://www.unipi.technology/1-wire-8-port-hub-p31 > If I understand the port wiring given on that site correctly, this is a purely passive wiring helper. You have to wire each sensors so it's at the tip of a lobe coming from the 3+6 GND+DQ pair and going into the 8+7 GND+DQ pair. Kind regards Jan ___ Owfs-developers mailing list Owfs-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/owfs-developers
Re: [Owfs-developers] DS18S20 fault again
Am 15.07.19 um 22:03 schrieb Mick Sulley: > > latesttemp 127.688 8.875 -1.5 127.688 > > temperature 24.9375 24.0625 23.5625 23.375 > > So temperature is about right, but latesttemp is wildly out. I always > thought that latesttemp was derived from temperature, temperature9, > temperature10, temperature11, temperature12 on a DS18B20 and just from > temperature on a DS18S20, but that is not what I am seeing here. > Reading /uncached//latesttemp reads the sampled temperature value from the scratchpad register on the DS1820 chip while reading /uncached//temperature will first initiate a new temperature conversion, then read the sampled temperature value from the scratchpad register on the DS1820 chip. The latesttemp nodes are meant for use in conjuction with the /simultaneous/temperature nodes. Trigger those once for all chips, read the results from latesttemp on each chip one second later. If you skip the /uncached part, you read from OWFS's internal cache instead. Only if the cached value is considered as too old by OWFS, it does the same operation as the /uncached variant. The cache is updated in any case, but only for that single node read. > I have always considered the DS18S20 and DS18B20 to be similar enough to > not really prefer one over the other. Is that true or is one better in > terms of accuracy, reliability or any other factor? > These are binned variants of the same chip. The DS18S20 has 9 bit accuracy only, while the DS18B20 supports 12 bit accuracy. Kind regards Jan ___ Owfs-developers mailing list Owfs-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/owfs-developers
Re: [Owfs-developers] bus interface statistics
Am 13.07.19 um 22:36 schrieb Mick Sulley: > > One other thought, I have separate power supplies for 1-wire and the > Pi. Can I just power cycle the 1-wire adapter and leave the Pi running? > It's only ever neccessary to power-cycle the DS2482-800. I found a problem related to spurious bus shorts and the DS2482-800 just a few days ago in a customer's equipment. Power-cycling the DS2482-800 fixed it each time. So I kept plugging in iButton locks and keys until I had the culprit which put the DS2482-800 into coma. Replaced it – all ok now. (Note: Some types of iButton locks are prone to short-circuit. The DS2482-800 does not like it at all.) Kind regards Jan ___ Owfs-developers mailing list Owfs-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/owfs-developers
Re: [Owfs-developers] bus interface statistics
Am 11.07.19 um 23:10 schrieb Mick Sulley: > Looking at my system via owhttpd at top level I can see all the devices > and some other things - > > bus.0 seems to mean the bus structure, so in there I can see bus.0 to > bus.7 In each of these I see just the devices on that bus plus > interface, simultaneous and alarm, and drilling down into > interface/statistics there is more data > bus.0 to bus.7 may be the channels of a single DS2482-800, or they may be a mix of individual adapters or owservers connected. You may find bus.4/bus.6 for channel #6 of an DS2482-800 at the owserver listed as bus.4. As owservers may connect to other owservers, there may be even more levels. > Is there any documentation on the data in there? > The manpages! See e.g. https://packages.debian.org/de/sid/all/owfs-doc/filelist for a list of typical installation pathes. > The reason for the question is that I still have random bus lockups and > I am considering creating something to power cycle the system, either on > a time basis, e.g. 3am each day, or based on some early warning > detection from the data in interface/statistics if that is possible. > > Does anyone have an opinion on scheduled power cycle? Good idea or not? > The DS2482-800 is known to be susceptible to dips in its power sluppy. Depending on your setup, it may be also susceptible to shorts on any of the Onewire channels (because they affect the power supply of the DS2482-800). The only known way to get the chip out of this unuseable mode is power-cycling it. One short dip is enough. There is no warning. I would rather find the source of the power supply problems or shorts than applying a crude fix. The other option is not using the DS2482-800 but several DS2483 instead. Kind regards Jan ___ Owfs-developers mailing list Owfs-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/owfs-developers
Re: [Owfs-developers] DS18S20 fault Question
Am 17.06.19 um 22:35 schrieb Mick Sulley: > > So the question is - is it possible to have a fault on a DS18S20 which > can cause it to heat up and pull the voltage down? > Certainly. But the fault isn't the DS18S20 but the 1W host. The 1W host has to supply current to the 1W line to power all the parasitic powered slave devices. It does so through the 1.5–4.7kΩ pullup resistor in normal operation. That current isn't sufficient during a temperature conversion however. During that time, the power supply is connected to the 1W through a considerably lower resistance. That's called the "string pullup" That's okay as long the slaves idle. If you have a short 1W dip in the bus to to a short or interferences, the slaves may think it's a bus reset from the host and answer with a presence pulse, which means they pull the bus low. If the host supplies power through the strong pullup, that means there is a short through the pulldown transistor of the slave. Nothing bad happens if that occurs once. It's bad however if it occurs again and again. Then, those shorts will heat up the slaves. Check your onewire cabling and sources of interference, e.g. power cables nearby. Kind regards Jan ___ Owfs-developers mailing list Owfs-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/owfs-developers
Re: [Owfs-developers] ds18b20 always showing 85 as temperature output
Am 17.05.19 um 10:15 schrieb nihar Modi: > Hey, thanks for the reply. But meanwhile I got in new trouble. Owdir > command sometime shows all the sensors but as I add a new one it randomly > shows two or three sensors only. I am trying continuously for two days and > same problem persists. > Please post how owserver is started in your setup. $ ps aux|grep owserver If there's owfs.conf mentioned in the above result, please post it. $ cat /etc/owfs.conf If you are controlling the I²C through owserver directly (option "i2c") and not through the kernel driver (option "w1"), the you **must not** have the kernel driver loaded. $ lsmod|grep ds2482 It's recommended to use the kernel driver (option "w1") though. > I am using 7-8 ds18b20 with ds2482-800 and powering > it through R pi 3b 3.3 volts. I am using external 4.7K pull up. Please tell > a solution. Thanks in advance. > Again, you don't need pullups if you use the DS2482-800. It has internal pullups. You setup sounds reasonable. If it fails, there must be a problem not yet discovered. Kind regards Jan ___ Owfs-developers mailing list Owfs-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/owfs-developers
Re: [Owfs-developers] ds18b20 always showing 85 as temperature output
Am 16.05.19 um 11:33 schrieb modi: > Hi > I am using owfs for first time. I have to take temperature from 10 dsb1820 > through ds2482-800 via r pi 3. I have followed instructions from > http://www.sheepwalkelectronics.co.uk/RPI2_software.php . > > It is giving correct values until I connect 5 sensors on one bus. As soon as > I connect 6th one it gives 85 as output. I have tried 3 on one bus and 3 on > other but same 85 output. I have tried 1.5K instead of 4.7K, no difference. > I can only use 3.3 volts for ds2482-800 as it is a part of larger system. > 85°C is the power-on value. If you get a steady 85°C readout, it means your sensors power-cycle during the conversion. You don't have to put pullups to the DS2482-800's 1W pins, it does so internally. It also uses its strong pullup feature automatically. Check your power supply. Kind regards Jan ___ Owfs-developers mailing list Owfs-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/owfs-developers
Re: [Owfs-developers] Pi Crash Question
Am 20.04.19 um 23:10 schrieb Mick Sulley: > Hi Jan, > > Thanks for your help - again! > > I started to unplug parts of the network, didn't make any difference, > then I remembered that I had seen this before, dug back in my emails and > we had a similar email conversation in 2017. By default (I think) > Raspbian starts w1 and that interferes with owfs. > A recent Raspbian install will use the w1 kernel driver for OWFS instead of controlling the hardware directly. > In case anyone else > picks up this thread this is what I did to prevent w1 from running > > edit /boot/config.txt and comment out the line > > dtoverlay=w1-gpio > This can't be an OWFS problem because driving gpios directly isn't supported by OWFS. > > I was seeing that message about every minute. It is now an hour since I > made the change and there hasn't been a single one! > In that case, you have connected something else to GPIO4, and the enabled w1-gpio conflicts with that hardware/software but not OWFS. > A couple of other questions, > > * Could this issue have caused the Pi itself to crash? > No. > * I know that due to the nature of 1-wire read failures will happen > occasionally, but what is the expected failure rate roughly? > That depends on the cabling. One in a minute for a fully loaded bus is what I encounter in my installations. Kind regards Jan ___ Owfs-developers mailing list Owfs-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/owfs-developers
Re: [Owfs-developers] Pi Crash Question
Am 20.04.19 um 16:47 schrieb Mick Sulley: > I just had the Pi on my main control system crash. Looking through > syslog there are load of entries like - > > Apr 20 14:47:35 pi-solar kernel: [1816089.721179] w1_master_driver > w1_bus_master1: Family 0 for 00.c611.3f is not registered. > Apr 20 14:48:00 pi-solar kernel: [1816114.723725] w1_master_driver > w1_bus_master1: Family 0 for 00.2611.d6 is not registered. > Apr 20 14:48:51 pi-solar kernel: [1816165.440416] w1_master_driver > w1_bus_master1: Family 0 for 00.a611.5a is not registered. > > I think this is 1-wire related > But not OWFS related. These are messages from within the kernel driver. It specially complains about unregistered device classes. Which is connected to some problem with your bus, in this case. Split the bus into pieces and check when the problems disappear. It may be some problem with your external power supply. Kind regards Jan ___ Owfs-developers mailing list Owfs-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/owfs-developers
Re: [Owfs-developers] DS2438 Question
Am 23.03.19 um 11:29 schrieb Mick Sulley: > I am using a DS2438 to measure my system +5v line and log it. As I > understand it the voltage measurement can be triggered by setting > /simultaneous/voltage in the same way as for temperature. As I want to > use both, can I set /simultaneous/voltage and /simultaneous/temperature > together or should I set one then wait 1 sec before setting the other? > There is no reason to wait between those commands. You have to wait one second for the temperature result to become meaningful, though. Kind regards Jan ___ Owfs-developers mailing list Owfs-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/owfs-developers
Re: [Owfs-developers] Strange read failure
Am 10.03.19 um 20:53 schrieb Mick Sulley: > Ahhh!!! I always refer to the descriptions on owfs.org, which don't > show tempres so I hadn't realised that it existed. > Read the manpages. They are accurate and pretty up-to-date. https://github.com/owfs/owfs-doc/wiki > So I assume that the resolution comments refer to the DS18B20, but the > DS18S20 is 12 bit and no possibility to change it. > > If I set tempres to say 11, then write to /simultaneous/temperature will > it then read at 11 bit and update latesttemp and temperature11? > I'm sorry but what I just wrote from memory is only half correct. You can set the default resolution through writing the tempres node. But reading returns the default resolution instead of the current resolution. Hmm. Let me think about it a bit. Kind regards Jan ___ Owfs-developers mailing list Owfs-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/owfs-developers
Re: [Owfs-developers] Strange read failure
Am 10.03.19 um 19:46 schrieb Mick Sulley: > OK, but looking through Jan's checklist again - > > * power all sensors > * set the sensor EEPROM to 9 bit default resolution. > > ?? How to do that? Is it just a read temperature9 on DS18B20? > With recent OWFS, you simply write 9 to the sensor's tempres node. > Then, the readout thread is as follows: > > 1. trigger a 12-bit resolution conversion on each sensor for > initialization. > 2. write something to /simultaneous/temperature to trigger all > temperature conversions at the same time. > 3. wait a second > 4. read /uncached//latesttemp of each sensor > 5. If the result for a sensor is not 85°C, store and go to 2. > 6. 85°C. Check the resolution. If it is still 12 bit, that's a valid > reading. Store and go to 2. > > ?? How do I check the resolution? > Read the sensor's uncached tempres node. Kind regards Jan ___ Owfs-developers mailing list Owfs-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/owfs-developers
Re: [Owfs-developers] Strange read failure
Am 19.02.19 um 14:35 schrieb Mick Sulley: > 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? > What I recommend to do for preparation is: * power all sensors * set the sensor EEPROM to 9 bit default resolution. Then, the readout thread is as follows: 1. trigger a 12-bit resolution conversion on each sensor for initialization. 2. write soemthing to /simultaneous/temperature to trigger all temperature conversions at the same time. 3. wait a second 4. read /uncached//latesttemp of each sensor 5. If the result for a sensor is not 85°C, store and go to 2. 6. 85°C. Check the resolution. If it is still 12 bit, that's a valid reading. Store and go to 2. 7. Power-on-reset. Store an error. Trigger a 12-bit resolution conversion for that sensor and go to 2. Kind regards Jan ___ Owfs-developers mailing list Owfs-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/owfs-developers
Re: [Owfs-developers] Strange read failure
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
Re: [Owfs-developers] Reliability and Robustness of the DS2482-100 or DS2482-800
Am 15.02.19 um 10:19 schrieb Mail Lists: > > 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? > The DS2482-800 has one problem. If the power to the chip dips, which may happen due to a bus short, it sometimes refuses to switch to another channel until you power-cycle it fully. So, use 10Ω series resistances on the buses to avoid that problem. Or use several DS2482-100, or DS2483, or DS2484. Kind regards Jan ___ Owfs-developers mailing list Owfs-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/owfs-developers
Re: [Owfs-developers] DS18B20 Question
Am 30.10.18 um 15:35 schrieb Mick Sulley: > I had a temperature sensor fail and replaced it but I am seeing strange > results from the new one. > > This is what I see. Why do Temperature 11 & 12 seem OK but 9, 10 and > Lasttemp are all 85? Is it a bad sensor? > owhttpd cannot sample all those values in an atomic way. OWlib's transactions are one node at a time. So there's no way we could know in which order all those values had been sampled. Please run owserver, and check every single node with $ owget /uncached/28.48999D04/... Kind regards Jan ___ Owfs-developers mailing list Owfs-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/owfs-developers
Re: [Owfs-developers] DS2482-800 reset ?
Am 23.10.18 um 02:35 schrieb Laurent FAILLIE via Owfs-developers: > Hi all, I'm back on this old problem as, despite I secured my power > path, my DS2482-800 still hang randomly (it's quite rare but it's > happening).Having a look on the datasheet, it seems this chip can be > reset using an I2C "Device Reset Command" : DRST or 0xF0. I'm > thinking to patch OWS to expose a "reset" pseudo file to issue this > command ... but my concern is : is it safe to do it or do I send > additional command to make the chip usable to OWFS ?Any tip to save > some time is welcome :) Bye Laurent > This command is used when owlib enumerates the DS2482 on the I²C bus. If it helped the issue, restarting e.g. owserver would remove the lockup. It doesn't. Unfortunately. Kind regards Jan ___ Owfs-developers mailing list Owfs-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/owfs-developers
Re: [Owfs-developers] Power Supply Question
Am 20.10.18 um 22:01 schrieb Mick Sulley: > > You say that the DS2482-800 can reset to an unusable state, would the > same apply to the DS2482-100? Sheepwalk now make a dual channel RPi2 > and I could stack 2 to get 4 channels and I think I could manage with > that if the lock up problem is fixed. > We haven't had the same complaints from people using the DS2482-100 on this list yet. If I remember correctly. But personally, I hadn't got the lockup problem either once the power supply problems were fixed. Check your power supply. Kind regards Jan ___ Owfs-developers mailing list Owfs-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/owfs-developers
Re: [Owfs-developers] Power Supply Question
Am 20.10.18 um 18:22 schrieb Mick Sulley: > I have a Pi with Sheepwalk RPi3 adapter running multiple temperature > and I/O. I get random read failures and bus lock up, read failures > every day or two, bus lock up every week or so. > You can't to anything about spurious read and write failures. It's a bus system, they happen. You have to implement a retry on the hostn side and failsafe logic on the device side. It can be tricky. (I just had the problem with a remote on-off switch. Sometimes, the **off** command is broken. Solution: always use anm on-timeout on the device. On-commands have to be repeated each few seconds. That way, a lost instant-off command will not do endless harm.) About the bus lock-up, that's a bug in the DS2482-800, I think. I had it. Various other people had it. The DS2482-800 seems to be susceptible to supply undervoltage and slow rising of the supply voltage. It resets into an unuseable state. Only a complete power-down and quick power-on will make it useable again. Check your power supply. > Currently I have > separate power supplies (Meanwell units) for the Pi and the 1-wire > and they are both floating. > > Question - Is there an advantage in linking the 0v on the two > supplies? > You cannot have them floating. The sheepwalk adapter has a shared GND for both the Onewire and the I²C (Raspberry side). The individual ports are protected my DS9503 chips, as far as I can see it from the photos. These have 5Ω resistors in the GND lines of each connector. A good thing, do not change that. > Also should the 0v be connected to the mains earth? > Don't do that. It will give you **less** noise immunity and also fry the low voltage circuit as soon as some high voltage circuit has a ground fault. Kind regards Jan ___ Owfs-developers mailing list Owfs-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/owfs-developers
Re: [Owfs-developers] Announcing a new Python library
Am 05.09.2018 um 10:08 schrieb Matthias Urlichs via Owfs-developers: > >> The DS2409 is already transparently supported by owlib. > Is it? > > Last time I checked, slaves behind a DS2409 or two do not show up > in "owdir /" or "owdir /bus.0" or "owdir /alarm", they do not > notice when I set /simultaneous/temperature, … > > So either I'm missing something, or your definition of > "transparent" differs from mine. :-/ > What you mean is *flattened*. Transparent means you don't have to care for the details of controlling the DS2409's switches on the way by hand if you want to access a certain device. Owlib does that for you. Also, it uses the special branch prefix command to access/enumerate only devices on a branch instead of the whole bus. This can speed up things a lot, e.g. if you have passive iButton locks marked with a single DS2409. I personally don't care if a library creates symbolic links in the main directory. That's one single run through the structure at the beginning. > > For one, support for (bus-specific) handling of /alarm or > /simultaneous. > Yes. > The idea is that different 1wire buses may have different > requirements (timing, polling, alarm handling, how often to trigger > temperature conversion, bus re-enumeration, …); it's the client > system's job to coordinate the device instances' requirements to do > the least-possible amount of work, and only on the bus(es) it cares > about. > Yes, exactly. But that's what a clever designed library can assist the application programmer. By requiring him to think about the logical abstraction of a whole device first, not just a Onewire slave. I understand that's not a simple thing to do for a library aiming at different targets on both sides, but putting in another abstraction layer which then fails to abstract things proved pointless to me. That's why I did this abstraction in my application program, which knows about the devices it controls. 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
Re: [Owfs-developers] Announcing a new Python library
Am 05.09.2018 um 05:20 schrieb Matthias Urlichs via Owfs-developers: > Hi, > > I'm writing a new high-level asynchronous Python library to talk > to owserver. > > It features multiple persistent server connections, transparent > support for DS2409 couplers, automatic retries when he server is > busy or the connection breaks, object-oriented design, > auto-generating accessor methods for bus slaves (based on the > server's /structure tree), reporting state changes via an async > event stream, and more. > > On the TODO list: auto-polling (both distinct and via > /simultaneous), alarm handling. > > Check it out at: https://github.com/python-trio/trio-owfs > These are nice features, but the real thing is aggregates and logical abstraction. The latter is needed for automatically setting up chips according to the modules they are put on after their power-on. Because power-on and unknown states of remote devices is what happens on a hot-pluggable bus all the time. Alarm handling comes in handy there and can also be used for other purposes. I found that writing a simple class hierachy in Tcl for a project using OWFS, which does roughly what you intend. So my advice from pratice is basing all the automatical mechanisms on a logical abstraction of a whole peripheral, with the Onewire stuff being only a part of a bigger picture. The DS2409 is already transparently supported by owlib. Not sure what you want to put on top. 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
Re: [Owfs-developers] DS1921 time linux vs windows
Am 22.08.2018 um 16:16 schrieb Ben Oliver: > I'm having issues with clock settings on a DS1921 going from windows to > owfs on linux, and vice-versa. > > I (on owfs) set the time like this: > > echo "$(date +%s)" > "clock/udate" > Which version of owfs do you use? $ owfs --version Owlib (owfs) uses gmtime_r() to turn the seconds till 1970-01-01 UTC into a representation the DS1921 understands. https://github.com/owfs/owfs/blob/master/module/owlib/src/c/ow_1921.c#L1065 This function assumes January == 0. Unfortunately, the DS1921 datasheet does not state whether January is 0 or 1. Others have the same problem: https://github.com/dustin/ibutton/blob/master/mlan/ds1921.c#L53 So far, I see only one way to find it out who's correct, check whether the February, 29th correction the chip does works right with owlib or not. Volunteers? Maybe Paul (or others) had checked that already in the past? 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
Re: [Owfs-developers] OWSERVER under Windows
Am 05.08.2018 um 14:22 schrieb Rowan Sylvester-Bradley: > Thanks for your input. I'm amazed though that no-one has already got a > pre-compiled version that works in Windows, or if they have, that they > have not made it available to the community. Surely this MUST exist > somewhere? > I haven't used MS-Windows for years now, but as the build relies on Cygwin, use the *Cygwin Installer* http://www.cygwin.com/ This installs the Cygwin library on your computer, as well as it has a package manager for precompiled software available in the Cygwin archives. You can simply pick e.g. libusb there. Maybe you are lucky and they also have an libusb-enabled owserver build at hand. No support from my side, though, for the initial reason. 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
Re: [Owfs-developers] OWSERVER under Windows
Am 05.08.2018 um 12:22 schrieb Rowan Sylvester-Bradley: > I am trying to use a DS9490R USB-to-onewire adapter. > > I want to plug it directly into my Windows PC. I may later add a > Raspberry Pi or similar, but for now I'm trying to keep things as simple > as possible. > Please go for the Raspberry Pi solution as quick as possible. While it's certainly possible to compile *libusb* and *owserver* using *Cygwin* on MS-Windows, it's not well tested and also not an easy thing to do. Certainly no a way to go if you want to keep things as simple as possible. On the Raspberry in contrary, there are pre-compiled owfs packages for Raspbian which you just has to configure. Plus, you get network transparency of your Onwire, even over WiFi if you want. Owserver is the component which does this. It's the OWFS' owlib driver compiled into a binary which provides access to the Onewire through the network. It's a very simple TCP-based protocol. On your MS-Windows host, you can use one of the Owserver language bindings to access the Owserver. OpenHAB does just this, so it boils down to configuring the ip address of the Raspberry and that was it. So, I recommend to buy a Raspberry Pi B+ (or any of the newer ones), load an 4GB SD card with the latest Raspbian Image and install owserver via apt-get. It gets configured automatically for use with the DS9490 through the kernel driver. This is a work of one hour, even for less experienced people. The other way, compiling and configuring Owserver for MS-Windows, will take you several days and lots of frustration. 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
Re: [Owfs-developers] OWSERVER under Windows
Am 04.08.2018 um 23:28 schrieb Rowan Sylvester-Bradley: > I am trying to use OpenHAB in Windows 8.1. I need to interface to some > OneWire devices. I am told that I need OWSERVER to do this. > 1. Which Onewire host adapter do you plan to use? 2. Should it be connected directly to the MS Windows host? OR 3. Do you plan to throw in some Raspberry Pi or other small Linux box for other OpenHAB functions anyway? All your other questions may or may not have to be addressed depending on this. 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
[Owfs-developers] MAX31850 /MAX31851 thermocouple bug
Hi Uwe, and all, Thermocouple users, please raise your hands now! We have a bug report at https://github.com/owfs/owfs/issues/11 complaining the thermocouple value reported by owfs is way too low. Reading the MAX31850 / MAX31851 datasheet, https://datasheets.maximintegrated.com/en/ds/MAX31850-MAX31851.pdf page 13 (table 2), I read the cold junction temperature and the thermocouple temperature are off by a factor of 16, which is roughly what the user reported. Now, in https://github.com/owfs/owfs/blob/master/module/owlib/src/c/ow_1820.c#L963 I see there's a separate resolution entry for the thermocouple binary->float conversion, but it's commented out and uses the cold junction resolution instead of the thermocouple resolution. Paul added that line and Uwe worked on the function, so before changing anything, I ask if this is intended. 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
Re: [Owfs-developers] Moved to GitHub!
Am 08.04.2018 um 10:12 schrieb Johan Ström: > As discussed numerous times before, SourceForge stability is suffering, > prompting discussions to move the project GitHub. > > This has not meet any protests, so now I have taken the liberty to make > the move. > Thanks for doing this tedious 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
Re: [Owfs-developers] git pull returns 502 error message
Am 04.04.2018 um 22:20 schrieb Johan Ström: > > Whatever we do, I really suggest shutting down Sourceforge git. Still > only me and Jan with commit access on github, but I assume any previous > commiters will raise their voices when they need to commit, if not before. > I second that. > > I'm not familiar with procedures of building releases, as that will > change a bit, perhaps Jan who have done latest release can add step by > step instructions for how it works today, into some doc file? > No, this won't change as there's no version control involved when building releases. You had to change VERSION_MAJOR=3 VERSION_MINOR=2 VERSION_PATCHLEVEL=2 in ./configure.ac, (then commit and tag the release in git), then $ make clean $ make distclean $ ./bootstrap $ ./configure $ make dist That creates the .tar.gz which I upload along with a README created by hand, enriched with data from the git log. 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
Re: [Owfs-developers] Correcting DS28EA00 and DS2413 PIO handling
Am 17.03.2018 um 17:59 schrieb Laurent FAILLIE via Owfs-developers: > > The behaviour changed since 3.1 > Can you nail it to v3.1? Which patchlevel? Which was the previous version where it worked as you expected it? 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
Re: [Owfs-developers] Supporting custom probes
Am 15.03.2018 um 17:24 schrieb Laurent FAILLIE via Owfs-developers: > Hi all, > I have a project to build custom slave 1-wire probes.Is some where a tutorial > how add support within OWFS ? > Use the source! That said, you may want to take a look at this https://github.com/owfs/owfs/commit/caea0ed8d8641a87bfd345f49d65cf7c022290f1 commit. It adds support for the iButtonLink Smart-Slave series. It's a very basic and yet complete example how to add you own driver code to owfs. 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
Re: [Owfs-developers] git pull returns 502 error message
Am 06.03.2018 um 07:23 schrieb Johan Ström: > And no opinion against here either.. SF seems to have shaped up last day > or two, but who know how long that will keep.. > > What are your suggestions? > > Move GIT only, and keep site + mailinglist on sourceforge? > Releases on Github I guess? > (https://help.github.com/articles/creating-releases/) > 100% Github, please. The numerous ways to file bug reports and asking for help make me dizzy already. 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
Re: [Owfs-developers] git pull returns 502 error message
Am 02.03.2018 um 01:48 schrieb Gregg Levine: > Hello! > I have the most recent numbered release on a Pi3 (now on a Pi Zero W) > running and working. However since I previously also released the > newest code via a git clone when setting up the directory. > > Now however I need to update things, and it is returning that error > message. It means bad gateway. > sf.net has the hiccups at the moment. 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
Re: [Owfs-developers] Requesting clarification on 'mission' for DS1921
Am 24.01.2018 um 18:02 schrieb Ben Oliver: > Apologies in advance if this is in the manpages somewhere but I can't > find it. > > I have a load of DS1921 loggers I am looking to provision as efficiently > as possible (I have 100+ and they all need to run with the same > settings). I thought using OWFS and a bash script might be a quick way > to loop through them. > > However, I am unclear on what all the options are/mean - especially in > 'mission'. > > Is there anywhere I should be looking for more information? > Aside from the manpage DS1921, only the sources in module/owlib/src/c/ow_1921.c. Be aware this is unchartered territory and not well tested. > I'm curious about the following: > > mission/date > The date when the current mission was started. > mission/easystart - what does it do? > The idea is to write *anything* to mission/easystart, then the following happens: * all memory is cleared * clock is stopped * no rollover, no delay, temp alarms on is setup * pending alarms are cleared * a new mission is started > mission/frequency - what units? > Minutes between samples. Writing a positive value starts a new mission, writing a negative value stops the current mission. > mission/clear - what does it do? > * all memory is cleared > mission/enable - what is the difference between this and 'running' > This is controlling the EM bit in the control register directly. > mission/running - see above > Writing 0/1 starts/stops a mission, reading returns the MIP bit in the status register. > Also, is there a built in way to pull the date and temperature data in > one file that I am missing? > No, you have to concatenate the memory pages yourself. 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
Re: [Owfs-developers] DS2423 counter read error
Am 20.01.2018 um 00:35 schrieb Péter Zsembery: > Hi All, > I am trying to read the counter values of two DS2423 1-wire counters with > OWFS 3.2p1. The OWHTTPD always returns "Error: Invalid argument" for the > following parameters: > counter.ALL > counter.A > counter.B > memory > mincount > pages/ > The other parameters are correct. > The wiring is double checked. Seems to be OK. > Is Vbat connected to a 2.8..5V source? The DS2423 parasite powered circuitry does provide power to all the ROM function components but as soon the RAM or counters should be accessed, you need Vbat. 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
Re: [Owfs-developers] Running owfs unter systemd makes /run/owfs mount inaccessible.
Am 07.01.2018 um 14:38 schrieb Christian Vogel: > Hi, > > running owfs 3.2p1-1 on ArchLinux (installed via aur), with recent > systemd the mount for owfs does not show up in the system. This is > caused by the RuntimeDirectory in /run essentially being a bind-mount > from somewhere else (as researched by the nice folks in the #systemd > channel). The mount of owfs then doesn't propagate to the rest of the > system and is invisible to everything but the owfs process. > > Please change the mount to somewhere outside of /run, I propose > /dev/bus/owfs. See attached file. > Christian, this mount shouldn't be there. No one should use the owfs binary for production. It has a naughty race condition which cannot be fixed without file locking – which no user program uses when accessing the filesystem presented by owfs. Distributions should fix their installations disabling the "owfs" binary by default, instead install and configure the owserver binary and the owread, owwrite, owget, owdir shell access tools. There's no use in fiddling with the owfs mountpoint. The whole idea is known to be broken and should be replaced by owserver+friends. 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
Re: [Owfs-developers] python-ow failure with new Raspbian Stretch
Am 17.12.2017 um 17:45 schrieb Gregg Levine: > 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. > The tcl binding does not use swig but a native binding. Works with Tcl-8.5 (my production environment), have to test with Tcl-8.6. If anyone has problems compiling it, it's mostly because tclConfig.sh isn't found automatically, which can easily be fixed by using the ./configure --with-tcl=... 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
Re: [Owfs-developers] USB-I2C-1-wire for Star Networking
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
Re: [Owfs-developers] USB-I2C-1-wire for Star Networking
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
Re: [Owfs-developers] Potential bug with DS2413 and DS28EA00 GPIOs.
Am 26.11.2017 um 17:35 schrieb Laurent FAILLIE via Owfs-developers: > Hi all, > > I'm playing with a DS28EA00's PIOs and a LM393 based rain detector (the > classical schema used as well on light detector, vibration detector, etc ...). > > * PIO.A is used to switch ON / OFF the detector by controlling it's VCC > through a transistor : no problem here. > * PIO.B is connected LM393 output with an inboard pull-up. > > The problem is if LM393 is low when PIO.A is set low (to switch on the > detector), PIO.B is forced as output LOW. > It's clearly an issue with OWFS as I tested with an ESP8266 with following > code and I haven't this issue : > The current OW_w_pio() function inside module/owlib/src/c/ow_1820.c is rather primitive, it always writes both the PIO.A and PIO.B bits. As a workaround, please use PIO.ALL or PIO.BYTE and store the current value of all bits in your application. I will take a look for a more sophisticated solution in the meantime. 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
Re: [Owfs-developers] (no subject)
Am 16.11.2017 um 11:56 schrieb FireWorker: > > I will running a OWFS Server with 2 DS9490 USB Adapter. > > i must differentiate on witch DS9490 Adapter a I-Button is connectet > > What must i do that the first DS9490 allways connect to Bus.1 and the > second allways connect to Bus.2. > and they are not make a change when the Maschine is rebooting > > sorry my bad English > Peter, die einfachste und zuverlässigste Methode ist ein Mapping. Die DS9490-Adapter haben einen eingebauten DS2401 mit der Seriennummer 81.xxx. Du schaust am Anfang deines Programms auf den bus.0/ drauf und guckst nach, welcher der beiden 81.xxx-Chips, deren Seriennummern das Programm kennt, an bus.0 dran ist, mit bus.1 genauso. Wenn die Zuordnung falschrum ist, drehst du sie in deinem Programm einfach um. Mit freundlichem Gruß 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
Re: [Owfs-developers] owserver and owcapi behave differently with —enet device
Am 08.11.2017 um 22:51 schrieb Andrew Brownsword: > Nothing but crickets — is anyone out there? > > I’ve been poking at the code to try and figure out how to enable my > debugger to step into the libowcapi/libow code, but the make process > is obscure enough that some advice would be welcome... > I had hoped someone with more experience with enet devices than myself (== zero) would answer that. So, if you place an owserver inbetween, it works for obscure reasons? I would check the owserver code then, if it does something differently than your code does. 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
Re: [Owfs-developers] DS1923(-F5)
Am 20.09.2017 um 07:14 schrieb Dr. Trigon: > Hello > > I have a Thermochron DS1923 lying around and would love to be able to > use it as a logger. But when I tryied I found that owfs does not > support that yet: > https://sourceforge.net/p/owfs/mailman/message/23219052/ > > What are the plans? Is anybody working on it? > Anything but the password protection is supported, but at the same time hardly tested. 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
Re: [Owfs-developers] Resetting/reinitialize a DS2450
Am 06.08.2017 um 18:52 schrieb Michael Hughes:
>
> I am using the ow C API to read all of my Dallas 1-Wire devices.
> I do a OW_init("/dev/cuao0"). I then go in to a loop and use
> OW_get to read each device. I use the following line to read the
> voltages:
>
> OW_get( "/uncached/1F.49D1/main/20.EDCD/volt.all",
> &buf, &s );
>
Please give me some time to prepare such a setup of a DS2450 behind a
DS2409 myself.
Could you test if you had the same problem when the DS2450 is directly
connected to the host adaptor?
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
Re: [Owfs-developers] Many-port bus master
Am 02.08.2017 um 01:41 schrieb Alastair D'Silva: > > My situation is a bit special - all the lighting, roller shutters, > fans, etc will be controlled by the bus. By splitting out as many > ports as I can fit on the microcontroller, it means that I can have > many independent buses with only a few devices on each. This keeps > the weight of bus down, and speeds up search/alarm search times. > While I totally agree on unconditional searches, I disagree on conditional (alarm) searches. That is because there usually is either none or one device signalling an alarm. Searching for alarmed devices every second or so, then clearing that alarm condition works very quickly. > It also means that a fault on the data line will only take a room, > rather than the whole house. > You need an access panel for the room's functions anyway. That's your Pi. One per room. So … you only need one bus per Pi, don't you? Ten years ago, I had agreed on having only one central computer. But nowadays that stuff is so cheap people want to have an access panel in any room. (And no, a smartphone is as bad as the remote you always forget where it is.) >> >>> I'm currently considering how the device should present to >>> OWlib: >>> >> I found it most useful if you wrote a w1 kernel driver for it >> instead, so one could also use the DS28E17 Onewire-to-I²C bridge >> with your chip. > > Are there any downsides to presenting as a kernel driver rather than > an OWlib driver? > If it is an I²C or SPI device, no. An RS232 device needs some thought, as the TTY subsystem needs to be aware this port isn't a TTY anymore. You need to define a "serial line disclipine" defining the protocol as for RS232 connected mice, touchscreens and so on. > When we say "poor performance" on > http://owfs.org/index.php?page=w1-project , what exactly do we mean? > > I plan on doing alarmed searches on some ports at ~10Hz so that my > light switches respond with reasonably low latency. Would this be > achievable with a W1 driver? > If you offload the search into the chip, sure. Doing it on the main CPU requires playing with scheduler settings as the 15ms required for searching one alarmed device is a very long time for a process to run continously. Real-time priority required or the process gets a very low dynamic priority and is slowed down. This is both for a OWFS only driver and a w1 kernel driver, as the latter acts on behalf of the calling process during alarm searches. Withbout scheduler tricks, I was able to get down to 250ms per loop. 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
Re: [Owfs-developers] Resetting/reinitialize a DS2450
Am 02.08.2017 um 01:17 schrieb Michael Hughes: > > If for some reason the leg that a DS2450 is on drops off line and then > comes back online, the values that are retrieved don't make any sense. > If I restart my program it will work again. Is there anyway to > reset/reinitialize the DS2450? I'm reading the values from it with a > get of /uncached/1F.49D1/main/20.EDCD/volt.all. > Which version of owfs are you using? If not v3.2p1, I suggest to update first. $ /opt/owfs/bin/owserver --version 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
Re: [Owfs-developers] Arduino yun as wifi 1wire master
Am 01.08.2017 um 20:09 schrieb Dr. Trigon: > > Regarding power, I assumed the > processors consumption (avr vs. arm, yun vs. raspi) > The Arduino Yun has an ARM processor, too. It's called "Wifi shield", but it's the main processor of that board. The AVR is on-board to be able to call it "Arduino", it seems. 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
Re: [Owfs-developers] Arduino yun as wifi 1wire master
Am 01.08.2017 um 20:09 schrieb Dr. Trigon: > > owserver-deamon that would be needed to run on the Raspi Zero W e.g., > means running 'owserver' binary, right? > Yes,sure. > The reason why I wanted to avoid running another instance of owserver > in the first place, was power consumption > Wifi is going to eat your battery. The CPU does mostly nothing and will eat <1/10 of Wifi. Also, if you want to save energy, you should use one of the "commercial" Onewire host adapters, e.g. the DS2483. Bitbanging wakes up the CPU on every bit sent and this will eat a lot of energy. (But still *nothing* compared to Wifi.) > 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. > These most likely came from people who have problems setting their stuff up correctly and mixing up things. > 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.) > With only one core, there is only one process running. All the other processes are waiting in the scheduler queue. What effects energy consumption of the CPU in a non-number-crunching application is the number of interrupts to service. That is because each interrupt means waking up the CPU from sleep. All other effects are neglible. You don't have to count processes, you have to count interrupts. Wifi produces a lot. Timer produces an awful lot when the CPU has to bitbang things. 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
Re: [Owfs-developers] Many-port bus master
Am 01.08.2017 um 16:01 schrieb Alastair D'Silva: > Hi folks, > > I'm currently designing an open-hardware 32 port 1wire bus master for part > of my home automation system, and would like your input. > > The design is based around an STM32F412ZG microcontroller, with MOSFET > active pullups & drive transistors. It will present as a hat for the Orange > Pi Prime (other Pis may also fit). My plan is to connect over the serial > port, but I've also wired through I2C & SPI just in case. > A hat employing standard connectors is going to be more useful to average users. This limits the number of channels because of the size of the hat. And nearly no one would need 32 channels. The 8 channels the DS2482-800 offers are already too much for most applications. What would be incredibly useful is a chip that does have separated RX and TX lines for each channel so one could use optocouples for totally isolated onewires. People using Onewire for building a weather station will love you for such a thing. Your hat should employ these, as well as an optional isolating DC-DC converter! What would be also useful is a device that offloads e.g. the search algorithm as the DS2490 does. That chip is now unavailable outside of the DS9490U device. > I'm currently considering how the device should present to OWlib: > I found it most useful if you wrote a w1 kernel driver for it instead, so one could also use the DS28E17 Onewire-to-I²C bridge with your chip. > Option 1: Maintain an internal hashtable mapping devices to ports, and > present as a single bus master. This has the downside of limiting the > potential number of devices, as well as monopolising all the buses during > long events, such as a firmware update. This would be annoying, as my light > switches won't respond across the whole house if I have to update the > firmware on any device. > > Option 2: Present as a single multi-bus master. I'm not sure if OWlib has > such a concept, if not, there may be significant infrastructure work > required. If it does, great, as hopefully OWlib will keep track of which bus > a device belongs to. > Just look at the DS2482-800 host adapter code. > Option 3: Present as many bus-masters. I think this would be a reasonable > solution, as other buses should continue to operate even if one is > monopolised by a firmware update. In this situation, only a single room will > stop responding, rather than the whole house. > On the OWFS level? Better not, it would make the configuration awfully complicated and require an awful lot of work. > > PS. Would it be possible to get my current work reviewed? I'm not quite > ready to push it upstream, but it would be good to know early if there is > anything there that would prevent it from being merged. My repo is here: > https://github.com/InfernoEmbedded/owfs/tree/infernoembedded > Please do not use the same source file for both your upcoming host and your current LED controller and relay boards. If you are happy with your current devices **and have them tested against the current version of owfs**, prepare a patch and I will push it into master. You are the only one who can test it anyway as long noone else has this hardware. 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
Re: [Owfs-developers] Arduino yun as wifi 1wire master
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. > I don't know what weird idea you have about how owserver works but it's designed explicitely for the thing you want to do. I use it that way in my setups. It is "bullshit" (to use your words) to avoid owserver just because you … yeah, what … don't know it better? > Basically > I could write a sketch for Arduino that emulates linkhube master and > then should be able to connect this to owserver but that would be > quite some effort given FHEM has already a solution for this... The > power btw. is no concern, if needed I can use a car battery... ;)) > This means reinventing the wheel. Have fun. 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
Re: [Owfs-developers] Arduino yun as wifi 1wire master
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
Re: [Owfs-developers] Arduino yun as wifi 1wire master
Am 16.07.2017 um 20:36 schrieb Dr. Trigon: > > I am looking for a possiblity to wirelessly attach 1wire slaves to my > bus for quite some time. The Arduino Yun can act as a wifi client and > connect to other wifi nets [1]. Also an Arduino can be used as a > 1wire master by setting up OneWireFirmata [2]. Do you see any chance > to make that working? To get something like a "wireless LinkHubE"? > The Arduino Yun's main processor runs an OpenWrt derivative. Owserver is available as a package for newer OpenWrt Linux distributions, but only version 2.8p13, it seems. That would mean you had to cross-compile it yourself to be up-to-date. Backporting to a six-year old version doesn't make sense. It would be much easier for you to use a Raspberry Pi Zero W because it runs the Raspbian distribution which is more up-to-date. Hook up a DS2483 to one of the I²C ports of the Raspberry or use the bitbanging master. They are both supported OOTB. (Personally, I think the Arduinos jumped the shark a long while ago.) 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
Re: [Owfs-developers] eservice LCD
Am 16.07.2017 um 20:22 schrieb Dr. Trigon: > Hi Jan > > After long time I got around to play with 1wire some bit again. > > I would like to give this LCD another try as I feel we must be close > to a solution. What is the most simple way to get the code and test > this (e.g. on a raspi)? > Download the v3.2p1 release and apply the patches I sent on 2016-07-05. They should still match. We could debug it further then. 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
Re: [Owfs-developers] Help with writing a new device driver
Am 04.07.2017 um 23:06 schrieb Nigel Titley: >> >> maybe there us the additional way to send some free sample to >> developers of owfs and ask them to help you additional to your >> own work. >> By that way it is (So my suggestion) the fastest and easyest way to get >> your unit to run. >> > Already tried this but got no takers, I'm afraid. > As I could really make use of such a device for my customers, I will help you out if you send me a sample. [Postal address given in private email] 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
Re: [Owfs-developers] Help with writing a new device driver
Am 04.07.2017 um 17:38 schrieb Nigel Titley: > Folks, I'm trying to add a new 1-wire device to OWFS and thrashing > around trying to make a start. I've tried looking at the code for > various devices and can sort of see how it hangs together but I wondered > if there was a guide anywhere (unlikely, I know) or any suggested order > of reading of code or *anything* really. I'm sure once I start to get > the feel of it I'll be Ok but at the moment I'm just thrashing. > No, there isn't a guide on writing OWFS drivers as far as I'm aware of. My advice is to take the module/owlib/src/c/ow_2450.c file as a template. It has a clear structure, touches a lot of subsystems and you can leave out things you don't need easily. What does your device do? 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
Re: [Owfs-developers] Unsupported 1-wire device
Am 03.05.2017 um 18:55 schrieb Péter Zsembery: > > 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. > Yes, and it's quite simple. You have to add support for it in the owlib part of owfs. You find it in the sources below module/owlib/src/c. Is your onewire slave fully custom, or is its programming interfacve similar to an existing device. If the latter, you can take one of the existing slave support source files and tweak it a bit. Or copy and tweak and adjust the makefiles etc. Do you have documentation of your custom slave device? I (or someone else with insight) could help you adding support for it into owfs. 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
Re: [Owfs-developers] How to perform lowlevel read operation from libow or libcapi?
Am 04.04.2017 um 09:47 schrieb Потапенко Сергей: > > How I can get access to lowlevel iface of OW bus from private data > structures > of libcapi ? > You cannot. Libow and owcapi are just there to hide those details from the user. If you want to access a new slave chip, the easiest way is to add support for it in owfs. Find the existing code under modules/owlib/src/c/. If you provide information and are willing to test, we could also help you adding support for your ow slave chip. 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
Re: [Owfs-developers] How to perform lowlevel read operation from libow or libcapi?
Am 04.04.2017 um 09:47 schrieb Потапенко Сергей: > Hi, > Please help me with libow (owfs) API. > How I can send the command "Read ROM" (0x33) and get response from OW bus at > this? This is needed for working with ds1990 similar device . > How I can get access to lowlevel iface of OW bus from private data > structures > of libcapi ? > Reading the /bus.0/simultaneous/single node issues a READ ROM (0x33) command. Reading the /bus.0/simultaneous/single_ds2400 node issues a READ ROM (0x0F) command. The result in both cases is the ID of the single chip connected to the selected bus (here: bus.0). e.g. # owserver --i2c=ALL:ALL $ owread /bus.0/simultaneous/single Please note you cannot use these nodes with the DS9490 host adapter, as it already has an iButton built-in. Connecting another onewwire chip and issuing any of these commands results in wired-and garbage data. 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
Re: [Owfs-developers] DS2438 reporting A6 as family
Am 30.11.2016 um 22:25 schrieb John Bass:
> Hello Jan,
>
> Found it a while back, and yep it works :-)
>
I've found time do develop a more generic approach to add support for
"secondary" family codes. Could you try the appended patch? Of course,
you had to remove your patch first.
Kind regards
Jan
diff --git a/module/owlib/src/c/ow_2438.c b/module/owlib/src/c/ow_2438.c
index f14d5e0f..9e7efa33 100644
--- a/module/owlib/src/c/ow_2438.c
+++ b/module/owlib/src/c/ow_2438.c
@@ -171,6 +171,7 @@ static struct filetype DS2438[] = {
};
DeviceEntryExtended(26, DS2438, DEV_temp | DEV_volt, NO_GENERIC_READ, NO_GENERIC_WRITE);
+DeviceEntryExtendedSecondary(A6, DS2438, DEV_temp | DEV_volt, NO_GENERIC_READ, NO_GENERIC_WRITE);
#define _1W_WRITE_SCRATCHPAD 0x4E
#define _1W_READ_SCRATCHPAD 0xBE
diff --git a/module/owlib/src/c/ow_tree.c b/module/owlib/src/c/ow_tree.c
index ca013d75..5bbb9788 100644
--- a/module/owlib/src/c/ow_tree.c
+++ b/module/owlib/src/c/ow_tree.c
@@ -144,6 +144,7 @@ void DeviceSort(void)
Device2Tree( & d_DS2436, ePN_real);
Device2Tree( & d_DS2437, ePN_real);
Device2Tree( & d_DS2438, ePN_real);
+ Device2Tree( & d_DS2438_A6, ePN_real);
Device2Tree( & d_DS2450, ePN_real);
Device2Tree( & d_DS2502, ePN_real);
Device2Tree( & d_DS2505, ePN_real);
diff --git a/module/owlib/src/include/ow_2438.h b/module/owlib/src/include/ow_2438.h
index d03aef6b..cb3ab284 100644
--- a/module/owlib/src/include/ow_2438.h
+++ b/module/owlib/src/include/ow_2438.h
@@ -20,5 +20,6 @@
DeviceHeader(DS2437);
DeviceHeader(DS2438);
+DeviceHeader(DS2438_A6);
#endif
diff --git a/module/owlib/src/include/ow_device.h b/module/owlib/src/include/ow_device.h
index dd39f5c3..16a54fc9 100644
--- a/module/owlib/src/include/ow_device.h
+++ b/module/owlib/src/include/ow_device.h
@@ -93,6 +93,7 @@ struct device {
#define COUNT_OF_FILETYPES(filetype_array) ((int)(sizeof(filetype_array)/sizeof(struct filetype)))
#define DeviceEntryExtended( code , chip , flags, gread, gwrite ) struct device d_##chip = {#code,#chip,flags,COUNT_OF_FILETYPES(chip),chip,gread,gwrite}
+#define DeviceEntryExtendedSecondary( code , chip , flags, gread, gwrite ) struct device d_##chip##_##code = {#code,#chip,flags,COUNT_OF_FILETYPES(chip),chip,gread,gwrite}
#define DeviceEntry( code , chip, gread, gwrite ) DeviceEntryExtended( code, chip, 0, gread, gwrite )
--
Announcing the Oxford Dictionaries API! The API offers world-renowned
dictionary content that is easy and intuitive to access. Sign up for an
account today to start using our lexical data to power your apps and
projects. Get started today and enter our developer competition.
http://sdm.link/oxford___
Owfs-developers mailing list
Owfs-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/owfs-developers
Re: [Owfs-developers] libusb-1.0 required version
Am 05.03.2017 um 17:31 schrieb Johan Ström: > Unfortunately FreeBSD advertises it's libusb-1.0 layer (which have > libusb_strerror) as 1.0.9, so just bumping the requirement to 1.0.16 > will break build on FreeBSD. > > A quick but ugly solution would just be to #ifdef out the calls to > libusb_strerror. Other suggestions? > With an AC_ macro? Then, I don't see problems with that approach. We have numerous of those quirks in the sources already. 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
Re: [Owfs-developers] FTDI problem on pi
Am 03.03.2017 um 14:44 schrieb Colin Law: > > I too had expected to see messages about the usb device being > disconnected, or something similar, but there is nothing. > Okay. Then we are a bit lost. There is nothing we can do about this from OWFS. It's a USB problem. > I don't know whether it may be relevant but I have a udev rule to map > the device to /dev/linkUSB but there is no mention of this anywhere in > the log, as far as I can see. > Please try updating the kernel. Maybe there was a bug in ftdi_sio. 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
Re: [Owfs-developers] FTDI problem on pi
Am 02.03.2017 um 10:21 schrieb Colin Law: > Running a LinkUSB on a pi zero (Raspbian Jessie), with owserver > 3.1p4-1 from jessie testing, I very occasionally (every few weeks) see > in syslog > > Mar 1 22:10:50 pi004 kernel: [194834.694657] ftdi_sio ttyUSB0: failed > to get modem status: -110 > Mar 1 22:11:00 pi004 kernel: [194844.694679] ftdi_sio ttyUSB0: failed > to get modem status: -110 > Mar 1 22:11:06 pi004 kernel: [194850.694734] ftdi_sio ttyUSB0: > ftdi_set_termios FAILED to set databits/stopbits/parity > Mar 1 22:11:07 pi004 kernel: [194851.694724] ftdi_sio ttyUSB0: > ftdi_set_termios urb failed to set baudrate > Mar 1 22:11:12 pi004 kernel: [194856.694771] ftdi_sio ttyUSB0: urb > failed to clear flow control > Mar 1 22:11:22 pi004 kernel: [194866.694810] ftdi_sio ttyUSB0: failed > to get modem status: -110 > Mar 1 22:11:27 pi004 kernel: [194871.694819] ftdi_sio ttyUSB0: urb > failed to clear flow control > These are messages from the ftdi_sio USB driver. All this usually means the kernel simply cannot talk to the USB converter. Please check your kernel log for USB related messages. 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
Re: [Owfs-developers] New device driver - write function not being called
Am 16.02.2017 um 09:10 schrieb Alastair D'Silva:
>> -Original Message-
>> From: Alastair D'Silva [mailto:alast...@d-silva.org]
>> Sent: Thursday, 16 February 2017 7:02 PM
>> To: 'OWFS (One-wire file system) discussion and help' > develop...@lists.sourceforge.net>
>> Subject: Re: [Owfs-developers] New device driver - write function not
> being
>> called
>>
>> if (channel->fade_time >= (2^24)) {
>> return gbBAD;
>> }
>
> And there's the problem - that's not how you perform a power operation :)
>
You're welcome. __[^_^]__
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
Re: [Owfs-developers] New device driver - write function not being called
Am 15.02.2017 um 12:54 schrieb Alastair D'Silva: > > Command: > > echo "5,10,15,20,300" > /mnt/1wire/FE.DECEA5EDBEEF/channel0 > -bash: echo: write error: Invalid argument > Is your parse_rgbw_string() tolerant against \n? 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
Re: [Owfs-developers] Fine-tune timing against disappearing slaves
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 LinkUSB)?
> Again: I already disconnected branches "A" and "B" resulting in no slaves
> at all - with a single bus/branch.
>
> Hope somebody can help me out...
>
First, get rid of the star topology. Make a lobe with the help of the
additional wires in the Cat.5 cable. Replace the 12m NYM-J1.5 stub by
another lob
Re: [Owfs-developers] Hiding incompatible device variants
Am 11.02.2017 um 12:26 schrieb Matthias Urlichs: > On 11.02.2017 11:03, Jan Kandziora wrote: >>>> - I would only like to display files for the permitted channels >>>> >> This is a nice-to-have feature. Given the amount of complexity you have >> to add to support this, I would first walk away, then turn around, throw >> something heavy at it, then run away. > MoaT implements something like this. It's not that difficult / complex > IMHO. The key idea is to store the list of permitted channels on the > device. You need a command to retrieve that information anyway, so use > its result in owfs to limit the number of channels. > The latter is the difficult and complex part, because you have to inform all layers in the owfs setup about that change. There are no provisions for that. It had to be introduced from scratch, change a number of core components. All that for a feature which is just nice-to-have and not used by any other component but these two. 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
Re: [Owfs-developers] Hiding incompatible device variants
Am 11.02.2017 um 06:16 schrieb Alastair D'Silva: >> >> 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. > > Agreed, what I was thinking of was adding an init/term function and a struct > that represents a device instance (rather than a whole family of devices), > and adding a DeviceEntryExtended2 to set that up. That way, the driver can > query the device when inited, find out it's real type, and pass the > appropriate filetype table (probably from a separate .c file), so we don't > have the horrible overloading that exists in the DS2408 driver. > All the things owlib knows about a family is purely static. This is required for the correct interaction of owserver and the client, which may be an abitrary number of owserver layers. Changing that creates a horrible amount of complexity. Please don't do that. We can't possibly maintain it. I was glad I found a simple trick for the "external" sensors where the upper level owservers know nothing about lower level definitions but it's ugly, too. > What I'm stuck on is that none of the existing infrastructure seems to have > a concept of a device instance, only types of devices, and I'm not sure it > can be easily retrofitted. > You are right. OWFS does not store anything device-specific. It's stateless in that regard, which is a wise choice because devices may be in an arbitrary state depending whether they had been powered on or off. (The only exception is the cache, but that's a node->value store only for user programs which isn't queried for owlib's internal workings. You could query it but please don't do it. It would confuse unaware programmers.) If you'd need to distinguish device states, please store these on the device itself. If you need owlib to do a quick check for a state after a device command, include a 1-bit cycle to query that state before continuing. It's simple to implement and the robust way to do it. > Regardless of whether I have a second level of device types, I don't think I > can do without a struct to have device instance state. My use case is this: > - The implementation library allows an arbitrary number of channels > - I have a command which returns the number of channels > This is something the user program (on top of OWFS) has to know. So the user program is the place to store that information. > - I would only like to display files for the permitted channels > This is a nice-to-have feature. Given the amount of complexity you have to add to support this, I would first walk away, then turn around, throw something heavy at it, then run away. > - I would like to avoid querying the device every time a directory listing > is done > You are right. Doing so would be bad. > If you have any ideas, I'm all ears. Maybe querying the device for it's > state when necessary wouldn't be disastrous... > Include the number of R/G/B channels into the second/third etc byte of the ID so OWFS magically knows it just from looking at the ID. There are plenty of ID bits available and the number of devices ever manufactured sure wouldn't hit millions. > > That feels a lot like "640kb ought to be enough for everyone"... > It was. What went wrong wasn't that number but DOS living for too long though better solutions existed. You don't have that problem. You are not required to stick to an inferior system. Your slaves are just software. If a better solution comes up later, there's no problem to re-flash the devices. (Please include a way to self-program your devices via onewire.) > >> 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 >> inyour 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?) > Yes. > COUNT_CHANNELSreturns the number of available channels to the master > Please do that in a static manner. > SET_CHANNEL fades a channel to a specified RGBW value over a > specified time > GET_CHANNEL gets 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. > A much better design would allow the user program to push presets into the device RAM, and into a EEPROM backing store for each preset slot. Whether to store a RAM preset into EEPROM
Re: [Owfs-developers] Hiding incompatible device variants
Am 10.02.2017 um 22:04 schrieb Alastair D'Silva: > > 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). > 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). 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
Re: [Owfs-developers] Hiding incompatible device variants
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
Re: [Owfs-developers] Strange errors while building owfs-3.1p0
Am 08.02.2017 um 17:23 schrieb Gregg Levine: > Hello! > I'm getting this error sequence: > In file included from ow_dnssd.c:17:0: > ../../../owlib/src/include/ow.h:302:20: fatal error: libusb.h: No such > file or directory > compilation terminated. > Makefile:637: recipe for target 'ow_dnssd.o' failed > make[4]: *** [ow_dnssd.o] Error 1 > make[4]: Leaving directory '/usr/src/owfs/owfs-3.1p0/module/owshell/src/c' > Makefile:486: recipe for target 'all-recursive' failed > make[3]: *** [all-recursive] Error 1 > make[3]: Leaving directory '/usr/src/owfs/owfs-3.1p0/module/owshell/src' > Makefile:486: recipe for target 'all-recursive' failed > make[2]: *** [all-recursive] Error 1 > make[2]: Leaving directory '/usr/src/owfs/owfs-3.1p0/module/owshell' > Makefile:500: recipe for target 'all-recursive' failed > make[1]: *** [all-recursive] Error 1 > make[1]: Leaving directory '/usr/src/owfs/owfs-3.1p0/module' > Makefile:556: recipe for target 'all-recursive' failed > make: *** [all-recursive] Error 1 > root@masterskywalkwer:/usr/src/owfs/owfs-3.1p0# cd .. > root@masterskywalkwer:/usr/src/owfs# cd .. > root@masterskywalkwer:/usr/src# ls > > The computer confirms that the missing header isn't. > Could you try with 3.1p5 instead? It makes no sense to hunt bugs which are already fixed. 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
Re: [Owfs-developers] DS2450 CRC16 Checksum calculation
Am 05.02.2017 um 18:12 schrieb Ritchie: > Can you explain, how it work, that the result of the Checksume is > always 0xB001, if it is good. > Was genau ist dein Problem damit? Ich kann dir das Testen deines DS2450-Klons nicht abnehmen, meist sind es Kleinigkeiten, die einem einen CRC versauen. Der Startwert ist es zumindest schonmal nicht, aber unter Umständen ist das bei dir big endian oder sonstwie verknautscht. Mit freundlichem Gruß 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
Re: [Owfs-developers] DS2450 CRC16 Checksum calculation
Am 04.02.2017 um 20:42 schrieb Ritchie:
>
> Is this correct, that the checksum is started with the value of "address" ?
>
Please see module/owlib/src/c/ow_2450.c:392 -- OW_w_mem()
423: if ( CRC16seeded(buf, 3, offset + i) || (echo[0] != p[i]) ) {
So, it's indeed seeded with 8+1 == 9.
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
Re: [Owfs-developers] Function OW_w_mem in OW_set_resolution not entered
Am 26.01.2017 um 19:14 schrieb Ritchie:
>
> I also add debug code in the OW_w_mem() function to see the problem.
> Here the function :
>
> //write bytes[size] is now common for normal and eeprom
> static GOOD_OR_BAD OW_w_mem(BYTE * data, size_t size, off_t offset,
> struct parsedname * pn)
> {
> size_t remain = size ;
> off_t local_offset = 0 ;
> int retry=0; //retry at 32byte block level because it is sometime hard
> to have a scuccession of 16 successfull bloc writes
>
This is from owfs-code/module/owlib/src/ow_bae.c
You are editing the wrong file.
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
[Owfs-developers] owfs.org: Bandwidth Limit Exceeded
Hi, http://owfs.org is down, it shows Bandwidth Limit Exceeded The server is temporarily unable to service your request due to the site owner reaching his/her bandwidth limit. Please try again later. Temporary failure? Something more serious? 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
Re: [Owfs-developers] Custom 1-wire slave - need to send two bytes
Am 18.01.2017 um 18:12 schrieb Gabrijel Erman: > I can read the device without any problems but if I try to write > echo "22" > io_valve.ALL > To sort out problems with CRLF, please set up owserver and use the owwrite tool instead of echo. 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
Re: [Owfs-developers] Problem with owhttpd on a raspberry pi (owfs-3.0p2)
Am 18.01.2017 um 18:05 schrieb Ritchie: > Dear Colin, > > I gave up with jessie and reinstalled the complete system with wheezly. > > The system is running now with owfs3p2 self compiled. > > Can somebody give me a hint, at which point (module) I have to add some > debug code, to let the transmitted and recived bytes of the 1-wire bus > shown. > > I tried the switch --debug and --error_level but it does not show any > data transmission information, but a lot more information is shown. > Is this still about the homebrewn DS2450? I have already pointed you to the files in question. Let me quote myself: > Please look at the source code. module/owlib/src/c/ow_2450.c has most > of the relevant code for communicating with the chip. The other part > is in module/owlib/src/c/ow_memory.c > >> Wright now I am working on a Ds2450 Slave, based on a attiny45 and > I get the values "Error: Invalid argument" on "PIO.*" > > You have to follow the FS_r_PIO() function down to the place in the > code which is interesting to you. > You already wrote your problem is only about PIO.* but not PIO.0 for example. Is this correct? If yes, I seriously doubt the byte-level communication is the problem. 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
Re: [Owfs-developers] Problem with owhttpd on a raspberry pi (owfs-3.0p2)
Am 15.01.2017 um 16:31 schrieb Ritchie: > Dear Jan, > > please see here my /etc/owf.conf file > > [...] > It essentially reads --- !server: server = localhost:4304 server: device = /dev/ttyUSB0 server: port = 4304 http: port = 2121 ftp: port = 2120 --- Looks good when you have your host connects to onewire through a DS2480 connected to a USB-RS232 adapter. E.g. DS9097U, DS9481P or an old DS9097 behind a PL2303 based USB-RS232 converter. I ask because here --- # # USB device: DS9490 #server: device = /dev/ttyUSB0 server: device = /dev/ttyUSB0 --- there's something very very wrong with the comments. The DS9490 is based on the DS2490 chip, which isn't USB-RS232, but a plain USB device which needs another driver. Do you use a DS9490? Then you have to use the option --- server: usb --- instead of server: device = /dev/ttyUSB0 Kind regards Jan -- 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] Problem with owhttpd on a raspberry pi (owfs-3.0p2)
Am 15.01.2017 um 12:56 schrieb Ritchie: > the owserver is running now, but the owhttpd does not start. > Please, we need to see your /etc/owfs.conf. Kind regards Jan -- 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] owcapiexample parameters to pass
Am 13.01.2017 um 23:34 schrieb bdrmachine: > > Okay I give up. I thought there was a simple way to add parameters > to that code to learn how to use C. > Um, it was giving exactly *two* OWFS specific calls, which are pretty understandable. What's the problem? > I have code that work in python > but that is not what I like to use. This learning curve is taking > more time than I have. For some reason your code won't compile. > If you'd show me the log, I could tell you why. If you don't like python and have problems setting up you C compiling environment, why don't use one of the numerous *other* language bindings? Ow the owshell tools? Kind regards Jan -- 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] owcapiexample parameters to pass
Am 13.01.2017 um 18:23 schrieb bdrmachine:
> Wouldsomeone Please help me with the input string needed forthe
> owcapiexample program. I am trying to read my 18b20 sensors that
> areattached to my Raspberry Pi 3 using the I2C interface. I can
> readthem with my browser @ “localhost:2121”. The problem is I cannot
> get the example code that was loaded
> at(/usr/share/doc/libowfs-dev/examples/owcapi/C) to work. I need
> helpfiguring out what parameters to pass to ./owcapiexample ???
> Ihave spent countless hours at this. Please help. ThanksBrian
>
Please understand this very simple test program first:
=== Makefile
.PHONY: all clean
CFLAGS=-I /opt/owfs/include/
LDFLAGS=-L /opt/owfs/lib64/ -lowcapi
all: owcapitest
clean:
-rm *.o owcapitest
owcapitest: owcapitest.o
$(CC) $(LDFLAGS) -o $@ $^
=== owcapitest.c
#include
#include
#include
int main(int argc, char* argv[]) {
size_t rs;
char*buf;
ssize_t rss;
if ((rss = OW_init("-s localhost:4304")) < 0) {
perror("OW_init failed");
exit(EXIT_FAILURE);
}
if ((rs = OW_get("/uncached/10.AE9C54020800/temperature", &buf, &rs)) <
0) {
perror("OW_get failed");
exit(EXIT_FAILURE);
}
printf("%s\n",buf);
}
=
Kind regards
Jan
--
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] Problem with owserver on a raspberry pi (does not start)
Am 11.01.2017 um 18:38 schrieb Ritchie: > > /usr/src $ sudo /opt/owfs/bin/owserver --foreground --debug > --error_print=2 --error_level=9 -c /etc/owfs.conf > We need /etc/owfs.conf and a list which owfs services you run in parallel to help you. Kind regards Jan -- 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] 85 degree reading means error, readout timing, error should be filtered
Am 09.01.2017 um 16:07 schrieb fl...@franke-prem.de: > gelaufen. Da diese Abfrage nun sehr häufig stattfindet, gibt es da mit dem > wandeln der Werte (Speziell da ich hier auch noch eine Mischbestückung > zwischen Parasite-Power und External-Power betreibe) immer mit Problemen > behaftet (Sensorwerte werden oft nicht gelesen (Kein Wert und nicht 85°)). > Es ergibt keinen Sinn, häufiger als einmal pro Sekunde die Messung anzustoßen. So schnell sind die DS18B20 nicht. Und schneller ändern sich die Temperaturen auch nicht, dafür hat das Gehäuse zuviel Wärmekapazität. Einfach die Abfragehäufigkeit runterdrehen. > Allerdings greift vermutlich die Abfrage über OWLIB so tiefgreifend in das > Ganze System ein, dass eben keine neue Wandlung der Messwerte getriggert > und somit der Wert in latesttemp immer auf den Ursprungswert bleibt. > /uncached/.../latesttemp liest einfach nur das Scratchpad des Chips aus. Es wird dadurch niemals eine neue Messung getriggert. Das ist genau der Sinn der Sache. Wenn du das Triggern der Messungen vom Auslesen trennen willst, musst du /simultaneous/temperature zum Triggern benutzen. Geht aber nur wenn alle Sensoren an einem Bus Strom per Vdd beziehen statt per DQ. Mit freundlichem Gruß Jan -- 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] 85 degree reading means error, readout timing, error should be filtered
Am 09.01.2017 um 09:33 schrieb fl...@franke-prem.de: > Hello, > sorry for the confusion. > The reading by me has nothing to do with the 85 degree values. > It was only the hint, when readout values with the OWLIB Connection, > that then the values by reading with only "latesttemp" will be not updated. > Erklärs mir bitte auf Deutsch. Vielleicht verstehe ich das Problem dann. Mit freundlichem Gruß 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
