Loading ...
Sorry, an error occurred while loading the content.

46921Re: [mh] xPL sensors

Expand Messages
  • George Clark
    Feb 27, 2014
      On 02/27/2014 03:03 PM, Lieven Hollevoet wrote:
      > Hey George,
      >
      > good to hear that you’re making progress.
      >
      > Op 27-feb.-2014, om 18:39 heeft George Clark <geomh@...> het volgende geschreven:
      >
      > Johan Braeken's suggestion was also very important. misterhouse ignores
      > xPL messages originated from it's own IP.
      > Do you mean MisterHouse-generated messages, or all messages that are generated on the same machine? I’m using a machine that runs MisterHouse next to multiple other programs that generate xPL messages and MisterHouse receives those messages well (note: only when I’m using the separate hub program, so this problem might be internal-hub related, and maybe another reason not to use the internal hub).
      Hmm... It doesn't seem to matter which hub I use. Sending the exact
      same message, one originated locally, and one originated on a 2nd
      system. In both cases they are parsed identically - the db4 debug
      messages are the same. But when originated local to misterhouse, I
      don't get any state events.
      >> I had two use two different
      >> systems to test. There is no indication in the debug logs that the
      >> message was dropped - It's received and parsed but then ignored. It
      >> would be nice if the debug messages logged the reason when a message was
      >> ignored.
      >>
      >> I've only played around with the Sensor definitions. Here is what was
      >> needed to get it to work:
      >>
      >> # XPL_SENSOR, <xpl_address>:<device_id>, <mh_item_name>, <mh_grouplist>,
      >> <sensor_type>, <state_key>
      >> XPL_SENSOR, arduino-test.basement:1, test_1, Sensors, input, current
      >> XPL_SENSOR, arduino-test.basement:1, test_2, Sensors, input, state
      > To my experience it is not required to have two separate declarations to parse a sensor.basic message. The reason you need this is because the message you’re sending does contain an extra field (the ‘state’ one). Note that this might make some hubs fail to send your message, as it is not compliant to the sensor.basic message specification (see http://xplproject.org.uk/wiki/index.php?title=Schema_-_SENSOR.BASIC#sensor.basic_Message_Specification)

      Agreed. I created multiple definitions to try to understand how the
      mapping was occurring. There is a possible 1:N mapping from incoming
      XPL message to the sensor definitions. With my example definitions,
      I've defined two inputs that are mapped to two different sensor definitions:

      XPL_SENSOR ... input, current => { type=input, device=1, current=on }
      XPL_SENSOR ... input, state => { type=input, device=1, state=on }

      And a single message containing both state=on and current=on generates
      two mh events, one for each sensor.

      So using the xpl-perl example code you pointed out as a starting point,
      I could generate a few different ways to map from the arduino inputs to
      the sensor definitions. I'm thinking that arduino would define two
      input types, digital and analog. And generate xPL messages:

      - { device=1, type=digital, pin2=off }
      - { device=1, type=analog, pinA0=<numeric level> }

      These would map to / be defined as:

      XPL_SENSOR, arduino-test.basement:1, test_1, Sensors, digital, pin2
      XPL_SENSOR, arduino-test.basement:1, test_2, Sensors, analog, pinA0

      So these sensors can be triggered individually, using two separate xPL messages, Or they could be triggered in a single message:
      { device=1 type=digital pin2=off pinA0=23 }


      George



      >> sensor_type defaults to "input", and state_key defaults to "current'
      >> so the first sensor could be defined as:
      >> XPL_SENSOR, arduino-test.basement:1, test_1, Sensors
      >>
      >> These definitions map from an xPL message. The critical parts are
      >> shown in <...> and map back to the sensor definition.
      >> ===============
      >> xpl-stat
      >> {
      >> hop=1
      >> source=arduino-test.basement <xpl_address>
      >> target=*
      >> }
      >> sensor.basic
      >> {
      >> type=input <sensor_type> device=1
      >> <device_id>
      >> current=on <state_key>
      >> state=1 <state_key>
      >> }
      >> ==============
      >>
      >> The message was sent using a python test tool:
      >>
      >> sendxplmsg.py <msg_type> <target> <schema> <body>
      >>
      >> python sendxplmsg.py "xpl-stat" "*" sensor.basic
      >> "type=input\\ndevice=1\\ncurrent=on\\nstate=1"
      >>
      >> Note that xpl-cmnd messages were processed as well. So either msg_type
      >> worked fine.
      >>
      >> (The source= is hardcoded in sendxplmsg.py and needed to be edited)
      >>
      >> This message triggers two events one on each of sensors test_1 and
      >> test_2 because two state keys are in the message body. If any of the
      >> sensor_type, device_id and state_key don't match, then the message is
      >> ignored.
      >>
      >> Misterhouse seems to ignore the "target" part of the message, but the
      >> external hub required a valid target.
      >> I used the test tools from
      >> http://xplproject.org.uk/wiki/index.php/Development_Tools to generate
      >> the messages
      >>
      >> George
      >>
      >>
      >>
      >> ------------------------------------------------------------------------------
      >> Flow-based real-time traffic analytics software. Cisco certified tool.
      >> Monitor traffic, SLAs, QoS, Medianet, WAAS etc. with NetFlow Analyzer
      >> Customize your own dashboards, set traffic alerts and generate reports.
      >> Network behavioral analysis & security monitoring. All-in-one tool.
      >> http://pubads.g.doubleclick.net/gampad/clk?id=126839071&iu=/4140/ostg.clktrk
      >> ________________________________________________________
      >> To unsubscribe from this list, go to: https://lists.sourceforge.net/lists/listinfo/misterhouse-users
      >>


      ------------------------------------------------------------------------------
      Flow-based real-time traffic analytics software. Cisco certified tool.
      Monitor traffic, SLAs, QoS, Medianet, WAAS etc. with NetFlow Analyzer
      Customize your own dashboards, set traffic alerts and generate reports.
      Network behavioral analysis & security monitoring. All-in-one tool.
      http://pubads.g.doubleclick.net/gampad/clk?id=126839071&iu=/4140/ostg.clktrk
      ________________________________________________________
      To unsubscribe from this list, go to: https://lists.sourceforge.net/lists/listinfo/misterhouse-users
    • Show all 11 messages in this topic