Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Not all xPL messages are processed #10

Closed
hollie opened this issue Nov 7, 2012 · 4 comments
Closed

Not all xPL messages are processed #10

hollie opened this issue Nov 7, 2012 · 4 comments
Labels

Comments

@hollie
Copy link
Owner

hollie commented Nov 7, 2012

I'm trying to switch from my old SVN checkout to the new git branch.

I notice that not all xPL messages are processed, more specifically the messages originating from my motion sensors.

I'm trying to find out what change to xPL_Items causes this problem.

@hollie
Copy link
Owner Author

hollie commented Nov 7, 2012

Some more debugging info:

the working version is running xPL_Items.pl v1954 (from SVN). The non-working version is the current master branch.

I have two items defined:

XPL_SENSOR, hollie-utilmon.ventimon:281326AE03000020, venti_aww_uit, Weather, temp
XPL_SENSOR, hollie-jeenodes.nessie:room25           , motion_keuken, Keuken, motion

Messages from my xpl-logger:

192.168.1.30:50002 [xpl-trig/sensor.basic: hollie-utilmon.ventimon -> * 281326AE03000020/temp/22.81]
xpl-trig
{
hop=1
source=hollie-utilmon.ventimon
target=*
}
sensor.basic
{
device=281326AE03000020
type=temp
current=22.81
}
192.168.1.30:50002 [xpl-trig/sensor.basic: hollie-jeenodes.nessie -> * room25/motion/off]
xpl-trig
{
hop=1
source=hollie-jeenodes.nessie
target=*
}
sensor.basic
{
device=room25
type=motion
current=off
}

Both messages are received and processed by the old MH version, the master only processes the temperature and not the motion.

hollie added a commit that referenced this issue Nov 7, 2012
The device_monitor function was changed in a previous commit to match any characters instead of only non-whitespace characters. This causes some existing xPL device stop funcitoning with MH, as state in #10. What was the reasoning behind this change?

I guess it doesn't make sense to make MH restrictive in what messages is can process. IMHO whitespace should not cause a message to fail, as xPL is supposed to be a human-readable format.
@hollie hollie mentioned this issue Nov 7, 2012
@hollie
Copy link
Owner Author

hollie commented Nov 7, 2012

Apparently, this behavior was added intentionally to support non-standard xPL messages containing spaces in their key/value pairs?

http://tech.groups.yahoo.com/group/misterhouse/message/43779

@john-
Copy link

john- commented Nov 7, 2012

As this is recent change implemented to support noncompliant message format, recommendation is to revert the change. If user requires this they should maintain corrected version in their own fork.

@hollie
Copy link
Owner Author

hollie commented Nov 10, 2012

Bug fixed in #11.

@hollie hollie closed this as completed Nov 10, 2012
hollie added a commit that referenced this issue Mar 17, 2013
In #10 I reverted a change in the xPL message parsing because it apparently caused the xPL processing of messages to stop working. In #10 I had the impression that the change was required to allow MisterHouse to support unsupported messages to be processed.
However, I was wrong there. I misinterpreted the xPL spec. When a message is created, it contains key/value pairs. Only the name of a key/value pair cannot contain a space. The value can. This fix enables processing of messages with spaces in the value of key/value pairs to be processed again.
@hollie hollie mentioned this issue Mar 17, 2013
hollie pushed a commit that referenced this issue Mar 21, 2017
Hue emulation module for Misterhouse
hplato pushed a commit that referenced this issue Aug 30, 2017
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

2 participants