You can subscribe to this list here.
2003 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
(64) |
Sep
(106) |
Oct
(103) |
Nov
(85) |
Dec
(28) |
---|---|---|---|---|---|---|---|---|---|---|---|---|
2004 |
Jan
(41) |
Feb
(87) |
Mar
(54) |
Apr
(23) |
May
(54) |
Jun
(86) |
Jul
(56) |
Aug
(35) |
Sep
(123) |
Oct
(98) |
Nov
(61) |
Dec
(83) |
2005 |
Jan
(192) |
Feb
(231) |
Mar
(114) |
Apr
(154) |
May
(45) |
Jun
(171) |
Jul
(123) |
Aug
(83) |
Sep
(95) |
Oct
(123) |
Nov
(56) |
Dec
(70) |
2006 |
Jan
(73) |
Feb
(84) |
Mar
(132) |
Apr
(186) |
May
(201) |
Jun
(121) |
Jul
(92) |
Aug
(108) |
Sep
(147) |
Oct
(156) |
Nov
(167) |
Dec
(279) |
2007 |
Jan
(159) |
Feb
(230) |
Mar
(61) |
Apr
(54) |
May
(89) |
Jun
(79) |
Jul
(57) |
Aug
(146) |
Sep
(123) |
Oct
(82) |
Nov
(56) |
Dec
(124) |
2008 |
Jan
(79) |
Feb
(64) |
Mar
(51) |
Apr
(119) |
May
(47) |
Jun
(37) |
Jul
(23) |
Aug
(44) |
Sep
(43) |
Oct
(53) |
Nov
(115) |
Dec
(93) |
2009 |
Jan
(85) |
Feb
(106) |
Mar
(56) |
Apr
(66) |
May
(114) |
Jun
(58) |
Jul
(120) |
Aug
(107) |
Sep
(17) |
Oct
(87) |
Nov
(36) |
Dec
(62) |
2010 |
Jan
(92) |
Feb
(121) |
Mar
(178) |
Apr
(115) |
May
(122) |
Jun
(33) |
Jul
(64) |
Aug
(168) |
Sep
(83) |
Oct
(67) |
Nov
(94) |
Dec
(98) |
2011 |
Jan
(240) |
Feb
(110) |
Mar
(183) |
Apr
(68) |
May
(47) |
Jun
(77) |
Jul
(72) |
Aug
(155) |
Sep
(93) |
Oct
(150) |
Nov
(110) |
Dec
(88) |
2012 |
Jan
(213) |
Feb
(148) |
Mar
(107) |
Apr
(105) |
May
(136) |
Jun
(94) |
Jul
(76) |
Aug
(29) |
Sep
(64) |
Oct
(60) |
Nov
(124) |
Dec
(71) |
2013 |
Jan
(79) |
Feb
(87) |
Mar
(87) |
Apr
(61) |
May
(100) |
Jun
(123) |
Jul
(106) |
Aug
(17) |
Sep
(44) |
Oct
(55) |
Nov
(40) |
Dec
(98) |
2014 |
Jan
(125) |
Feb
(160) |
Mar
(112) |
Apr
(61) |
May
(28) |
Jun
(50) |
Jul
(35) |
Aug
(49) |
Sep
(71) |
Oct
(115) |
Nov
(40) |
Dec
(48) |
2015 |
Jan
(51) |
Feb
(105) |
Mar
(58) |
Apr
(80) |
May
(69) |
Jun
(51) |
Jul
(24) |
Aug
(23) |
Sep
(62) |
Oct
(62) |
Nov
(201) |
Dec
(33) |
2016 |
Jan
(79) |
Feb
(83) |
Mar
(118) |
Apr
(40) |
May
(43) |
Jun
(113) |
Jul
(83) |
Aug
(54) |
Sep
(119) |
Oct
(79) |
Nov
(85) |
Dec
(60) |
2017 |
Jan
(65) |
Feb
(34) |
Mar
(25) |
Apr
(14) |
May
(10) |
Jun
|
Jul
(28) |
Aug
(49) |
Sep
(20) |
Oct
(4) |
Nov
(23) |
Dec
(28) |
2018 |
Jan
(14) |
Feb
|
Mar
(19) |
Apr
(8) |
May
|
Jun
|
Jul
(5) |
Aug
(15) |
Sep
(13) |
Oct
(17) |
Nov
(7) |
Dec
(3) |
2019 |
Jan
(2) |
Feb
(25) |
Mar
(16) |
Apr
(20) |
May
(34) |
Jun
(8) |
Jul
(26) |
Aug
(19) |
Sep
(17) |
Oct
(21) |
Nov
(3) |
Dec
|
2020 |
Jan
|
Feb
|
Mar
(9) |
Apr
(4) |
May
(14) |
Jun
(7) |
Jul
|
Aug
(58) |
Sep
(4) |
Oct
(16) |
Nov
|
Dec
|
2021 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
(2) |
2022 |
Jan
|
Feb
|
Mar
(2) |
Apr
|
May
(3) |
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
2023 |
Jan
|
Feb
|
Mar
|
Apr
(1) |
May
|
Jun
|
Jul
(1) |
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
2024 |
Jan
|
Feb
|
Mar
|
Apr
(3) |
May
(2) |
Jun
|
Jul
(3) |
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
2025 |
Jan
|
Feb
(2) |
Mar
(1) |
Apr
(3) |
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
From: Nico B. <ni...@cu...> - 2020-10-24 08:19:43
|
I'm using a raspberry zero with a ds2482-100 board. OWFS software is the one from the debian repo it's self 3.1p5. (debian 9) I's running stable for a couple of months now. Pi zero is in a greenhouse who has a ethernet connection (usb to ethernet) with ds2408 and ds2438 (humidity) https://fstab.nl/Raspberry-Pi-zero Nico han...@at... wrote: > Hello! > I've just downloaded and built the latest release of OWFS on the Raspberry > Pi device that I normally use for first tries of the OWFS system. All I saw > while doing so were the usual wonky warnings from the Debian based build > tools on the device. I haven't tried building this release on Slackware as I > do not have a 64 bit 14.2 system available so we can take this report as > factual for the Pi device. > > Hardware is a DS9097U device using an FTDI FT232 and MAX232A based adapter, > they are talking to a pair of DS2406 devices. > > Further studies will be on a Pi3 and a Pi Zero W Or a PI Zero in gadget zero > Ethernet mode talking to a regular Pi Zero. > > 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.) > > 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? > ----- > Gregg Levine han...@at... > "They were in the wrong place at the wrong time. Naturally they became > heroes." Princess Leia Organa of Alderann Senator > > > > > _______________________________________________ > Owfs-developers mailing list > Owf...@li... > https://lists.sourceforge.net/lists/listinfo/owfs-developers > -- 0623391101 |
From: <han...@at...> - 2020-10-24 04:32:01
|
Hello! I've just downloaded and built the latest release of OWFS on the Raspberry Pi device that I normally use for first tries of the OWFS system. All I saw while doing so were the usual wonky warnings from the Debian based build tools on the device. I haven't tried building this release on Slackware as I do not have a 64 bit 14.2 system available so we can take this report as factual for the Pi device. Hardware is a DS9097U device using an FTDI FT232 and MAX232A based adapter, they are talking to a pair of DS2406 devices. Further studies will be on a Pi3 and a Pi Zero W Or a PI Zero in gadget zero Ethernet mode talking to a regular Pi Zero. 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.) 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? ----- Gregg Levine han...@at... "They were in the wrong place at the wrong time. Naturally they became heroes." Princess Leia Organa of Alderann Senator |
From: Martin P. <Mar...@GM...> - 2020-10-14 15:33:16
|
Maestro Stefano, questo sembra bellissimo! :-) On 14.10.20 16:13, Stefano Miccoli via Owfs-developers wrote: > A more succinct way would be: > > str(x).encode() > > In fact the outer call to ‘bytes’ in 'bytes(str.encode(str(x)))' is a > no-op, and python strings are objects which have an ‘encode' method, > so no need call the class method ’str.encode’. > > Another possible way is > > f"{x:d}".encode() > > or > > "{:d}".format(x).encode() > > which is more “defensive”, in the sense that the conversion fails if x > is not an integer. In fact “str(x)” is defined for almost any > imaginable object in python, and could return anything. Therefore it > is better to be a little more verbose, and be explicit on the fact > that here we are interested in a decimal integer. > > Another variant, in which we accept a float value could be > > f"{round(x):d}".encode() > > or > > f"{x:.0f}" > > but possibilities are endless. > > Bye and thank you for sharing. > > > Stefano > > >> On 14 Oct 2020, at 15:08, Mick Sulley <mi...@su... >> <mailto:mi...@su...>> wrote: >> >> I had a bit of trouble with this and thought it worth sharing the >> solution. >> >> With Python2 and pyownet I could use >> >> owp.write('/settings/timeout/directory', 60) >> >> but with Python3 that throws an error, TypeError: 'data' argument >> must be binary. I can use >> >> owp.write('/settings/timeout/directory', b'60') >> >> but if I want to use a variable for the data the format which works is - >> >> x = 60 >> owp.write('/settings/timeout/directory', bytes(str.encode(str(x)))) >> >> There may be other ways to do it but that works for me. >> >> Mick >> >> >> >> _______________________________________________ >> Owfs-developers mailing list >> Owf...@li... >> <mailto:Owf...@li...> >> https://lists.sourceforge.net/lists/listinfo/owfs-developers > > > > _______________________________________________ > Owfs-developers mailing list > Owf...@li... > https://lists.sourceforge.net/lists/listinfo/owfs-developers |
From: Mick S. <mi...@su...> - 2020-10-14 14:51:10
|
Thanks Stefano, that looks much better. On 14/10/2020 15:13, Stefano Miccoli via Owfs-developers wrote: > A more succinct way would be: > > str(x).encode() > > In fact the outer call to ‘bytes’ in 'bytes(str.encode(str(x)))' is a > no-op, and python strings are objects which have an ‘encode' method, > so no need call the class method ’str.encode’. > > Another possible way is > > f"{x:d}".encode() > > or > > "{:d}".format(x).encode() > > which is more “defensive”, in the sense that the conversion fails if x > is not an integer. In fact “str(x)” is defined for almost any > imaginable object in python, and could return anything. Therefore it > is better to be a little more verbose, and be explicit on the fact > that here we are interested in a decimal integer. > > Another variant, in which we accept a float value could be > > f"{round(x):d}".encode() > > or > > f"{x:.0f}" > > but possibilities are endless. > > Bye and thank you for sharing. > > > Stefano > > >> On 14 Oct 2020, at 15:08, Mick Sulley <mi...@su... >> <mailto:mi...@su...>> wrote: >> >> I had a bit of trouble with this and thought it worth sharing the >> solution. >> >> With Python2 and pyownet I could use >> >> owp.write('/settings/timeout/directory', 60) >> >> but with Python3 that throws an error, TypeError: 'data' argument >> must be binary. I can use >> >> owp.write('/settings/timeout/directory', b'60') >> >> but if I want to use a variable for the data the format which works is - >> >> x = 60 >> owp.write('/settings/timeout/directory', bytes(str.encode(str(x)))) >> >> There may be other ways to do it but that works for me. >> >> Mick >> >> >> >> _______________________________________________ >> Owfs-developers mailing list >> Owf...@li... >> <mailto:Owf...@li...> >> https://lists.sourceforge.net/lists/listinfo/owfs-developers > > > > _______________________________________________ > Owfs-developers mailing list > Owf...@li... > https://lists.sourceforge.net/lists/listinfo/owfs-developers |
From: Stefano M. <mo...@ic...> - 2020-10-14 14:13:56
|
A more succinct way would be: str(x).encode() In fact the outer call to ‘bytes’ in 'bytes(str.encode(str(x)))' is a no-op, and python strings are objects which have an ‘encode' method, so no need call the class method ’str.encode’. Another possible way is f"{x:d}".encode() or "{:d}".format(x).encode() which is more “defensive”, in the sense that the conversion fails if x is not an integer. In fact “str(x)” is defined for almost any imaginable object in python, and could return anything. Therefore it is better to be a little more verbose, and be explicit on the fact that here we are interested in a decimal integer. Another variant, in which we accept a float value could be f"{round(x):d}".encode() or f"{x:.0f}" but possibilities are endless. Bye and thank you for sharing. Stefano > On 14 Oct 2020, at 15:08, Mick Sulley <mi...@su...> wrote: > > I had a bit of trouble with this and thought it worth sharing the solution. > > With Python2 and pyownet I could use > > owp.write('/settings/timeout/directory', 60) > > but with Python3 that throws an error, TypeError: 'data' argument must be binary. I can use > > owp.write('/settings/timeout/directory', b'60') > > but if I want to use a variable for the data the format which works is - > > x = 60 > owp.write('/settings/timeout/directory', bytes(str.encode(str(x)))) > > There may be other ways to do it but that works for me. > > Mick > > > > _______________________________________________ > Owfs-developers mailing list > Owf...@li... > https://lists.sourceforge.net/lists/listinfo/owfs-developers |
From: Mick S. <mi...@su...> - 2020-10-14 13:08:55
|
I had a bit of trouble with this and thought it worth sharing the solution. With Python2 and pyownet I could use owp.write('/settings/timeout/directory', 60) but with Python3 that throws an error, TypeError: 'data' argument must be binary. I can use owp.write('/settings/timeout/directory', b'60') but if I want to use a variable for the data the format which works is - x = 60 owp.write('/settings/timeout/directory', bytes(str.encode(str(x)))) There may be other ways to do it but that works for me. Mick |
From: Mick S. <mi...@su...> - 2020-10-08 19:00:34
|
Just looked at it again and all sensors are now reading correctly, so I am wondering if there was a bad connection somewhere. As they are all working I will try to see if I can recreate the problem, but not sure I will be able to. I'll get back to you if I discover anything further. Thanks Mick On 08/10/2020 19:47, Mick Sulley wrote: > This is a test setup, all sensors are in a breadboard on the bench, > power is from a Meanwell unit set to 5.1 volts, which is what I > measure at the sensors. So I am pretty confident it is not a wiring > or power supply problem. > > Is there any way to determine if the simultaneous command is getting > to all of the chips? > > I am pretty confident that if I power cycle it all the problem will go > away and I won't be able to recreate it, so I am trying to investigate > as much as I can while the situation exists. > > Thanks > > Mick > > On 08/10/2020 17:27, Jan Kandziora wrote: >> 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 >> Owf...@li... >> https://lists.sourceforge.net/lists/listinfo/owfs-developers > > > _______________________________________________ > Owfs-developers mailing list > Owf...@li... > https://lists.sourceforge.net/lists/listinfo/owfs-developers |
From: Mick S. <mi...@su...> - 2020-10-08 18:47:22
|
This is a test setup, all sensors are in a breadboard on the bench, power is from a Meanwell unit set to 5.1 volts, which is what I measure at the sensors. So I am pretty confident it is not a wiring or power supply problem. Is there any way to determine if the simultaneous command is getting to all of the chips? I am pretty confident that if I power cycle it all the problem will go away and I won't be able to recreate it, so I am trying to investigate as much as I can while the situation exists. Thanks Mick On 08/10/2020 17:27, Jan Kandziora wrote: > 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 > Owf...@li... > https://lists.sourceforge.net/lists/listinfo/owfs-developers |
From: Jan K. <jj...@gm...> - 2020-10-08 16:28:00
|
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 |
From: Mick S. <mi...@su...> - 2020-10-08 13:08:17
|
On 08/10/2020 12:26, Jan Kandziora wrote: > 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/<id>/latesttemp reads the contents of the temperature > register from the chip. > > It never triggers a temperature conversion. 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! pi@pi4b:~ $ owread /DHW_Top/latesttemp 85pi@pi4b:~ $ owread /DHW_Top/latesttemp 85 pi@pi4b:~ $ owwrite /simultaneous/temperature 1 pi@pi4b:~ $ owread /DHW_Top/latesttemp 85pi@pi4b:~ $ owread /DHW_Top/latesttemp 85pi@pi4b:~ $ pi@pi4b:~ $ owread /DHW_Top/temperature12 13.5625pi@pi4b:~ $ owread /DHW_Top/latesttemp 13.5625pi@pi4b:~ $ pi@pi4b:~ $ 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 > > 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 > Owf...@li... > https://lists.sourceforge.net/lists/listinfo/owfs-developers |
From: Jan K. <jj...@gm...> - 2020-10-08 11:27:14
|
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/<id>/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 |
From: Henrik Ö. <tr...@gm...> - 2020-10-08 09:51:01
|
Nice setup Nico! And a useful watchdog for the DS2408, thanks for sharing the schematics! I'm still struggling with my implementation, resetting the microcontroller will get the DS2480 out of sync somehow, and the only way to get back on track is to powercycle the beast. I have tried to send a master control reset to the DS2480, but it doesn't seem to work, the chip is notoriously hard to reset. So I threw the circuit away and have ordered a new PCB based upon the DS2484(I2C), hopefully it works better than the serial DS2480, at least it requires less external components and a reset is only a I2C-instruction away. :-) Crossing my fingers that this one works better... // Henrik Den tors 8 okt. 2020 kl 10:30 skrev Nico Bouthoorn <ni...@cu...>: > Also comment on what Mick mentioned about power supply problems. I 've > made a kind of ups. 5V 3A regulator IC, driven by a normal switched PS > 12V and a 12V battery, divided bij Schottky diodes. > But i'm using a BeageBone Black, a uptime in this way of 2 years is not a > problem. > i'm using also a watchdog circuit behind the DS2408 for temperature > runaways. > > I did just a refresh/rework of my 1-wire project website: https://fstab.nl > I'm controlling my greenhouse(s) in this way > > Nico > > Henrik Östman wrote: > > Hi! > I have been following the OWFS project for 20+ years and I really think > it's a marvelous piece of software. It's been run on a Raspberry Pi for > many years now to control the heating in our house. > However lately my Raspberry Pi has been more and more unstable, > overheating problems, diskfailure, hanging, owserver unexpectedly going > down and soo forth. It really got me thinking if my setup is the best > approche, my wife and kids should not have to be Unix admins and be able to > SSH to my server and restart the Docker container with Owserver just to not > freeze when I'm out on a business trip! So in a true Unix spirit I'm > splitting my Home automation system appart into well defined pieces that > "do one thing and do it well". > My house is heated by water-based floor heating, and there are three floor > heating control centers, with relays opening and closing the water-valves. > Each control center has a DS2408 controlling the relayes of 3-5 valves. A > made a small circuit board with a commonly used Arduino compatible > microcontroller that reads the temperature in the rooms using DS1820 > sensors, then instructs the DS2408 to open/close the right valve. There is > one circuit board for each control center, so if one goes down only a few > rooms get affected. There is a reset-button on each circuit board that > could be used to restart it for whatever reason, and since there are no > filesystems mounted there is no problem with corruption in case of power > loss, and restarting only takes a second. The Raspberry Pi is now only used > for plotting graphs, MQTT and other home automation tasks. > > Since I no longer use Owserver in my setup, I understand that it may be > inappropriate to ask for help within this forum. But I know that there are > some 10+ years skilled developers here with deep knowledge of 1-Wire > systems so I'm still going to pop the questions, maybe you could direct me > to a more suitable forum where we could continue the discussion? > > The problem I'm having is with the DS2408 devices, I only seem to be able > to communicate with them using the SKIP-ROM command, if I try to address > them individually then I only get garbage and errors back. The same code > works great when addressing DS2423 and DS18(B/S)20 devices, so I think the > code itself should work. Maybe I have missed something when communicating > or initializing the DS2408? I tried to read all the Maxim specs, and it > feels like I'm doing everything right. During startup I begin with > initializing the DS2408 and set the pins to output and to a known state. > > void ds2408_reset(DS2480B &ds, onewireNode &node) { > ESP_LOGD(TAG, "Reset DS2408, id: %s.", node.idStr.c_str()); > if (existTestMode(ds, node)) { > // Configure RSTZ as STRB output. > //ds.select(node.id); // reselect last selected device. > ds.write(SKIP_ROM); // HACK, this select all devices on the bus, but we > should select only this single device. Though I get CRC-errors using above > line. > ds.write(0xCC); // Issue Write Conditional Search Register command > ds.write(0x8D); // TA1, target address = 8Dh > ds.write(0x00); // TA2, target address = 008Dh > ds.write(0x04); // Write byte to Control/Status Register, RSTZ as STRB > output > // Verify configuration setting > if (!ds.reset()) { > ESP_LOGW(TAG, "Reset DS2408 failed after non-success configure RSTZ as > STRB."); > node.errors++; > return; > } > ds.write(RESUME); // reselect last selected device. > ds.write(0xF0); // Issue Read PIO Registers command > ds.write(0x8D); // TA1, target address = 8Dh > ds.write(0x00); // TA2, target address = 008Dh > auto status = ds.read(); // Read Control/Status Register and verify > ESP_LOGD(TAG, "DS2408 verify configuration setting: %s.", String(status, > HEX)); > // Set all relays off. > setState(ds, node, B11111111); > } else { > ESP_LOGW(TAG, "Reset DS2408 failed for id: %s.", node.idStr.c_str()); > } > } > > /** > * Exit test-mode. > * "The DS2408 is sensitive to the power-on slew rate and can inadvertently > power up with a test mode > * feature enabled. When this occurs, the P0 port does not respond to the > Channel Access Write command." > * @return 0=failed, 1=success > */ > bool existTestMode(DS2480B &ds, onewireNode &node) { > // RST PD 96h <64-bit DS2408 ROM Code> 3Ch RST PD > if (ds.reset()) { // onewire initialization sequence, to be followed by > other commands > ds.write(0x96); > for (uint8_t i = 0; i < 8; i++) { > ds.write(node.id[i]); > } > ds.write(0x3C); > if (ds.reset()) { > return 1; > } > } > return 0; > } > > int16_t setState(DS2480B &ds, onewireNode &node, uint8_t state) { > if (node.id[0] != DS2408) { > ESP_LOGW(TAG, "Device is not a DS2408!"); > return -1; > } > if (ds.reset()) { // onewire initialization sequence, to be followed by > other commands > ESP_LOGD(TAG, "Set DS2408 state to: %s.", String(state, BIN)); > uint8_t retries = MAX_CONSECUTIVE_RETRIES; > //ds.select(node.id); // issues onewire "MATCH ROM" address which selects > a SPECIFIC (only one) 1-Wire device > ds.write(SKIP_ROM); // HACK, this select all devices on the bus, but we > should select only this single device. Though I get CRC-errors using above > line. > do { > ds.write(0x5A); // Issue Channel-access Write command > ds.write(state); // Write byte to PIO > ds.write(~state); // Write inverted byte to PIO > auto status = ds.read(); // Read for verification (AAh = success) > auto newState = ds.read(); // DS2408 samples PIO pin status > if (status == 0xAA) { // AAh = success > ESP_LOGD(TAG, "DS2408 current state: %s.", String(newState, BIN)); > node.success++; > return newState; > } else { > node.errors++; > ESP_LOGW(TAG, "DS2408 setState failed, trying again..."); > if (ds.reset()) { > ds.write(RESUME); // reselect last selected device. > } else { > ESP_LOGW(TAG, "Reset DS2408 failed after non-success setState."); > node.errors++; > return -1; > } > } > } while (--retries); > return -1; > } else { > ESP_LOGW(TAG, "Reset DS2408 failed."); > node.errors++; > return -1; > } > } > > When using "ds.select(node.id);" it does not work, with > "ds.write(SKIP_ROM) it works better, the question is why? And if it does > matter, the circuit-board is using a DS2480 to communicate with the other > devices. > > Any help or suggestions would be more than welcome! > Thanks! > > // Henrik > > > > > _______________________________________________ > Owfs-developers mailing lis...@li...https://lists.sourceforge.net/lists/listinfo/owfs-developers > > > |
From: Nico B. <ni...@cu...> - 2020-10-08 08:49:00
|
Also comment on what Mick mentioned about power supply problems. I 've made a kind of ups. 5V 3A regulator IC, driven by a normal switched PS 12V and a 12V battery, divided bij Schottky diodes. But i'm using a BeageBone Black, a uptime in this way of 2 years is not a problem. i'm using also a watchdog circuit behind the DS2408 for temperature runaways. I did just a refresh/rework of my 1-wire project website: https://fstab.nl I'm controlling my greenhouse(s) in this way Nico Henrik Östman wrote: > Hi! > I have been following the OWFS project for 20+ years and I really > think it's a marvelous piece of software. It's been run on a Raspberry > Pi for many years now to control the heating in our house. > However lately my Raspberry Pi has been more and more unstable, > overheating problems, diskfailure, hanging, owserver unexpectedly > going down and soo forth. It really got me thinking if my setup is the > best approche, my wife and kids should not have to be Unix admins and > be able to SSH to my server and restart the Docker container with > Owserver just to not freeze when I'm out on a business trip! So in a > true Unix spirit I'm splitting my Home automation system appart into > well defined pieces that "do one thing and do it well". > My house is heated by water-based floor heating, and there are three > floor heating control centers, with relays opening and closing the > water-valves. Each control center has a DS2408 controlling the relayes > of 3-5 valves. A made a small circuit board with a commonly used > Arduino compatible microcontroller that reads the temperature in the > rooms using DS1820 sensors, then instructs the DS2408 to open/close > the right valve. There is one circuit board for each control center, > so if one goes down only a few rooms get affected. There is a > reset-button on each circuit board that could be used to restart it > for whatever reason, and since there are no filesystems mounted there > is no problem with corruption in case of power loss, and restarting > only takes a second. The Raspberry Pi is now only used for plotting > graphs, MQTT and other home automation tasks. > > Since I no longer use Owserver in my setup, I understand that it may > be inappropriate to ask for help within this forum. But I know that > there are some 10+ years skilled developers here with deep knowledge > of 1-Wire systems so I'm still going to pop the questions, maybe you > could direct me to a more suitable forum where we could continue the > discussion? > > The problem I'm having is with the DS2408 devices, I only seem to be > able to communicate with them using the SKIP-ROM command, if I try to > address them individually then I only get garbage and errors back. The > same code works great when addressing DS2423 and DS18(B/S)20 devices, > so I think the code itself should work. Maybe I have missed something > when communicating or initializing the DS2408? I tried to read all the > Maxim specs, and it feels like I'm doing everything right. During > startup I begin with initializing the DS2408 and set the pins to > output and to a known state. > > void ds2408_reset(DS2480B &ds, onewireNode &node) { > ESP_LOGD(TAG, "Reset DS2408, id: %s.", node.idStr.c_str()); > if (existTestMode(ds, node)) { > // Configure RSTZ as STRB output. > //ds.select(node.id <http://node.id>); // reselect last selected device. > ds.write(SKIP_ROM);// HACK, this select all devices on the bus, but we > should select only this single device. Though I get CRC-errors using > above line. > ds.write(0xCC);// Issue Write Conditional Search Register command > ds.write(0x8D);// TA1, target address = 8Dh > ds.write(0x00);// TA2, target address = 008Dh > ds.write(0x04);// Write byte to Control/Status Register, RSTZ as STRB > output > // Verify configuration setting > if (!ds.reset()) { > ESP_LOGW(TAG, "Reset DS2408 failed after non-success configure RSTZ as > STRB."); > node.errors++; > return; > } > ds.write(RESUME);// reselect last selected device. > ds.write(0xF0);// Issue Read PIO Registers command > ds.write(0x8D);// TA1, target address = 8Dh > ds.write(0x00);// TA2, target address = 008Dh > auto status = ds.read();// Read Control/Status Register and verify > ESP_LOGD(TAG, "DS2408 verify configuration setting: %s.", > String(status, HEX)); > // Set all relays off. > setState(ds, node, B11111111); > } else { > ESP_LOGW(TAG, "Reset DS2408 failed for id: %s.", node.idStr.c_str()); > } > } > > /** > * Exit test-mode. > * "The DS2408 is sensitive to the power-on slew rate and can > inadvertently power up with a test mode > * feature enabled. When this occurs, the P0 port does not respond to > the Channel Access Write command." > * @return0=failed, 1=success > */ > bool existTestMode(DS2480B &ds, onewireNode &node) { > // RST PD 96h <64-bit DS2408 ROM Code> 3Ch RST PD > if (ds.reset()) {// onewire initialization sequence, to be followed by > other commands > ds.write(0x96); > for (uint8_t i = 0; i < 8; i++) { > ds.write(node.id[i]); > } > ds.write(0x3C); > if (ds.reset()) { > return 1; > } > } > return 0; > } > > int16_t setState(DS2480B &ds, onewireNode &node, uint8_t state) { > if (node.id[0] != DS2408) { > ESP_LOGW(TAG, "Device is not a DS2408!"); > return -1; > } > if (ds.reset()) {// onewire initialization sequence, to be followed by > other commands > ESP_LOGD(TAG, "Set DS2408 state to: %s.", String(state, BIN)); > uint8_t retries = MAX_CONSECUTIVE_RETRIES; > //ds.select(node.id <http://node.id>); // issues onewire "MATCH ROM" > address which selects a SPECIFIC (only one) 1-Wire device > ds.write(SKIP_ROM);// HACK, this select all devices on the bus, but we > should select only this single device. Though I get CRC-errors using > above line. > do { > ds.write(0x5A);// Issue Channel-access Write command > ds.write(state);// Write byte to PIO > ds.write(~state);// Write inverted byte to PIO > auto status = ds.read();// Read for verification (AAh = success) > auto newState = ds.read();// DS2408 samples PIO pin status > if (status == 0xAA) {// AAh = success > ESP_LOGD(TAG, "DS2408 current state: %s.", String(newState, BIN)); > node.success++; > return newState; > } else { > node.errors++; > ESP_LOGW(TAG, "DS2408 setState failed, trying again..."); > if (ds.reset()) { > ds.write(RESUME);// reselect last selected device. > } else { > ESP_LOGW(TAG, "Reset DS2408 failed after non-success setState."); > node.errors++; > return -1; > } > } > } while (--retries); > return -1; > } else { > ESP_LOGW(TAG, "Reset DS2408 failed."); > node.errors++; > return -1; > } > } > > When using "ds.select(node.id <http://node.id>);" it does not work, > with "ds.write(SKIP_ROM) it works better, the question is why? And if > it does matter, the circuit-board is using a DS2480 to communicate > with the other devices. > > Any help or suggestions would be more than welcome! > Thanks! > > // Henrik > > > > > _______________________________________________ > Owfs-developers mailing list > Owf...@li... > https://lists.sourceforge.net/lists/listinfo/owfs-developers |
From: Mick S. <mi...@su...> - 2020-10-07 22:31:37
|
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. However if I run owread /uncached/DHW_Mid_Btm/temperature12 it returns 13.4375. If I then owread /uncached/DHW_Mid_Btm/latesttemp it also returns 13.4375 and after that it seems to work as expected. So it seems that reading temperature12 resets it. I can't reproduce this, as I say, once a temperature12 read resets it it works fine. 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. Thanks Mick |
From: Henrik Ö. <tr...@gm...> - 2020-09-16 22:11:14
|
Thanks for your suggestions Mick! And interesting to read about how you tackle the lookups. I also use a quality Meanwell 5 volt power supply that is connected to a 230v UPS, and the Raspberry Pi is equipped with a PiJuice Hat( https://uk.pi-supply.com/products/pijuice-standard), so there are two layers of uninterruptible power supplies in the system. To reduce wear on the Flash-card it's only used during booting, the rest of the filesystem is on an external USB-harddrive. All 1-Wire devices are powered, no parasite-mode here, but I'm using telephone cables to connect the devices and not Cat5-cables. I used to have a similar DS2482-800 card as you described (*AbioWire, *https://axiris.eu/en/index.php/1-wire/abiowire) on top of my Raspberry, all the channels help to keep the number of devices per channel down. However that's in the past, instead of having "all eggs in the same basket" and where you need SSH knowledge to restart the "basket" I now try to be more microservice with small autonomous 1-Wire controllers that can be restarted by my wife with a button pressed. More suggestions about my code and lowlevel pitfalls of 1-Wire devices are welcome! Are there any alternatives to these traditional mailing lists? Like Discord-group? // Henrik Den mån 14 sep. 2020 kl 12:45 skrev Mick Sulley <mi...@su...>: > Hi Henrik, > > I can't answer you questions I'm afraid but I would add a few comments. > > I have been using Pi's since they were first released and yes, I have had > a few problems as well. The most common problem I have found is power > supply, always worth using a decent one, I use Meanwell units in critical > situations. Second on the list is SD cards, I have had loads of failures > there and I generally use hard drives recovered from old laptops instead of > SD cards. > > The biggest problem I have had with 1-wire is that it occasionally locks > up. I use a Sheepwalk RPi3 adapter to give me 8 channels, that uses the > DS2482-800 chip. When a lock-up occurs it needs a power cycle of 1-wire, > reboot does not reset it. The solution I use for that is to use a second > Pi which drives a relay (driven via GPIO pins) and 1-wire power is routed > through a normally closed contact on the relay. Pi-monitor reads a > heartbeat file on pi-control and if the heartbeat is more than 30 seconds > old it energises the relay for 10 seconds. This is controlling a solar hot > water system, which can easily boil (and has several times) if the controls > do not function correctly. > > Best of luck with your system. > > Mick > On 12/09/2020 11:32, Henrik Östman wrote: > > Hi! > I have been following the OWFS project for 20+ years and I really think > it's a marvelous piece of software. It's been run on a Raspberry Pi for > many years now to control the heating in our house. > However lately my Raspberry Pi has been more and more unstable, > overheating problems, diskfailure, hanging, owserver unexpectedly going > down and soo forth. It really got me thinking if my setup is the best > approche, my wife and kids should not have to be Unix admins and be able to > SSH to my server and restart the Docker container with Owserver just to not > freeze when I'm out on a business trip! So in a true Unix spirit I'm > splitting my Home automation system appart into well defined pieces that > "do one thing and do it well". > My house is heated by water-based floor heating, and there are three floor > heating control centers, with relays opening and closing the water-valves. > Each control center has a DS2408 controlling the relayes of 3-5 valves. A > made a small circuit board with a commonly used Arduino compatible > microcontroller that reads the temperature in the rooms using DS1820 > sensors, then instructs the DS2408 to open/close the right valve. There is > one circuit board for each control center, so if one goes down only a few > rooms get affected. There is a reset-button on each circuit board that > could be used to restart it for whatever reason, and since there are no > filesystems mounted there is no problem with corruption in case of power > loss, and restarting only takes a second. The Raspberry Pi is now only used > for plotting graphs, MQTT and other home automation tasks. > > Since I no longer use Owserver in my setup, I understand that it may be > inappropriate to ask for help within this forum. But I know that there are > some 10+ years skilled developers here with deep knowledge of 1-Wire > systems so I'm still going to pop the questions, maybe you could direct me > to a more suitable forum where we could continue the discussion? > > The problem I'm having is with the DS2408 devices, I only seem to be able > to communicate with them using the SKIP-ROM command, if I try to address > them individually then I only get garbage and errors back. The same code > works great when addressing DS2423 and DS18(B/S)20 devices, so I think the > code itself should work. Maybe I have missed something when communicating > or initializing the DS2408? I tried to read all the Maxim specs, and it > feels like I'm doing everything right. During startup I begin with > initializing the DS2408 and set the pins to output and to a known state. > > void ds2408_reset(DS2480B &ds, onewireNode &node) { > ESP_LOGD(TAG, "Reset DS2408, id: %s.", node.idStr.c_str()); > if (existTestMode(ds, node)) { > // Configure RSTZ as STRB output. > //ds.select(node.id); // reselect last selected device. > ds.write(SKIP_ROM); // HACK, this select all devices on the bus, but we > should select only this single device. Though I get CRC-errors using above > line. > ds.write(0xCC); // Issue Write Conditional Search Register command > ds.write(0x8D); // TA1, target address = 8Dh > ds.write(0x00); // TA2, target address = 008Dh > ds.write(0x04); // Write byte to Control/Status Register, RSTZ as STRB > output > // Verify configuration setting > if (!ds.reset()) { > ESP_LOGW(TAG, "Reset DS2408 failed after non-success configure RSTZ as > STRB."); > node.errors++; > return; > } > ds.write(RESUME); // reselect last selected device. > ds.write(0xF0); // Issue Read PIO Registers command > ds.write(0x8D); // TA1, target address = 8Dh > ds.write(0x00); // TA2, target address = 008Dh > auto status = ds.read(); // Read Control/Status Register and verify > ESP_LOGD(TAG, "DS2408 verify configuration setting: %s.", String(status, > HEX)); > // Set all relays off. > setState(ds, node, B11111111); > } else { > ESP_LOGW(TAG, "Reset DS2408 failed for id: %s.", node.idStr.c_str()); > } > } > > /** > * Exit test-mode. > * "The DS2408 is sensitive to the power-on slew rate and can inadvertently > power up with a test mode > * feature enabled. When this occurs, the P0 port does not respond to the > Channel Access Write command." > * @return 0=failed, 1=success > */ > bool existTestMode(DS2480B &ds, onewireNode &node) { > // RST PD 96h <64-bit DS2408 ROM Code> 3Ch RST PD > if (ds.reset()) { // onewire initialization sequence, to be followed by > other commands > ds.write(0x96); > for (uint8_t i = 0; i < 8; i++) { > ds.write(node.id[i]); > } > ds.write(0x3C); > if (ds.reset()) { > return 1; > } > } > return 0; > } > > int16_t setState(DS2480B &ds, onewireNode &node, uint8_t state) { > if (node.id[0] != DS2408) { > ESP_LOGW(TAG, "Device is not a DS2408!"); > return -1; > } > if (ds.reset()) { // onewire initialization sequence, to be followed by > other commands > ESP_LOGD(TAG, "Set DS2408 state to: %s.", String(state, BIN)); > uint8_t retries = MAX_CONSECUTIVE_RETRIES; > //ds.select(node.id); // issues onewire "MATCH ROM" address which selects > a SPECIFIC (only one) 1-Wire device > ds.write(SKIP_ROM); // HACK, this select all devices on the bus, but we > should select only this single device. Though I get CRC-errors using above > line. > do { > ds.write(0x5A); // Issue Channel-access Write command > ds.write(state); // Write byte to PIO > ds.write(~state); // Write inverted byte to PIO > auto status = ds.read(); // Read for verification (AAh = success) > auto newState = ds.read(); // DS2408 samples PIO pin status > if (status == 0xAA) { // AAh = success > ESP_LOGD(TAG, "DS2408 current state: %s.", String(newState, BIN)); > node.success++; > return newState; > } else { > node.errors++; > ESP_LOGW(TAG, "DS2408 setState failed, trying again..."); > if (ds.reset()) { > ds.write(RESUME); // reselect last selected device. > } else { > ESP_LOGW(TAG, "Reset DS2408 failed after non-success setState."); > node.errors++; > return -1; > } > } > } while (--retries); > return -1; > } else { > ESP_LOGW(TAG, "Reset DS2408 failed."); > node.errors++; > return -1; > } > } > > When using "ds.select(node.id);" it does not work, with > "ds.write(SKIP_ROM) it works better, the question is why? And if it does > matter, the circuit-board is using a DS2480 to communicate with the other > devices. > > Any help or suggestions would be more than welcome! > Thanks! > > // Henrik > > > > > _______________________________________________ > Owfs-developers mailing lis...@li...https://lists.sourceforge.net/lists/listinfo/owfs-developers > > _______________________________________________ > Owfs-developers mailing list > Owf...@li... > https://lists.sourceforge.net/lists/listinfo/owfs-developers > |
From: Mick S. <mi...@su...> - 2020-09-14 10:45:32
|
Hi Henrik, I can't answer you questions I'm afraid but I would add a few comments. I have been using Pi's since they were first released and yes, I have had a few problems as well. The most common problem I have found is power supply, always worth using a decent one, I use Meanwell units in critical situations. Second on the list is SD cards, I have had loads of failures there and I generally use hard drives recovered from old laptops instead of SD cards. The biggest problem I have had with 1-wire is that it occasionally locks up. I use a Sheepwalk RPi3 adapter to give me 8 channels, that uses the DS2482-800 chip. When a lock-up occurs it needs a power cycle of 1-wire, reboot does not reset it. The solution I use for that is to use a second Pi which drives a relay (driven via GPIO pins) and 1-wire power is routed through a normally closed contact on the relay. Pi-monitor reads a heartbeat file on pi-control and if the heartbeat is more than 30 seconds old it energises the relay for 10 seconds. This is controlling a solar hot water system, which can easily boil (and has several times) if the controls do not function correctly. Best of luck with your system. Mick On 12/09/2020 11:32, Henrik Östman wrote: > Hi! > I have been following the OWFS project for 20+ years and I really > think it's a marvelous piece of software. It's been run on a Raspberry > Pi for many years now to control the heating in our house. > However lately my Raspberry Pi has been more and more unstable, > overheating problems, diskfailure, hanging, owserver unexpectedly > going down and soo forth. It really got me thinking if my setup is the > best approche, my wife and kids should not have to be Unix admins and > be able to SSH to my server and restart the Docker container with > Owserver just to not freeze when I'm out on a business trip! So in a > true Unix spirit I'm splitting my Home automation system appart into > well defined pieces that "do one thing and do it well". > My house is heated by water-based floor heating, and there are three > floor heating control centers, with relays opening and closing the > water-valves. Each control center has a DS2408 controlling the relayes > of 3-5 valves. A made a small circuit board with a commonly used > Arduino compatible microcontroller that reads the temperature in the > rooms using DS1820 sensors, then instructs the DS2408 to open/close > the right valve. There is one circuit board for each control center, > so if one goes down only a few rooms get affected. There is a > reset-button on each circuit board that could be used to restart it > for whatever reason, and since there are no filesystems mounted there > is no problem with corruption in case of power loss, and restarting > only takes a second. The Raspberry Pi is now only used for plotting > graphs, MQTT and other home automation tasks. > > Since I no longer use Owserver in my setup, I understand that it may > be inappropriate to ask for help within this forum. But I know that > there are some 10+ years skilled developers here with deep knowledge > of 1-Wire systems so I'm still going to pop the questions, maybe you > could direct me to a more suitable forum where we could continue the > discussion? > > The problem I'm having is with the DS2408 devices, I only seem to be > able to communicate with them using the SKIP-ROM command, if I try to > address them individually then I only get garbage and errors back. The > same code works great when addressing DS2423 and DS18(B/S)20 devices, > so I think the code itself should work. Maybe I have missed something > when communicating or initializing the DS2408? I tried to read all the > Maxim specs, and it feels like I'm doing everything right. During > startup I begin with initializing the DS2408 and set the pins to > output and to a known state. > > void ds2408_reset(DS2480B &ds, onewireNode &node) { > ESP_LOGD(TAG, "Reset DS2408, id: %s.", node.idStr.c_str()); > if (existTestMode(ds, node)) { > // Configure RSTZ as STRB output. > //ds.select(node.id <http://node.id>); // reselect last selected device. > ds.write(SKIP_ROM);// HACK, this select all devices on the bus, but we > should select only this single device. Though I get CRC-errors using > above line. > ds.write(0xCC);// Issue Write Conditional Search Register command > ds.write(0x8D);// TA1, target address = 8Dh > ds.write(0x00);// TA2, target address = 008Dh > ds.write(0x04);// Write byte to Control/Status Register, RSTZ as STRB > output > // Verify configuration setting > if (!ds.reset()) { > ESP_LOGW(TAG, "Reset DS2408 failed after non-success configure RSTZ as > STRB."); > node.errors++; > return; > } > ds.write(RESUME);// reselect last selected device. > ds.write(0xF0);// Issue Read PIO Registers command > ds.write(0x8D);// TA1, target address = 8Dh > ds.write(0x00);// TA2, target address = 008Dh > auto status = ds.read();// Read Control/Status Register and verify > ESP_LOGD(TAG, "DS2408 verify configuration setting: %s.", > String(status, HEX)); > // Set all relays off. > setState(ds, node, B11111111); > } else { > ESP_LOGW(TAG, "Reset DS2408 failed for id: %s.", node.idStr.c_str()); > } > } > > /** > * Exit test-mode. > * "The DS2408 is sensitive to the power-on slew rate and can > inadvertently power up with a test mode > * feature enabled. When this occurs, the P0 port does not respond to > the Channel Access Write command." > * @return0=failed, 1=success > */ > bool existTestMode(DS2480B &ds, onewireNode &node) { > // RST PD 96h <64-bit DS2408 ROM Code> 3Ch RST PD > if (ds.reset()) {// onewire initialization sequence, to be followed by > other commands > ds.write(0x96); > for (uint8_t i = 0; i < 8; i++) { > ds.write(node.id[i]); > } > ds.write(0x3C); > if (ds.reset()) { > return 1; > } > } > return 0; > } > > int16_t setState(DS2480B &ds, onewireNode &node, uint8_t state) { > if (node.id[0] != DS2408) { > ESP_LOGW(TAG, "Device is not a DS2408!"); > return -1; > } > if (ds.reset()) {// onewire initialization sequence, to be followed by > other commands > ESP_LOGD(TAG, "Set DS2408 state to: %s.", String(state, BIN)); > uint8_t retries = MAX_CONSECUTIVE_RETRIES; > //ds.select(node.id <http://node.id>); // issues onewire "MATCH ROM" > address which selects a SPECIFIC (only one) 1-Wire device > ds.write(SKIP_ROM);// HACK, this select all devices on the bus, but we > should select only this single device. Though I get CRC-errors using > above line. > do { > ds.write(0x5A);// Issue Channel-access Write command > ds.write(state);// Write byte to PIO > ds.write(~state);// Write inverted byte to PIO > auto status = ds.read();// Read for verification (AAh = success) > auto newState = ds.read();// DS2408 samples PIO pin status > if (status == 0xAA) {// AAh = success > ESP_LOGD(TAG, "DS2408 current state: %s.", String(newState, BIN)); > node.success++; > return newState; > } else { > node.errors++; > ESP_LOGW(TAG, "DS2408 setState failed, trying again..."); > if (ds.reset()) { > ds.write(RESUME);// reselect last selected device. > } else { > ESP_LOGW(TAG, "Reset DS2408 failed after non-success setState."); > node.errors++; > return -1; > } > } > } while (--retries); > return -1; > } else { > ESP_LOGW(TAG, "Reset DS2408 failed."); > node.errors++; > return -1; > } > } > > When using "ds.select(node.id <http://node.id>);" it does not work, > with "ds.write(SKIP_ROM) it works better, the question is why? And if > it does matter, the circuit-board is using a DS2480 to communicate > with the other devices. > > Any help or suggestions would be more than welcome! > Thanks! > > // Henrik > > > > > _______________________________________________ > Owfs-developers mailing list > Owf...@li... > https://lists.sourceforge.net/lists/listinfo/owfs-developers |
From: Henrik Ö. <tr...@gm...> - 2020-09-12 10:32:30
|
Hi! I have been following the OWFS project for 20+ years and I really think it's a marvelous piece of software. It's been run on a Raspberry Pi for many years now to control the heating in our house. However lately my Raspberry Pi has been more and more unstable, overheating problems, diskfailure, hanging, owserver unexpectedly going down and soo forth. It really got me thinking if my setup is the best approche, my wife and kids should not have to be Unix admins and be able to SSH to my server and restart the Docker container with Owserver just to not freeze when I'm out on a business trip! So in a true Unix spirit I'm splitting my Home automation system appart into well defined pieces that "do one thing and do it well". My house is heated by water-based floor heating, and there are three floor heating control centers, with relays opening and closing the water-valves. Each control center has a DS2408 controlling the relayes of 3-5 valves. A made a small circuit board with a commonly used Arduino compatible microcontroller that reads the temperature in the rooms using DS1820 sensors, then instructs the DS2408 to open/close the right valve. There is one circuit board for each control center, so if one goes down only a few rooms get affected. There is a reset-button on each circuit board that could be used to restart it for whatever reason, and since there are no filesystems mounted there is no problem with corruption in case of power loss, and restarting only takes a second. The Raspberry Pi is now only used for plotting graphs, MQTT and other home automation tasks. Since I no longer use Owserver in my setup, I understand that it may be inappropriate to ask for help within this forum. But I know that there are some 10+ years skilled developers here with deep knowledge of 1-Wire systems so I'm still going to pop the questions, maybe you could direct me to a more suitable forum where we could continue the discussion? The problem I'm having is with the DS2408 devices, I only seem to be able to communicate with them using the SKIP-ROM command, if I try to address them individually then I only get garbage and errors back. The same code works great when addressing DS2423 and DS18(B/S)20 devices, so I think the code itself should work. Maybe I have missed something when communicating or initializing the DS2408? I tried to read all the Maxim specs, and it feels like I'm doing everything right. During startup I begin with initializing the DS2408 and set the pins to output and to a known state. void ds2408_reset(DS2480B &ds, onewireNode &node) { ESP_LOGD(TAG, "Reset DS2408, id: %s.", node.idStr.c_str()); if (existTestMode(ds, node)) { // Configure RSTZ as STRB output. //ds.select(node.id); // reselect last selected device. ds.write(SKIP_ROM); // HACK, this select all devices on the bus, but we should select only this single device. Though I get CRC-errors using above line. ds.write(0xCC); // Issue Write Conditional Search Register command ds.write(0x8D); // TA1, target address = 8Dh ds.write(0x00); // TA2, target address = 008Dh ds.write(0x04); // Write byte to Control/Status Register, RSTZ as STRB output // Verify configuration setting if (!ds.reset()) { ESP_LOGW(TAG, "Reset DS2408 failed after non-success configure RSTZ as STRB."); node.errors++; return; } ds.write(RESUME); // reselect last selected device. ds.write(0xF0); // Issue Read PIO Registers command ds.write(0x8D); // TA1, target address = 8Dh ds.write(0x00); // TA2, target address = 008Dh auto status = ds.read(); // Read Control/Status Register and verify ESP_LOGD(TAG, "DS2408 verify configuration setting: %s.", String(status, HEX )); // Set all relays off. setState(ds, node, B11111111); } else { ESP_LOGW(TAG, "Reset DS2408 failed for id: %s.", node.idStr.c_str()); } } /** * Exit test-mode. * "The DS2408 is sensitive to the power-on slew rate and can inadvertently power up with a test mode * feature enabled. When this occurs, the P0 port does not respond to the Channel Access Write command." * @return 0=failed, 1=success */ bool existTestMode(DS2480B &ds, onewireNode &node) { // RST PD 96h <64-bit DS2408 ROM Code> 3Ch RST PD if (ds.reset()) { // onewire initialization sequence, to be followed by other commands ds.write(0x96); for (uint8_t i = 0; i < 8; i++) { ds.write(node.id[i]); } ds.write(0x3C); if (ds.reset()) { return 1; } } return 0; } int16_t setState(DS2480B &ds, onewireNode &node, uint8_t state) { if (node.id[0] != DS2408) { ESP_LOGW(TAG, "Device is not a DS2408!"); return -1; } if (ds.reset()) { // onewire initialization sequence, to be followed by other commands ESP_LOGD(TAG, "Set DS2408 state to: %s.", String(state, BIN)); uint8_t retries = MAX_CONSECUTIVE_RETRIES; //ds.select(node.id); // issues onewire "MATCH ROM" address which selects a SPECIFIC (only one) 1-Wire device ds.write(SKIP_ROM); // HACK, this select all devices on the bus, but we should select only this single device. Though I get CRC-errors using above line. do { ds.write(0x5A); // Issue Channel-access Write command ds.write(state); // Write byte to PIO ds.write(~state); // Write inverted byte to PIO auto status = ds.read(); // Read for verification (AAh = success) auto newState = ds.read(); // DS2408 samples PIO pin status if (status == 0xAA) { // AAh = success ESP_LOGD(TAG, "DS2408 current state: %s.", String(newState, BIN)); node.success++; return newState; } else { node.errors++; ESP_LOGW(TAG, "DS2408 setState failed, trying again..."); if (ds.reset()) { ds.write(RESUME); // reselect last selected device. } else { ESP_LOGW(TAG, "Reset DS2408 failed after non-success setState."); node.errors++; return -1; } } } while (--retries); return -1; } else { ESP_LOGW(TAG, "Reset DS2408 failed."); node.errors++; return -1; } } When using "ds.select(node.id);" it does not work, with "ds.write(SKIP_ROM) it works better, the question is why? And if it does matter, the circuit-board is using a DS2480 to communicate with the other devices. Any help or suggestions would be more than welcome! Thanks! // Henrik |
From: Mick S. <mi...@su...> - 2020-09-02 19:59:34
|
I have been doing some more testing of voltage reading, this is what I found Testing on Pi4 with Sheepwalk RPi3 adapter with 2 voltage sensors, a DS2437 and a DS2438 Reading voltage from cached takes around 0.06 seconds for each, reading from uncached takes around 0.28 seconds for DS2437 and 0.23 seconds for DS2438. I then tested setting the /simultaneous/voltage bit followed by a 1 second delay Setting the /simultaneous/voltage bit causes CRC16_errors and CRC16_tries both to increase by 6, CRC8_errors remains unchanged, CRC8_tries increases by 2 Setting the /simultaneous/voltage bit has no impact on voltage read times, so it is not doing what I thought it was supposed to do. This is on the system that I am also using to test temperature reading, with no errors, so I am pretty sure the errors are not caused by a hardware problem. Thoughts? Mick |
From: Martin P. <Mar...@GM...> - 2020-08-28 20:51:03
|
👍 Stefano, thank you for the summary, most appreciated 👍 |
From: Stefano M. <mo...@ic...> - 2020-08-27 22:25:31
|
I have no experience with the DS2413, but if I understand correctly the manual, here is a list of valid commands: owproxy.write('device_id' + '/PIO.A, b'1’) # A on owproxy.write('device_id' + '/PIO.A, b’0’) # A off owproxy.write('device_id' + '/PIO.B, b'1’) # B on owproxy.write('device_id' + '/PIO.B, b’0’) # B off owproxy.write('device_id' + '/PIO.ALL, b’1,1’) # both on owproxy.write('device_id' + '/PIO.ALL, b’0,0’) # both off owproxy.write('device_id' + ‘/PIO.BYTE', b’\x03’) # both on owproxy.write('device_id' + ‘/PIO.BYTE', b’\x00’) # both off In fact from the Manual page DS2413(3): PIO.A PIO.B PIO.ALL PIO.BYTE read-write, yes-no State of the open-drain output ( PIO ) pin. 0 = non-conducting (off), 1 = conducting (on). Writing zero will turn off the switch, non-zero will turn on the switch. Reading the PIO state will return the switch setting. To deter- mine the actual logic level at the switch, refer to the sensed prop- erty. ALL references both channels simultaneously, comma separated. BYTE references both channels simultaneously as a single byte, with channel A in bit 0. If I got this right, then owserver on PIO.A is expecting a single byte, with character ‘1’ or ‘0’, ascii encoded ( python literals b’1’ or b’0’). PIO.BYTE instead is a single byte in which bit 0 is channel A, and bit 1 is channel B, so here I have to transmit a byte with integer values 0, 1, 2, or 3, (python literals b’\x00’, b’\x01’, b’\x03’, b’\x03’). PIO.ALL should be 3 bytes, e.g. b’0,1’. Just to clarify the python3 literals: >>> b'1' == b'\x31' True >>> b'0' == b'\x30' True >>> bytes.fromhex('00') b'\x00' >>> bytes.fromhex('deadbeef') b'\xde\xad\xbe\xef' >>> bytes(range(8)) b'\x00\x01\x02\x03\x04\x05\x06\x07' Hope this helps. Stefano > On 27 Aug 2020, at 19:47, Mick Sulley <mi...@su...> wrote: > > Yes I have struggled with that as well. I have discovered how to do it, but I don't really understand why. > > The answer seems to be that to write a 1 you need > > owproxy.write('device_id' + '/PIO.BYTE, b'1') > > so you need to write the byte value of the string 1, not the byte value of the integer 1. As I say, I don't understand why that is so, I dabble with Python, I'm far from expert :) > > Hope that helps > > Mick > > On 27/08/2020 15:18, Dennis Putnam wrote: >> Hi Martin, >> >> See embedded comments. >> >> On 8/27/2020 2:56 AM, Martin Patzak wrote: >>> >>> what does onOff.to_bytes(1,byteorder=sys.byteorder)) evaluate to? Is that resulting in a byte-value? I am not familiar with this... >> This seems to be the crux of the problem. After a lot of testing it appears to be a python 3 issue converting an integer to a byte string. I am convinced that passing a byte string to the write function is the problem. Thanks for everyone's help but this is not an owfs problem. >>> >>> Things you could try: >>> In the path use the fully qualifying path and add /uncached and write a byte-value like this owproxy.write('/uncached/3A.0BE14D000000/PIO.BYTE',b'0') >>> write to the individual outputs PIO.A or PIO.B directly >>> try reading the sensed values print('sensed.BYTE = ', owp.read('/uncached/3A.0BE14D000000/sensed.BYTE') >>> >>> On 26.08.20 21:05, Dennis Putnam wrote: >>>> I have rewritten my code to use pyownet but am now nearly back where I started. I have the following code: >>>> >>>> owproxy.write('/3A.'+blower.id_+'/PIO.BYTE',onOff.to_bytes(1,byteorder=sys.byteorder)) >>>> >>>> That statement gives me the following error: >>>> >>>> pyownet.protocol.OwnetError: [Errno 22] legacy - Invalid transaction: '/3A.0BE14D000000/PIO.BYTE' >>>> >>>> The error is meaningless to me. The path is not wrong so is it complaining about writing a single byte? >>>> >>>> Thanks again. >>>> >>>> On 8/24/2020 4:33 PM, Dennis Putnam wrote: >>>>> Thanks to everyone that replied. I was not aware of pyownet. I will look into that and rewrite my code to use it. >>>>> >>>>> On 8/24/2020 11:47 AM, Martin Patzak wrote: >>>>>> For python I would highly recommend you use the library pyownet by Stefano Miccoli >>>>>> https://github.com/miccoli/pyownet/ <https://github.com/miccoli/pyownet/> >>>>>> >>>>>> using Fuse can lead to weird problems... (not saying that it is the reason in your specific case) >>>>>> >>>>>> or you can use the buil-in functions in owserver owread/owwrite/owdir instead. >>>>>> >>>>> >>>> >>>> >>>> <https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=emailclient&utm_term=icon> Virus-free. www.avast.com <https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=emailclient&utm_term=link> <x-msg://4/#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2> >> >> >> >> >> _______________________________________________ >> Owfs-developers mailing list >> Owf...@li... <mailto:Owf...@li...> >> https://lists.sourceforge.net/lists/listinfo/owfs-developers <https://lists.sourceforge.net/lists/listinfo/owfs-developers> > _______________________________________________ > Owfs-developers mailing list > Owf...@li... > https://lists.sourceforge.net/lists/listinfo/owfs-developers |
From: Mail L. <li...@aj...> - 2020-08-27 21:13:29
|
Hi Guys, I’m pretty “late to the party” but In April this year I upgraded my RPi to the latest Debian packages to read all my DS28EA00 sensors and ran into issues with some of the sensor subfields had disappeared, namely “temphigh” And “templow” and needed to patch the source code and rebuild the package and then it was all good again. You might want to just double check that you can do read/write commands to the PIO.BYTE using the shell command line tools (owdir owread, owwrite) to make sure its not a owfs core issue. HTH Alex Shepherd Sent from my iPad >> On 28/08/2020, at 5:48 AM, Mick Sulley <mi...@su...> wrote: > > Yes I have struggled with that as well. I have discovered how to do it, but I don't really understand why. > > The answer seems to be that to write a 1 you need > > owproxy.write('device_id' + '/PIO.BYTE, b'1') > > so you need to write the byte value of the string 1, not the byte value of the integer 1. As I say, I don't understand why that is so, I dabble with Python, I'm far from expert :) > > Hope that helps > > Mick > > On 27/08/2020 15:18, Dennis Putnam wrote: >> Hi Martin, >> >> See embedded comments. >> >>> On 8/27/2020 2:56 AM, Martin Patzak wrote: >>> >>> what does onOff.to_bytes(1,byteorder=sys.byteorder)) evaluate to? Is that resulting in a byte-value? I am not familiar with this... >> This seems to be the crux of the problem. After a lot of testing it appears to be a python 3 issue converting an integer to a byte string. I am convinced that passing a byte string to the write function is the problem. Thanks for everyone's help but this is not an owfs problem. >>> >>> Things you could try: >>> In the path use the fully qualifying path and add /uncached and write a byte-value like this owproxy.write('/uncached/3A.0BE14D000000/PIO.BYTE',b'0') >>> write to the individual outputs PIO.A or PIO.B directly >>> try reading the sensed values print('sensed.BYTE = ', owp.read('/uncached/3A.0BE14D000000/sensed.BYTE') >>> >>> On 26.08.20 21:05, Dennis Putnam wrote: >>>> I have rewritten my code to use pyownet but am now nearly back where I started. I have the following code: >>>> >>>> owproxy.write('/3A.'+blower.id_+'/PIO.BYTE',onOff.to_bytes(1,byteorder=sys.byteorder)) >>>> >>>> That statement gives me the following error: >>>> >>>> pyownet.protocol.OwnetError: [Errno 22] legacy - Invalid transaction: '/3A.0BE14D000000/PIO.BYTE' >>>> >>>> The error is meaningless to me. The path is not wrong so is it complaining about writing a single byte? >>>> >>>> Thanks again. >>>> >>>>> On 8/24/2020 4:33 PM, Dennis Putnam wrote: >>>>> Thanks to everyone that replied. I was not aware of pyownet. I will look into that and rewrite my code to use it. >>>>> >>>>>> On 8/24/2020 11:47 AM, Martin Patzak wrote: >>>>>> For python I would highly recommend you use the library pyownet by Stefano Miccoli >>>>>> https://github.com/miccoli/pyownet/ >>>>>> >>>>>> using Fuse can lead to weird problems... (not saying that it is the reason in your specific case) >>>>>> >>>>>> or you can use the buil-in functions in owserver owread/owwrite/owdir instead. >>>> >>>> >>>> Virus-free. www.avast.com >> >> >> >> >> _______________________________________________ >> Owfs-developers mailing list >> Owf...@li... >> https://lists.sourceforge.net/lists/listinfo/owfs-developers > _______________________________________________ > Owfs-developers mailing list > Owf...@li... > https://lists.sourceforge.net/lists/listinfo/owfs-developers |
From: Mick S. <mi...@su...> - 2020-08-27 17:47:22
|
Yes I have struggled with that as well. I have discovered how to do it, but I don't really understand why. The answer seems to be that to write a 1 you need owproxy.write('device_id' + '/PIO.BYTE, b'1') so you need to write the byte value of the string 1, not the byte value of the integer 1. As I say, I don't understand why that is so, I dabble with Python, I'm far from expert :) Hope that helps Mick On 27/08/2020 15:18, Dennis Putnam wrote: > Hi Martin, > > See embedded comments. > > On 8/27/2020 2:56 AM, Martin Patzak wrote: >> >> what does *onOff.to_bytes(1,byteorder=sys.byteorder)) *evaluate to? >> Is that resulting in a byte-value? I am not familiar with this... > This seems to be the crux of the problem. After a lot of testing it > appears to be a python 3 issue converting an integer to a byte string. > I am convinced that passing a byte string to the write function is the > problem. Thanks for everyone's help but this is not an owfs problem. >> >> Things you could try: >> >> * In the path use the fully qualifying path and add */uncached *and >> write a byte-value like this >> *owproxy.write('/uncached/3A.0BE14D000000/PIO.BYTE',b'0')* >> * writeto the individual outputs PIO.A or PIO.B directly >> * try reading the sensed values***print('sensed.BYTE = ', >> owp.read('/uncached/****3A.0BE14D000000**/sensed.BYTE')* >> >> ** >> On 26.08.20 21:05, Dennis Putnam wrote: >>> I have rewritten my code to use pyownet but am now nearly back where >>> I started. I have the following code: >>> >>> *owproxy.write('/3A.'+blower.id_+'/PIO.BYTE',onOff.to_bytes(1,byteorder=sys.byteorder)) >>> >>> *That statement gives me the following error: >>> >>> *pyownet.protocol.OwnetError: [Errno 22] legacy - Invalid >>> transaction: '/3A.0BE14D000000/PIO.BYTE' >>> >>> *The error is meaningless to me. The path is not wrong so is it >>> complaining about writing a single byte? >>> >>> Thanks again. >>> >>> On 8/24/2020 4:33 PM, Dennis Putnam wrote: >>>> Thanks to everyone that replied. I was not aware of pyownet. I will >>>> look into that and rewrite my code to use it. >>>> >>>> On 8/24/2020 11:47 AM, Martin Patzak wrote: >>>>> For python I would highly recommend you use the library *pyownet >>>>> *by Stefano Miccoli >>>>> /https://github.com/miccoli/pyownet/ >>>>> >>>>> /using Fuse can lead to weird problems... (not saying that it is >>>>> the reason in your specific case) >>>>> >>>>> or you can use the buil-in functions in owserver >>>>> owread/owwrite/owdir instead. >>>>> >>>> >>> >>> >>> <https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=emailclient&utm_term=icon> >>> Virus-free. www.avast.com >>> <https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=emailclient&utm_term=link> >>> >>> >>> <#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2> >> > > > > _______________________________________________ > Owfs-developers mailing list > Owf...@li... > https://lists.sourceforge.net/lists/listinfo/owfs-developers |
From: Dennis P. <da...@be...> - 2020-08-27 14:38:57
|
Hi Martin, See embedded comments. On 8/27/2020 2:56 AM, Martin Patzak wrote: > > what does *onOff.to_bytes(1,byteorder=sys.byteorder)) *evaluate to? Is > that resulting in a byte-value? I am not familiar with this... This seems to be the crux of the problem. After a lot of testing it appears to be a python 3 issue converting an integer to a byte string. I am convinced that passing a byte string to the write function is the problem. Thanks for everyone's help but this is not an owfs problem. > > Things you could try: > > * In the path use the fully qualifying path and add */uncached *and > write a byte-value like this > *owproxy.write('/uncached/3A.0BE14D000000/PIO.BYTE',b'0')* > * writeto the individual outputs PIO.A or PIO.B directly > * try reading the sensed values***print('sensed.BYTE = ', > owp.read('/uncached/****3A.0BE14D000000**/sensed.BYTE')* > > ** > On 26.08.20 21:05, Dennis Putnam wrote: >> I have rewritten my code to use pyownet but am now nearly back where >> I started. I have the following code: >> >> *owproxy.write('/3A.'+blower.id_+'/PIO.BYTE',onOff.to_bytes(1,byteorder=sys.byteorder)) >> >> *That statement gives me the following error: >> >> *pyownet.protocol.OwnetError: [Errno 22] legacy - Invalid >> transaction: '/3A.0BE14D000000/PIO.BYTE' >> >> *The error is meaningless to me. The path is not wrong so is it >> complaining about writing a single byte? >> >> Thanks again. >> >> On 8/24/2020 4:33 PM, Dennis Putnam wrote: >>> Thanks to everyone that replied. I was not aware of pyownet. I will >>> look into that and rewrite my code to use it. >>> >>> On 8/24/2020 11:47 AM, Martin Patzak wrote: >>>> For python I would highly recommend you use the library *pyownet >>>> *by Stefano Miccoli >>>> /https://github.com/miccoli/pyownet/ >>>> >>>> /using Fuse can lead to weird problems... (not saying that it is >>>> the reason in your specific case) >>>> >>>> or you can use the buil-in functions in owserver >>>> owread/owwrite/owdir instead. >>>> >>> >> >> >> <https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=emailclient&utm_term=icon> >> Virus-free. www.avast.com >> <https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=emailclient&utm_term=link> >> >> >> <#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2> > -- This email has been checked for viruses by Avast antivirus software. https://www.avast.com/antivirus |
From: Martin P. <Mar...@GM...> - 2020-08-27 11:27:40
|
... did you try Mick's sample program? > import pyownet > > DevAddress = '*3A.0BE14D000000*' > owp = pyownet.protocol.proxy(persistent=True) > owp.write('/DevAddress/PIO.BYTE',b'0') > print('PIO.BYTE = ', owp.read('/uncached/DevAddress/PIO.BYTE')) > print('sensed.BYTE = ', owp.read('/uncached/DevAddress/sensed.BYTE')) On 26.08.20 21:05, Dennis Putnam wrote: > I have rewritten my code to use pyownet but am now nearly back where I > started. I have the following code: > > *owproxy.write('/3A.'+blower.id_+'/PIO.BYTE',onOff.to_bytes(1,byteorder=sys.byteorder)) > > *That statement gives me the following error: > > *pyownet.protocol.OwnetError: [Errno 22] legacy - Invalid transaction: > '/3A.0BE14D000000/PIO.BYTE' > > *The error is meaningless to me. The path is not wrong so is it > complaining about writing a single byte? > > Thanks again. > > On 8/24/2020 4:33 PM, Dennis Putnam wrote: >> Thanks to everyone that replied. I was not aware of pyownet. I will >> look into that and rewrite my code to use it. >> >> On 8/24/2020 11:47 AM, Martin Patzak wrote: >>> For python I would highly recommend you use the library *pyownet *by >>> Stefano Miccoli >>> /https://github.com/miccoli/pyownet/ >>> >>> /using Fuse can lead to weird problems... (not saying that it is the >>> reason in your specific case) >>> >>> or you can use the buil-in functions in owserver >>> owread/owwrite/owdir instead. >>> >> > > > <https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=emailclient&utm_term=icon> > Virus-free. www.avast.com > <https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=emailclient&utm_term=link> > > > <#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2> |
From: Martin P. <Mar...@GM...> - 2020-08-27 06:57:12
|
what does *onOff.to_bytes(1,byteorder=sys.byteorder)) *evaluate to? Is that resulting in a byte-value? I am not familiar with this... Things you could try: * In the path use the fully qualifying path and add */uncached *and write a byte-value like this *owproxy.write('/uncached/3A.0BE14D000000/PIO.BYTE',b'0')* * writeto the individual outputs PIO.A or PIO.B directly * try reading the sensed values***print('sensed.BYTE = ', owp.read('/uncached/****3A.0BE14D000000**/sensed.BYTE')* ** On 26.08.20 21:05, Dennis Putnam wrote: > I have rewritten my code to use pyownet but am now nearly back where I > started. I have the following code: > > *owproxy.write('/3A.'+blower.id_+'/PIO.BYTE',onOff.to_bytes(1,byteorder=sys.byteorder)) > > *That statement gives me the following error: > > *pyownet.protocol.OwnetError: [Errno 22] legacy - Invalid transaction: > '/3A.0BE14D000000/PIO.BYTE' > > *The error is meaningless to me. The path is not wrong so is it > complaining about writing a single byte? > > Thanks again. > > On 8/24/2020 4:33 PM, Dennis Putnam wrote: >> Thanks to everyone that replied. I was not aware of pyownet. I will >> look into that and rewrite my code to use it. >> >> On 8/24/2020 11:47 AM, Martin Patzak wrote: >>> For python I would highly recommend you use the library *pyownet *by >>> Stefano Miccoli >>> /https://github.com/miccoli/pyownet/ >>> >>> /using Fuse can lead to weird problems... (not saying that it is the >>> reason in your specific case) >>> >>> or you can use the buil-in functions in owserver >>> owread/owwrite/owdir instead. >>> >> > > > <https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=emailclient&utm_term=icon> > Virus-free. www.avast.com > <https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=emailclient&utm_term=link> > > > <#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2> |