Group Details Private

Global Moderators

Forum wide moderators

  • RE: Adding remotes, scene controllers as entities to MSR

    @andr said in Adding remotes, scene controllers as entities to MSR:

    But nodeid, property and property key is just to filter out right device, all the other data is still there?

    That's right. The event section only filters using the data; it does not modify the data or transform it in any way. Whatever is received in the event structure stays as received.

    @andr said in Adding remotes, scene controllers as entities to MSR:

    And in that case, I guess that it would work to skip event data and just mapping commands to MSR functions?

    I'm not sure what you mean by this. I don't think you want to skip anything. You should filter the incoming events, to make sure that you are handling the right events from the right device. So you need to be specific in the event filter to both the event type and the sending device.

    posted in Multi-System Reactor
  • RE: Adding remotes, scene controllers as entities to MSR

    But, still, I can't for some reason really understand the code and how different parts relate to each other.

    The event section is a filter to look for a specific event. In your version, you have multiple value keys, which is not allowed. Also, you don't want to filter by value, just accept them all and let the response section deal with them. I recommended against using label because it's changeable in ZWave, whereas the property and property_key values are defined by the device and will not change.

    So again, the event section is the filter that determines what incoming event will match, and what will not.

    Once an event matches, the response section determines what to do with it. Each component of the response section is an attribute of an assigned capability and the instructions to set it. In the case of button.state, my version says grab the value from, and then, map that value from the device's string to one of Reactor's accepted capability/attribute value. Setting button.since completes the "contract" of the button capability (i.e. makes it work like similar uses of button in other devices and related to other controllers). I'm not sure I can explain it more simply than that.

    It's really just a "if you find this... do this" configuration. The effect is that if a matching button event is detected by the event section, the response section will interpet the value and map it to a Reactor-compatible value to place on the entity attribute button.state, and also update the button.since timestamp. Thus the since timestamp changes every time a button press event is received, but state may not change, because it's possible to press a button once, wait 15 seconds, and press the same button again, which will result in the value single being persistent on the state attribute and not changing. So to detect an event, you have to check both state and since (and this is consistent with all button behavior in Reactor).

    To test button state in a rule, you test button.state for what you want in that rule (equals single, double, triple), and you AND that test with a button.since changes (from any to any). That will send a very short pulse when a matching button press occurs. While testing, to make sure you can see it, add a "sustained for" delay on the changes condition of a few seconds (keep it short), and you'll more easily see what's going on in the status view. Make sure to remove the delay when you're done playing (keeping it will dampen response to buttons when, for example, a single press is done repeatedly within the delay period).

    Example here:

    posted in Multi-System Reactor
  • RE: Adding remotes, scene controllers as entities to MSR

    Yeah, you need to fix it. It should not be left like this, as the discussion may be read by others in future, and I can't follow it (also on my phone), and likely nobody would bother

    From what I can see, I don't know why you're stuck on using payload in your from value, that word/key does not appear in your event data.

    posted in Multi-System Reactor
  • RE: Adding remotes, scene controllers as entities to MSR

    This did not work at all, Reactor would not even start

    Not surprised it wouldn't start... it's not properly formatted. Two errors: the attributes line is incorrectly indented (and therefore so is everything underneath it). Second issue, it shouldn't even be there. If it was properly indented, it would be ignored, because the code isn't looking for it. The definition of the button capability is already determined by system files; you don't need to repeat it here.

    As for the rest of it, the - event is also not properly indented, although this may not make it choke.

    Your property value in the event section won't match anything. That value doesn't appear in the example data you posted. It does match label, however, but I don't recommend using that. Change the property value to scene and add property_key with value 001. You probably also want to match the specific device, so that if you have more than one of these, these rules apply only to this one; do this by matching node_id.

    Your response has a few issues. Traversing your sample data, the action field is not The expr line shouldn't be there, since you're using map to remap the string values grabbed by from. The word string in the map data should be the word KeyPressed (an actual string you are looking for) with the value single (the string you want it to be, which matches the definition of the button.state attribute). If there are other possible strings that map to double, triple, hold and release, those should be added to the map; since you show in your sample data a 2x press, I added that (see below).

    Then, to make sure button.since is correctly updated (modified for each event), you need to specify it as an attribute to be updated as part of the event response, and in this case we will use an expression to set it to the current time.

    Correcting all that, I give you this:

          event_targets:    # this section starts the event-receiving entities
            "Keyfob_fyrkant":      # Assign an ID to your entity; each entity must have a unique ID
              name: Lukas Keyfob Fyrkant   # This is optional but recommended, so you have a friendly name
              capabilities: ['button']  # define an array of capabilities to be modified by the event 
              events:  # define an array of events that modify capability attributes on the entity
                - event:  # start of an event; each element of the events array begins this way
                    event_type: zwave_js_value_notification
                    data:  # optional section, if further matching to the event data is required
                      node_id: 15
                      property: "scene" # Square button
                      property_key: "001"
                  response:  # begin the (required) response section for handling the event
                    "button.state":  # an attribute that the event modifies.
                      from: ""  # dot-reference expression to pull value from event message
                      map:                    # optional, map to modify value
                        KeyPressed: 'single'   # if value is value_in, it is mapped to new_value
                        KeyPressed2x: 'double'
                      map_unmatched: 'unknown'
                      expr: "time()"

    I highly recommend using a syntax-highlighting YAML editor. Check out

    posted in Multi-System Reactor
  • RE: Adding remotes, scene controllers as entities to MSR

    @andr great choice!

    posted in Multi-System Reactor
  • RE: Condition must occur after -restriction not working

    OK. I think I've got this, and fixed in 22179.

    posted in Multi-System Reactor
  • RE: Reactor (Multi-System/Multi-Hub) Announcements

    Build 22179 (latest, zwavejs)

    NOTE: I will be on holiday for most of the month of July, and with limited Internet access. During this time, I will not be able to provide software support, fixes or builds, and likely will not have much time or means to read and answer questions. Please step up and provide support to your peers if questions come up!

    • HassController: Fix an issue that may randomly affect/disable assignment of primary attributes (since 22118).
    • Fix a problem in after...within (time-restricted) sequence conditions.
    posted in Multi-System Reactor
  • RE: Adding remotes, scene controllers as entities to MSR

    Re: PR 0000326:

    The way Home Assistant handles keyfobs is unlike the old Vera model you are used to. There is by default no "device" with variables indicating the state of the buttons. Home Assistant sends events when the buttons are pressed, but it doesn't set values on entities.

    In order to use these devices, you need to follow the configuration instructions here:

    What you will be doing is effectively telling HassController to create and maintain a virtual (Reactor) entity to track button state, and use the events sent by Home Assistant to map to state values on that entity. Since Reactor cannot know in advance what events are sent, there is no way for it to automatically "guess" these entities and create them; you've got to do the work. You will be editing/extending the configuration for your HassController in reactor.yaml.

    To help you find the events you need to build config for, add log_events: true to the config: section for your HassController and restart. Then play with your buttons, and observe what is logged to logs/hass_events.log. There will probably be a lot of data, so don't leave this setting on for too long, just for your research. Once you've identified the events sent by the device, you can build the configuration for the event_targets subsection as described in the linked docs.

    Let's keep the conversation here, instead of on the PR, as it's not looking like a bug or device support request at the moment, and the process of getting the config right will probably require some back and forth that would be educational for all to have documented here.

    Here's an example I use for testing... I have an Amcrest camera supported by Hass that sends events when it detects audio (and motion, etc., but this is just audio to keep it simple):

    It logs this event when audio is first detected:

    2022-06-28T16:29:23.885Z amcrest {"id":1656433623424,"type":"event","event":{"event_type":"amcrest","data":{"camera":"Cam2","event":"AudioMutation","payload":{"Code":"AudioMutation","action":"Start","index":"0"}},"origin":"LOCAL","time_fired":"2022-06-28T16:29:23.879133+00:00","context":{"id":"01G6NJASH7Y06R2AM49E7MF5YK","parent_id":null,"user_id":null}}}

    ...and this event when audio is no longer detected:

    2022-06-28T16:29:28.301Z amcrest {"id":1656433623424,"type":"event","event":{"event_type":"amcrest","data":{"camera":"Cam2","event":"AudioMutation","payload":{"Code":"AudioMutation","action":"Stop","index":"0"}},"origin":"LOCAL","time_fired":"2022-06-28T16:29:28.294575+00:00","context":{"id":"01G6NJAXV6AJAXPDAX93SJ8ZKT","parent_id":null,"user_id":null}}}

    For your review, I would copy-paste your logged data into to format it and make it more readable. Here's the Start event, reformatted:

    	"id": 1656433623424,
    	"type": "event",
    	"event": {
    		"event_type": "amcrest",
    		"data": {
    			"camera": "Cam2",
    			"event": "AudioMutation",
    			"payload": {
    				"Code": "AudioMutation",
    				"action": "Start",
    				"index": "0"
    		"origin": "LOCAL",
    		"time_fired": "2022-06-28T16:29:23.879133+00:00",
    		"context": {
    			"id": "01G6NJASH7Y06R2AM49E7MF5YK",
    			"parent_id": null,
    			"user_id": null

    The event section the part to focus on, and everything in the config is relative to it. From this, I built this config to drive a binary sensor that's true when my Amcrest camera detects sound:

      - id: hass
        enabled: true
        implementation: HassController
        name: Hass System
          source: 'ws://'
          access_token: "X.X.X"
          log_events: true
              capabilities: ['binary_sensor']
              primary_attribute: binary_sensor.state
                - event:
                    event_type: amcrest
                      camera: "Cam2"
                      event: "AudioMutation"
                      from: ""
                        Start: true
                        Stop: false

    A quick tour of that: you're telling HassController to build an entity with ID cam2_audio that has (only) binary_sensor capability, and binary_sensor.state as its primary attribute. From there, it looks for just one event: something with an event_type of amcrest, and equal to Cam2, and data.event equal to AudioMutation. That's what the events: section is describing. The response section that follows tells HassController what to do when it finds a matching event: set binary_sensor.state on the entity using the value of, and mapping the word Start to boolean true, and Stop to boolean false.

    posted in Multi-System Reactor
  • RE: [Solved] Changes in 22178 for HASS sensor no longer provide a value in topic "value", MQTTController echo capability

    Found this. Old bug since 22118 plus some odd conditions to trigger it, but I think I've got it. Build later today after I look at some other things.

    posted in Multi-System Reactor
  • RE: Adding remotes, scene controllers as entities to MSR

    OK. We're going to have to rush to look at this, as I'm going on a long vacation in a couple of days.

    Go ahead and open a PR in Mantis, and with it post your hass_states.json file (in logs) as an attachment (do not copy-paste the text of it). I also need the entity IDs (Home Assistant's) for the device in question.

    In addition, you haven't "shown the work" as is required for posts here. I need you to show the entities (Entities page, attributes open) that MSR has produced for its version of Home Assistant's entities, as well as any and all rules you've created to try to use them (Rule Status views, not Rule Editor editor). You can also attach all of that to the PR. The guidelines and recommendations for posts are in a pinned topic in this category.

    posted in Multi-System Reactor