Quantcast

xPL and tracking state_changed from RPi gpio

classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

xPL and tracking state_changed from RPi gpio

Rick Bolen(gm)
Ahoy sailors!

I've managed to muddle my way through [mostly] implementing a[n
ancient?] technology, xPL. I'm sending door contact state from RPi gpio
to MH using xPL.

Problem is, my user code only tracks the closed->open contact state
(i.e., zero to 1), and doesn't track the open->closed state (i.e., 1 to
zero).

MHT definition:

XPL_SENSOR, raspberrypi-gpio.backdoor:1, Backdoor_1, GPIO, input, pin25


MH code...

#if (my $state = $Backdoor_1->state_now) {
if (my $state = $Backdoor_1->state_changed) {
   print_log "Backdoor state changed: $state";
}

MH xPL debug logging shows:

*** on 0->1
--->
...
db3 state check m=sensor.basic : pin25 key=xpl-stat : pin25 value=1
...
db3 xpl set n=$Backdoor1 to state=1


12/09/2016 06:45;00 PM Backdoor state changed: 1
<---


*** on 1->0
--->
...
db3 state check m=sensor.basic : pin25 key=xpl-stat : pin25 value=0
...
db3 xpl set n=$Backdoor1 to state=0

<---

My user code isn't hit on the 1->0 transition, even though debug logging
tracks the change.



Any ideas on how I can get MH to track this state change?

Sail on,

Rick









------------------------------------------------------------------------------
Developer Access Program for Intel Xeon Phi Processors
Access to Intel Xeon Phi processor-based developer platforms.
With one year of Intel Parallel Studio XE.
Training and support from Colfax.
Order your platform today.http://sdm.link/xeonphi
________________________________________________________
To unsubscribe from this list, go to: https://lists.sourceforge.net/lists/listinfo/misterhouse-users

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: xPL and tracking state_changed from RPi gpio

Lieven Hollevoet
Administrator
Hello Rick,

Fellow-xPL user here. I’m using the following code to react to status updates of an xPL-enabled motion sensor:

in items.mht:
        • XPL_SENSOR, hollie-jeenodes.nessie:room31,     motion_berging, Berging, motion

and then in the user code:

https://gist.github.com/hollie/631b7351532210fced976f358cb1ff38

This works as expected tracking both the ‘on’ and the ‘off’ state.

Are you using the latest MisterHouse master version? Because I don’t see any direct reasons why the ->state_changed is not triggered in your code, especially because you’re seeing the state change in the debug log of xPL.

In the current master version there is a check that is related to updating the ‘$state_value’ that might be impacting your code, see https://github.com/hollie/misterhouse/blob/master/lib/xPL_Items.pm#L524

Do you see in the log the line ‘db3 xpl setting state to …’ between the log files you pasted in your mail?

Best regards,
 Lieven.



> Op 10 dec. 2016, om 00:53 heeft Rick Bolen(gm) <[hidden email]> het volgende geschreven:
>
> Ahoy sailors!
>
> I've managed to muddle my way through [mostly] implementing a[n
> ancient?] technology, xPL. I'm sending door contact state from RPi gpio
> to MH using xPL.
>
> Problem is, my user code only tracks the closed->open contact state
> (i.e., zero to 1), and doesn't track the open->closed state (i.e., 1 to
> zero).
>
> MHT definition:
>
> XPL_SENSOR, raspberrypi-gpio.backdoor:1, Backdoor_1, GPIO, input, pin25
>
>
> MH code...
>
> #if (my $state = $Backdoor_1->state_now) {
> if (my $state = $Backdoor_1->state_changed) {
>   print_log "Backdoor state changed: $state";
> }
>
> MH xPL debug logging shows:
>
> *** on 0->1
> --->
> ...
> db3 state check m=sensor.basic : pin25 key=xpl-stat : pin25 value=1
> ...
> db3 xpl set n=$Backdoor1 to state=1
>
>
> 12/09/2016 06:45;00 PM Backdoor state changed: 1
> <---
>
>
> *** on 1->0
> --->
> ...
> db3 state check m=sensor.basic : pin25 key=xpl-stat : pin25 value=0
> ...
> db3 xpl set n=$Backdoor1 to state=0
>
> <---
>
> My user code isn't hit on the 1->0 transition, even though debug logging
> tracks the change.
>
>
>
> Any ideas on how I can get MH to track this state change?
>
> Sail on,
>
> Rick
>
>
>
>
>
>
>
>
>
> ------------------------------------------------------------------------------
> Developer Access Program for Intel Xeon Phi Processors
> Access to Intel Xeon Phi processor-based developer platforms.
> With one year of Intel Parallel Studio XE.
> Training and support from Colfax.
> Order your platform today.http://sdm.link/xeonphi
> ________________________________________________________
> To unsubscribe from this list, go to: https://lists.sourceforge.net/lists/listinfo/misterhouse-users
>


