I use owfs to control DS18B20, DS2405, DS2406P, etc
Using ownet.php I can read data from devices and write data (turn on/off) PIO on DS2405
But now I need to turn on PIO.A after detecting button press (PIO.B) on DS2406P as soon as possible. (Less a second)
I put "230" value to "set_alarm" value so when button is pressed I can see DS2406P in /mnt/1wire/bus.0/alarm/ folder.
So I can make script to check the file in loop. It works but makes avarage load of system high (uptime, top show this).
Is it the right way to check status of PIO, latch? I mean polling in loop without delays.
Now I have only one DS2406 but I need to check about 10-15 such keys...
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Your solution (polling the alarm directory) is the only way I know to see a change in the PIO state. You can probably add a small delay to the loop and still make your time goals.
The other good news is that your solution scales well. There shouldn't be any extra system load polling for dozens of devices -- the same alarm directory listing will show all of them.
Different Bus masters require different loads from the system. USB is probably the most efficient, passive the least -- it depends on how much of the work the master does autonomously.
Finally, when you get closer to production, you could look at running your system on a small embedded device, like the NSLU2 or some OpenWRT router. You can still get access to the data over tcp, but run the polling on the device.
I'll post your query to the developer's list, to see if other people have better suggestions.
Paul Alfille
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I made a delay for about 0,1 sec. Now it works enoght quick and dosn't increase system load.
But now I have a problem with my DS2406P and I don't understand the reason of this.
As I told, I use two channel of DS2406P (A and B). Channel A is used to turn on/off 220V lamp. Channel B is used to detect pressing button. It's independent events.
Channel A works fine in any cases.
But Channel B has problem. When I'm pressing a button i can see changing PIO.B from 0 to 1. So my script is looking for PIO.B property (via set_alarm and alarm folder) to check status of button. It works excellent when Channel A is off. But when the channel A is activated (on) and button (channel B) is pressed, value of PIO.B is '1'. It's okey. Then I release the button, but value of PIO.B remains 1 (ON). Then channel B doesn't respond to button and PIO.B remains 1 always. When I turn off channel A, PIO.B still dosn't respong to button. It starts to respond as before only if I write '0' to PIO.B propery. The problem is only if Channel A is turned on.
Is it a problem of my device (based on DS2406P and Dallas datasheet circuit) or owfs? May be, I do something wrong?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I'm reading
/mnt/1wire/12.7AD769000000/PIO.B
/mnt/1wire/uncached/12.7AD769000000/PIO.B
The result is the same and has 100% stability. If PIO.B is sensed by button first and PIO.A is turning on at this moment of time (by writing '1' to PIO.A), PIO.B remains sensed forever... (reading PIO.B property gives 1 although button/key is not pressed (released after PIO.A was on). Sorry for bad description. ;)
PIO.B works in any cases except this one. Please, help! How can I try to resolve the problem? Is it a feature of DS2406P?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Let me ask the obvious: This is a 2-channel DS2408? Does /12.xxxxchannels=2 ?
Also, can you check your circuit to demonstrate that the voltage is 0 when you are sensing 1?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
>This is a 2-channel DS2408?
No, this is a 2-channel DS2406P ;) DS2408 has 8 channels. I don't use DS2408 but it's required for my tasks and it will be used as well soon.
cat /mnt/1wire/12.7AD769000000/channels
2
Sorry, but 2406 + owfs works. I can change the status of channel A. Also I can see how PIO.B, flipflop.B, latch.B, sensed.B is changed by owfs when I press button, connected to channel B.
As far as I understand, when I'm changing PIO state, owfs sends command to master.
When PIO.B is 0 and I'm turning on PIO.A by 1, owfs sends Channel Access (?) command to change status of PIO.A
When PIO.B is 1 (button is pressed all the time) and I'm turning on PIO.A by echo "1", owfs sends Channel Access command to change status of what? Channel A, of course. But the PIO.B is sensed and also in '1' state. I don't know exectly the way owfs talk to master but I suppose owfs/master/smth else thinks that PIO.B as PIO.A is also needed to be conducted by PIO-transistor (because PIO.B is checked) and changes PIO.B from detecting level mode to conducting mode. May be something wrong with Channel Access command (F5h which is described on datasheet). I don't know...
The used circuit is ok.
I saw the changes in ow_2406.c
It's great to see flipflop properties. Reading Info byte and clearing cache are also important but I have a feeling that this patch dosn't solve my problem. Unfortunately it's hard to understand for me how ow_w_pio works and what exactly "b = (b & 0x9F) | ((data << 5) & 0x60);" means.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
>No, this is a 2-channel DS2406P ;) DS2408 has 8 channels. I don't use DS2408 but it's >> Oops DS2406 of course
>cat /mnt/1wire/12.7AD769000000/channels
>2
Good.
>>understand for me how ow_w_pio works and what exactly "b = (b & 0x9F) | ((data << 5) & 0x60);" means.
It keeps all bits in status byte except 6 and 5 (&9F) and moves flipflops from 1 and 0 of input to 6 and 5 of status memory byte.
There are 2 ways to set the flip flops: The Status memory byte, and the channel access.
I wanted to preseve all but the changed data in the status memory byte but I think the unchanged PIO.B SENSED data is being used as the SET data. I can get the proper baseline state from the flip flops instead, or use the (rather complicated for me) channel access approach.
Can you test again? I've changed the meaning of reading PIO to be essentially the (inverse) flipflop state (what you set rather than sense). Flipflop is the actual flipflop state (inverted PIO), and sensed is what it's always been. This allows me to use the intended value of the "other" PIO when setting a single PIO.
Paul Alfille
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Thank you very much!
Now everything is perfect. Just couple of questions.
The default value of set_alarm was '331', now '0'. Is it ok?
When Channel B is sensed by button 'sensed.B' property is 'NO (0)' as before but 'PIO.B' property remains '0' (although, early releases gives '1') I think it's normal behavior because key is off (only sensed) and I can see my device in alarm folder as before but nevertheless I'd like to ask, is it normal that PIO.B property doesn't react on conducting channel B by button?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
>1. The default value of set_alarm was '331', now '0'. Is it ok?
I can't find where the default value of the set_alarm was set, either in the old or the new code. I think that's what is in the chip registers..
>2. When Channel B is sensed by button 'sensed.B' property is 'NO (0)' as before but 'PIO.B' property remains '0' (although, early releases gives '1') I think it's normal behavior because key is off (only sensed) and I can see my device in alarm folder as before but nevertheless I'd like to ask, is it normal that PIO.B property doesn't react on conducting channel B by button?
PIO should now reflect what you SET, rather than what is sensed. This was needed to get the setting PIO to work -- otherwise the channel you weren't setting was getting changed to it's sensed value rather than stay as you set it (we have to change the entire register, not just a single bit.)
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I use owfs to control DS18B20, DS2405, DS2406P, etc
Using ownet.php I can read data from devices and write data (turn on/off) PIO on DS2405
But now I need to turn on PIO.A after detecting button press (PIO.B) on DS2406P as soon as possible. (Less a second)
I put "230" value to "set_alarm" value so when button is pressed I can see DS2406P in /mnt/1wire/bus.0/alarm/ folder.
So I can make script to check the file in loop. It works but makes avarage load of system high (uptime, top show this).
Is it the right way to check status of PIO, latch? I mean polling in loop without delays.
Now I have only one DS2406 but I need to check about 10-15 such keys...
Your solution (polling the alarm directory) is the only way I know to see a change in the PIO state. You can probably add a small delay to the loop and still make your time goals.
The other good news is that your solution scales well. There shouldn't be any extra system load polling for dozens of devices -- the same alarm directory listing will show all of them.
Different Bus masters require different loads from the system. USB is probably the most efficient, passive the least -- it depends on how much of the work the master does autonomously.
Finally, when you get closer to production, you could look at running your system on a small embedded device, like the NSLU2 or some OpenWRT router. You can still get access to the data over tcp, but run the polling on the device.
I'll post your query to the developer's list, to see if other people have better suggestions.
Paul Alfille
Thank you very much for the answer!
I made a delay for about 0,1 sec. Now it works enoght quick and dosn't increase system load.
But now I have a problem with my DS2406P and I don't understand the reason of this.
As I told, I use two channel of DS2406P (A and B). Channel A is used to turn on/off 220V lamp. Channel B is used to detect pressing button. It's independent events.
Channel A works fine in any cases.
But Channel B has problem. When I'm pressing a button i can see changing PIO.B from 0 to 1. So my script is looking for PIO.B property (via set_alarm and alarm folder) to check status of button. It works excellent when Channel A is off. But when the channel A is activated (on) and button (channel B) is pressed, value of PIO.B is '1'. It's okey. Then I release the button, but value of PIO.B remains 1 (ON). Then channel B doesn't respond to button and PIO.B remains 1 always. When I turn off channel A, PIO.B still dosn't respong to button. It starts to respond as before only if I write '0' to PIO.B propery. The problem is only if Channel A is turned on.
Is it a problem of my device (based on DS2406P and Dallas datasheet circuit) or owfs? May be, I do something wrong?
I have important information about my last problem with channel B.
I've tested my device based on DS2406P and now have the results.
The problem exists only when PIO.B is sensed before PIO.A is turned on.
Is it a bug in owfs ?
Are you reading the uncached directory?
I'm reading
/mnt/1wire/12.7AD769000000/PIO.B
/mnt/1wire/uncached/12.7AD769000000/PIO.B
The result is the same and has 100% stability. If PIO.B is sensed by button first and PIO.A is turning on at this moment of time (by writing '1' to PIO.A), PIO.B remains sensed forever... (reading PIO.B property gives 1 although button/key is not pressed (released after PIO.A was on). Sorry for bad description. ;)
PIO.B works in any cases except this one. Please, help! How can I try to resolve the problem? Is it a feature of DS2406P?
Are you able to test my changes? It would require building from the cvs version.
If not, I'll make a new release for you.
Paul Alfille
Sounds like a bug. Let me investigate. Thanks for the report (and for testing).
Paul Alfille
I have tested cvs version but my problem still exists...
Perhaps I have to provide some debug information but I don't know which one.
Let me ask the obvious: This is a 2-channel DS2408? Does /12.xxxxchannels=2 ?
Also, can you check your circuit to demonstrate that the voltage is 0 when you are sensing 1?
>This is a 2-channel DS2408?
No, this is a 2-channel DS2406P ;) DS2408 has 8 channels. I don't use DS2408 but it's required for my tasks and it will be used as well soon.
cat /mnt/1wire/12.7AD769000000/channels
2
Sorry, but 2406 + owfs works. I can change the status of channel A. Also I can see how PIO.B, flipflop.B, latch.B, sensed.B is changed by owfs when I press button, connected to channel B.
As far as I understand, when I'm changing PIO state, owfs sends command to master.
When PIO.B is 0 and I'm turning on PIO.A by 1, owfs sends Channel Access (?) command to change status of PIO.A
When PIO.B is 1 (button is pressed all the time) and I'm turning on PIO.A by echo "1", owfs sends Channel Access command to change status of what? Channel A, of course. But the PIO.B is sensed and also in '1' state. I don't know exectly the way owfs talk to master but I suppose owfs/master/smth else thinks that PIO.B as PIO.A is also needed to be conducted by PIO-transistor (because PIO.B is checked) and changes PIO.B from detecting level mode to conducting mode. May be something wrong with Channel Access command (F5h which is described on datasheet). I don't know...
The used circuit is ok.
I saw the changes in ow_2406.c
It's great to see flipflop properties. Reading Info byte and clearing cache are also important but I have a feeling that this patch dosn't solve my problem. Unfortunately it's hard to understand for me how ow_w_pio works and what exactly "b = (b & 0x9F) | ((data << 5) & 0x60);" means.
>No, this is a 2-channel DS2406P ;) DS2408 has 8 channels. I don't use DS2408 but it's >> Oops DS2406 of course
>cat /mnt/1wire/12.7AD769000000/channels
>2
Good.
>>understand for me how ow_w_pio works and what exactly "b = (b & 0x9F) | ((data << 5) & 0x60);" means.
It keeps all bits in status byte except 6 and 5 (&9F) and moves flipflops from 1 and 0 of input to 6 and 5 of status memory byte.
There are 2 ways to set the flip flops: The Status memory byte, and the channel access.
I wanted to preseve all but the changed data in the status memory byte but I think the unchanged PIO.B SENSED data is being used as the SET data. I can get the proper baseline state from the flip flops instead, or use the (rather complicated for me) channel access approach.
Can you test again? I've changed the meaning of reading PIO to be essentially the (inverse) flipflop state (what you set rather than sense). Flipflop is the actual flipflop state (inverted PIO), and sensed is what it's always been. This allows me to use the intended value of the "other" PIO when setting a single PIO.
Paul Alfille
Thank you, Paul!
Now everything works excellent!
Sorry, Paul! It seems like there is another bug in owfs.
After rebooting my server and starting owfs p20 the following is happening.
cat /mnt/1wire/bus.0/12.7AD769000000/set_alarm/PIO.A
0
cat /mnt/1wire/bus.0/12.7AD769000000/set_alarm/PIO.B
0
echo "230" > /mnt/1wire/bus.0/12.7AD769000000/set_alarm
cat /mnt/1wire/bus.0/12.7AD769000000/set_alarm/PIO.A
1
cat /mnt/1wire/bus.0/12.7AD769000000/set_alarm/PIO.B
0
Writing 230 to set_alarm property is turning PIO.A on!
echo "0" > /mnt/1wire/bus.0/12.7AD769000000/PIO.A
echo "0" > /mnt/1wire/bus.0/12.7AD769000000/PIO.B
echo "220" > /mnt/1wire/bus.0/12.7AD769000000/set_alarm
cat /mnt/1wire/bus.0/12.7AD769000000/set_alarm/PIO.A
1
cat /mnt/1wire/bus.0/12.7AD769000000/set_alarm/PIO.B
1
After "220" both channels are checked!
Something wrong with Status Memory writing?
Solve:
I've started p19, put 230 to 'set_alarm' then stoped p19 and started p20. Now everything is ok.
Thanks for the report!
So the problem is with the "set_alarm" in p20 (not p19)?
Paul Alfille
Yes. The problem with 'set_alarm' is only in p20. Obviously, it appeared after last patch.
p19 hasn't problem with 'set_alarm' but has problem with channel B sense.
I think it's now fixed.
Thank you very much!
Now everything is perfect. Just couple of questions.
>1. The default value of set_alarm was '331', now '0'. Is it ok?
I can't find where the default value of the set_alarm was set, either in the old or the new code. I think that's what is in the chip registers..
>2. When Channel B is sensed by button 'sensed.B' property is 'NO (0)' as before but 'PIO.B' property remains '0' (although, early releases gives '1') I think it's normal behavior because key is off (only sensed) and I can see my device in alarm folder as before but nevertheless I'd like to ask, is it normal that PIO.B property doesn't react on conducting channel B by button?
PIO should now reflect what you SET, rather than what is sensed. This was needed to get the setting PIO to work -- otherwise the channel you weren't setting was getting changed to it's sensed value rather than stay as you set it (we have to change the entire register, not just a single bit.)