Announcement

Collapse
No announcement yet.

HS values, mcsMTTP plugin and initial planning

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • HS values, mcsMTTP plugin and initial planning

    I’m new to Homeseer and am looking to move what has largely been my own mix of Python and Java to something that uses Homeseer (std HS3 version running on a Pi) as the base. I’d like to end up with a system as readable as possible to others in the family in case I’m away as well as supporting more devices – on the latter, I am using a Vera for our few Z Wave bits but I had problems with it in other areas when I tried a more complete switch over a couple of years back.

    One thing I’m not sure I’m understanding is devices and their values. It looks to me that Homeseer is easiest to handle with individual devices for items/values, probably grouped with a parent device and that values are better numeric or simple boolean type things like “On/Off” but maybe I’m missing something.

    I’ll try to use my Visonic alarm (for which there doesn’t seem to be a plug in) as an example. On my old system, for a zone, I could receive something along the lines of {"event": "Violated","notices": ""}. The “OnUpdate” event code (embedded Java Rhino) could do something like:

    Code:
    state = Server.getNewProperty(“event”); //last changes for calling device
    if (state.equals(“Violated”)) {
    […]
    }
    Now I can pretty much do the same first stage via the mcsMQTT plugin (mostly just a change from XPL to mqtt was needed). And if mcsMQTT is set “Create both full parent and child keys” and event is made an integer instead of text, I can easily have that available for Homeseer’s Event pages if required, say for when a door is opened or a sensor is tripped.

    The thing that concerns me a bit is that going about things the way I am, I wind up with 3 devices per zone. If I take things further and add in some io controller (rather OTT but the Teensy I’m playing with with would do 8 analog in, 8 digital out, 8 pwm out) I’m toying with making for some outdoor bits if we go solar out there and a couple of IP cameras that send messages, etc. I wind up with about 200 mcsMQTT devices but maybe that shouldn’t be a concern?

    Alternatively, I could just have the parent devices, eg. just {"event": "Violated","notices": "null"}/ mcsMQTT setting “Place full payload into HS device”. This would reduce the device count considerably but I don’t see how to use that. The only things I can guess at is that it would be possible via a (I think) vbscript but doing that would seem to break away from my objective of trying to make as much as I can as clear and visible to others.

    Which would be best and, of course again, what might I be missing/not seeing?




  • #2
    You are correct that HS is oriented to devices that contain a single piece of information. What works well are numbers and enumerations. As an example, "Violated" would be accepted by mcsMQTT and associate it with a number. Behind the scenes you would be able to trigger events on "Violated". These are implemented as Value Status Pair and there is also a Value Graphic Pair if you want to render something visually pleasing. The DeviceValue contains the number and the related information is stored in other Device properties.

    DeviceString is a place to store unstructured information, but does not have a direct capability to trigger events based upon the contents of the string. There is a 3rd party plugin that will allow strings to be used as event triggers.

    If you want to use HS as it is intended then multiple devices and grouped with a parent is the way to go. You should not be concerned with 100's of devices. At any point in time only a few will be changing so HS has no difficulty keeping up. The constraint that others have had is with RAM on small computers. The entry version of HS that is sold with RPi has a plugin limit which is partially driven by the resource issue. If you are using higher data rates with MQTT then look at Express mode for your associations in mcsMQTT. You are not giving up much in capability, but saving CPU resources. The mcsMQTT manual has a section on performance considerations and contains benchmark data.

    As an aside, I believe the mcsXap plugin will handle XPL. The hub I use routes both XPL and XAP, but this version only runs on Windows. When I ported it to Linux and .NET I did not carry over XPL. You are, however, better going the MQTT route as that has a wider following.

    Comment


    • #3
      Michael, Thanks very much for a speedy response which clears my questions/doubts.

      As for XPL, it seemed to me to be the way to go when I cobbled things up I can't remember when but the XPL project is closed although you can still download code. I've already decided to drop it for this new attempt. Pretty much entirely (my laptop is dual boot to Win 10) Linux user here btw.

      Comment

      Working...
      X