------------------------------------------------------------------------------
Developer Access Program for Intel Xeon Phi Processors
Access to Intel Xeon Phi processor-based developer platforms.
With one year of Intel Parallel Studio XE.
Training and support from Colfax.
Order your platform today.http://sdm.link/xeonphi
________________________________________________________
To unsubscribe from this list, go to: https://lists.sourceforge.net/lists/listinfo/misterhouse-users

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: xPL and tracking state_changed from RPi gpio

Giles Godart-Brown
In reply to this post by Rick Bolen(gm)
I use xPL a lot with MH; being a broadcast protocol its good if you have
multiple MH instances that watchdog each other.

Looks like you need a double equals to perform the equality test
(http://perlmeme.org/howtos/syntax/comparing_values.html);

e.g. try replacing

if (my $state = $Backdoor_1->state_changed) {

with

  if ( $state == $Backdoor_1->state_changed) {

I'm not sure you need the 'my' either in this instance


Giles

On 09/12/2016 23:53, Rick Bolen(gm) wrote:

> Ahoy sailors!
>
> I've managed to muddle my way through [mostly] implementing a[n
> ancient?] technology, xPL. I'm sending door contact state from RPi gpio
> to MH using xPL.
>
> Problem is, my user code only tracks the closed->open contact state
> (i.e., zero to 1), and doesn't track the open->closed state (i.e., 1 to
> zero).
>
> MHT definition:
>
> XPL_SENSOR, raspberrypi-gpio.backdoor:1, Backdoor_1, GPIO, input, pin25
>
>
> MH code...
>
> #if (my $state = $Backdoor_1->state_now) {
> if (my $state = $Backdoor_1->state_changed) {
>     print_log "Backdoor state changed: $state";
> }
>
> MH xPL debug logging shows:
>
> *** on 0->1
> --->
> ...
> db3 state check m=sensor.basic : pin25 key=xpl-stat : pin25 value=1
> ...
> db3 xpl set n=$Backdoor1 to state=1
>
>
> 12/09/2016 06:45;00 PM Backdoor state changed: 1
> <---
>
>
> *** on 1->0
> --->
> ...
> db3 state check m=sensor.basic : pin25 key=xpl-stat : pin25 value=0
> ...
> db3 xpl set n=$Backdoor1 to state=0
>
> <---
>
> My user code isn't hit on the 1->0 transition, even though debug logging
> tracks the change.
>
>
>
> Any ideas on how I can get MH to track this state change?
>
> Sail on,
>
> Rick
>
>
>
>
>
>
>
>
>
> ------------------------------------------------------------------------------
> Developer Access Program for Intel Xeon Phi Processors
> Access to Intel Xeon Phi processor-based developer platforms.
> With one year of Intel Parallel Studio XE.
> Training and support from Colfax.
> Order your platform today.http://sdm.link/xeonphi
> ________________________________________________________
> To unsubscribe from this list, go to: https://lists.sourceforge.net/lists/listinfo/misterhouse-users
>


------------------------------------------------------------------------------
Developer Access Program for Intel Xeon Phi Processors
Access to Intel Xeon Phi processor-based developer platforms.
With one year of Intel Parallel Studio XE.
Training and support from Colfax.
Order your platform today.http://sdm.link/xeonphi
________________________________________________________
To unsubscribe from this list, go to: https://lists.sourceforge.net/lists/listinfo/misterhouse-users

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: xPL and tracking state_changed from RPi gpio

Lieven Hollevoet
Administrator
Hey Giles,

I don’t think that is what Rick is trying to do. He captures the state of the state-changed function at the same time as checking if the state actually changed. Hence the ‘my’ declaration in front of the state. $state is local to the ‘if’ clause and will be set if the state actually changed and the ‘if’ clause is executed.

Now what I’m thinking about what is different between the code Rick is using and the code I’m using: when the output is set to ‘0’, the if will not be executed because the ->state_changed() will return the state, and the state will be ‘0’ so the code after the ‘if’ will not be exectuted.

The reason why it works in my code example is because I’m using ‘on’ and ‘off’ as xPL state for the motion detector and not ‘1’ and ‘0’. Rick, you might want to check the xPL protocol spec, the ‘current’ values should be reported to be ‘on’ or ‘off’ according to me.
http://xplproject.org.uk/wiki/Schema_-_SENSOR.html

Best regards,
 Lieven.


> Op 10 dec. 2016, om 09:43 heeft Giles Godart-Brown <[hidden email]> het volgende geschreven:
>
> I use xPL a lot with MH; being a broadcast protocol its good if you have
> multiple MH instances that watchdog each other.
>
> Looks like you need a double equals to perform the equality test
> (http://perlmeme.org/howtos/syntax/comparing_values.html);
>
> e.g. try replacing
>
> if (my $state = $Backdoor_1->state_changed) {
>
> with
>
>  if ( $state == $Backdoor_1->state_changed) {
>
> I'm not sure you need the 'my' either in this instance
>
>
> Giles
>
> On 09/12/2016 23:53, Rick Bolen(gm) wrote:
>> Ahoy sailors!
>>
>> I've managed to muddle my way through [mostly] implementing a[n
>> ancient?] technology, xPL. I'm sending door contact state from RPi gpio
>> to MH using xPL.
>>
>> Problem is, my user code only tracks the closed->open contact state
>> (i.e., zero to 1), and doesn't track the open->closed state (i.e., 1 to
>> zero).
>>
>> MHT definition:
>>
>> XPL_SENSOR, raspberrypi-gpio.backdoor:1, Backdoor_1, GPIO, input, pin25
>>
>>
>> MH code...
>>
>> #if (my $state = $Backdoor_1->state_now) {
>> if (my $state = $Backdoor_1->state_changed) {
>>    print_log "Backdoor state changed: $state";
>> }
>>
>> MH xPL debug logging shows:
>>
>> *** on 0->1
>> --->
>> ...
>> db3 state check m=sensor.basic : pin25 key=xpl-stat : pin25 value=1
>> ...
>> db3 xpl set n=$Backdoor1 to state=1
>>
>>
>> 12/09/2016 06:45;00 PM Backdoor state changed: 1
>> <---
>>
>>
>> *** on 1->0
>> --->
>> ...
>> db3 state check m=sensor.basic : pin25 key=xpl-stat : pin25 value=0
>> ...
>> db3 xpl set n=$Backdoor1 to state=0
>>
>> <---
>>
>> My user code isn't hit on the 1->0 transition, even though debug logging
>> tracks the change.
>>
>>
>>
>> Any ideas on how I can get MH to track this state change?
>>
>> Sail on,
>>
>> Rick
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> ------------------------------------------------------------------------------
>> Developer Access Program for Intel Xeon Phi Processors
>> Access to Intel Xeon Phi processor-based developer platforms.
>> With one year of Intel Parallel Studio XE.
>> Training and support from Colfax.
>> Order your platform today.http://sdm.link/xeonphi
>> ________________________________________________________
>> To unsubscribe from this list, go to: https://lists.sourceforge.net/lists/listinfo/misterhouse-users
>>
>
>
> ------------------------------------------------------------------------------
> Developer Access Program for Intel Xeon Phi Processors
> Access to Intel Xeon Phi processor-based developer platforms.
> With one year of Intel Parallel Studio XE.
> Training and support from Colfax.
> Order your platform today.http://sdm.link/xeonphi
> ________________________________________________________
> To unsubscribe from this list, go to: https://lists.sourceforge.net/lists/listinfo/misterhouse-users
>


------------------------------------------------------------------------------
Developer Access Program for Intel Xeon Phi Processors
Access to Intel Xeon Phi processor-based developer platforms.
With one year of Intel Parallel Studio XE.
Training and support from Colfax.
Order your platform today.http://sdm.link/xeonphi
________________________________________________________
To unsubscribe from this list, go to: https://lists.sourceforge.net/lists/listinfo/misterhouse-users

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: xPL and tracking state_changed from RPi gpio [resolved]

Rick Bolen(gm)
Thanks for the responses.

When I tried Giles recommendation, MH went into a tight loop on that
block, so to try and get that working, I'd have to do some more logic
testing\coding in that block. I haven't pursued that at the moment,
because I have similar code to my original working fine with other
hardware (owfs) elsewhere, and I wanna keep coding consistent if possible.

Lieven, thanks for the pointer to the xPL spec. That informed me on two
things:

1) I should really be using xpl-trig for these unsolicited state change
broadcasts.

2) and as you said, the source node's xPL state change should be
indicated by sending 'off' and 'on', not '0' or '1'. Once I got this
recoded on the xPL source node, state change tracked accurately.

thanks again. I'll be sending another email regarding this setup,

Rick


On 10/12/16 03:59 AM, Lieven Hollevoet wrote:

> Hey Giles,
>
> I don’t think that is what Rick is trying to do. He captures the state of the state-changed function at the same time as checking if the state actually changed. Hence the ‘my’ declaration in front of the state. $state is local to the ‘if’ clause and will be set if the state actually changed and the ‘if’ clause is executed.
>
> Now what I’m thinking about what is different between the code Rick is using and the code I’m using: when the output is set to ‘0’, the if will not be executed because the ->state_changed() will return the state, and the state will be ‘0’ so the code after the ‘if’ will not be exectuted.
>
> The reason why it works in my code example is because I’m using ‘on’ and ‘off’ as xPL state for the motion detector and not ‘1’ and ‘0’. Rick, you might want to check the xPL protocol spec, the ‘current’ values should be reported to be ‘on’ or ‘off’ according to me.
> http://xplproject.org.uk/wiki/Schema_-_SENSOR.html
>
> Best regards,
>  Lieven.
>
>
>> Op 10 dec. 2016, om 09:43 heeft Giles Godart-Brown <[hidden email]> het volgende geschreven:
>>
>> I use xPL a lot with MH; being a broadcast protocol its good if you have
>> multiple MH instances that watchdog each other.
>>
>> Looks like you need a double equals to perform the equality test
>> (http://perlmeme.org/howtos/syntax/comparing_values.html);
>>
>> e.g. try replacing
>>
>> if (my $state = $Backdoor_1->state_changed) {
>>
>> with
>>
>>  if ( $state == $Backdoor_1->state_changed) {
>>
>> I'm not sure you need the 'my' either in this instance
>>
>>
>> Giles
>>
>> On 09/12/2016 23:53, Rick Bolen(gm) wrote:
>>> Ahoy sailors!
>>>
>>> I've managed to muddle my way through [mostly] implementing a[n
>>> ancient?] technology, xPL. I'm sending door contact state from RPi gpio
>>> to MH using xPL.
>>>
>>> Problem is, my user code only tracks the closed->open contact state
>>> (i.e., zero to 1), and doesn't track the open->closed state (i.e., 1 to
>>> zero).
>>>
>>> MHT definition:
>>>
>>> XPL_SENSOR, raspberrypi-gpio.backdoor:1, Backdoor_1, GPIO, input, pin25
>>>
>>>
>>> MH code...
>>>
>>> #if (my $state = $Backdoor_1->state_now) {
>>> if (my $state = $Backdoor_1->state_changed) {
>>>    print_log "Backdoor state changed: $state";
>>> }
>>>
>>> MH xPL debug logging shows:
>>>
>>> *** on 0->1
>>> --->
>>> ...
>>> db3 state check m=sensor.basic : pin25 key=xpl-stat : pin25 value=1
>>> ...
>>> db3 xpl set n=$Backdoor1 to state=1
>>>
>>>
>>> 12/09/2016 06:45;00 PM Backdoor state changed: 1
>>> <---
>>>
>>>
>>> *** on 1->0
>>> --->
>>> ...
>>> db3 state check m=sensor.basic : pin25 key=xpl-stat : pin25 value=0
>>> ...
>>> db3 xpl set n=$Backdoor1 to state=0
>>>
>>> <---
>>>
>>> My user code isn't hit on the 1->0 transition, even though debug logging
>>> tracks the change.
>>>
>>>
>>>
>>> Any ideas on how I can get MH to track this state change?
>>>
>>> Sail on,
>>>
>>> Rick
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> ------------------------------------------------------------------------------
>>> Developer Access Program for Intel Xeon Phi Processors
>>> Access to Intel Xeon Phi processor-based developer platforms.
>>> With one year of Intel Parallel Studio XE.
>>> Training and support from Colfax.
>>> Order your platform today.http://sdm.link/xeonphi
>>> ________________________________________________________
>>> To unsubscribe from this list, go to: https://lists.sourceforge.net/lists/listinfo/misterhouse-users
>>>
>>
>>
>> ------------------------------------------------------------------------------
>> Developer Access Program for Intel Xeon Phi Processors
>> Access to Intel Xeon Phi processor-based developer platforms.
>> With one year of Intel Parallel Studio XE.
>> Training and support from Colfax.
>> Order your platform today.http://sdm.link/xeonphi
>> ________________________________________________________
>> To unsubscribe from this list, go to: https://lists.sourceforge.net/lists/listinfo/misterhouse-users
>>
>

------------------------------------------------------------------------------
Developer Access Program for Intel Xeon Phi Processors
Access to Intel Xeon Phi processor-based developer platforms.
With one year of Intel Parallel Studio XE.
Training and support from Colfax.
Order your platform today.http://sdm.link/xeonphi
________________________________________________________
To unsubscribe from this list, go to: https://lists.sourceforge.net/lists/listinfo/misterhouse-users

Loading...