Discussion Forum to share and further the development of home control and automation, independent of platforms.

    SmartHome Community

    • Register
    • Login
    • Search
    • Categories
    • Recent
    • Tags
    • Popular
    • Unsolved
    1. Home
    2. toggledbits
    • Can't post screen shots here now?

      cw-kid

      I wanted to asked a question with some screen shots but I am getting an error when I try to copy and paste an image from paint into this forum post editor.

      "Error something went wrong parsing server response" it was saying.

      Multi-System Reactor
    • Home Assistant add-on

      M

      I've done a bit of repackaging of MSR to make it work as an add-on under Home Assistant mostly for my own purposes but hopefully it makes it a bit easier to install and get going.

      GitHub - mrw298/hassio-reactor-addon GitHub - mrw298/hassio-reactor-addon

      Contribute to mrw298/hassio-reactor-addon development by creating an account on GitHub.

      Multi-System Reactor
    • DelayLight replicate in MSR

      P

      Hi Everyone,

      I am just starting to move over from Vera to Home Assistant using MSR.

      On vera I had been using DelayLight. I have tried to replicate it with help from youtube (https://www.youtube.com/watch?v=fc_ij0D1hXE) Reactor for Vera #006 - Emulating DelayLight in Reactor.

      I have created 6 rules that sort of work. but I am just wondering if this is best practice or should can it be built in 1 rule like the old vera way?

      Multi-System Reactor
    • Having an Echo device play mp3?

      F

      Hi!
      I tried to find an answer in both the forum and by myself, without any luck. I'm trying to make my Echo device play a mp3 file. The same mp3 file is easy to play with other smart speakers (Sonos, Google/Nest) - that it no problem. Same approch do not work with Echo devices. The mp3 files I want to use is located on my HA installation (config/www/audio), running on ver. 2023.5.4. I have MSR ver 23114.
      Is there a way to do this easily?
      Thanks!
      /Fanan

      Multi-System Reactor
    • Reactor (Multi-System/Multi-Hub) Announcements

      toggledbits

      Build 21228 has been released. Docker images available from DockerHub as usual, and bare-metal packages here.

      Home Assistant up to version 2021.8.6 supported; the online version of the manual will now state the current supported versions; Fix an error in OWMWeatherController that could cause it to stop updating; Unify the approach to entity filtering on all hub interface classes (controllers); this works for device entities only; it may be extended to other entities later; Improve error detail in messages for EzloController during auth phase; Add isRuleSet() and isRuleEnabled() functions to expressions extensions; Implement set action for lock and passage capabilities (makes them more easily scriptable in some cases); Fix a place in the UI where 24-hour time was not being displayed.
      Multi-System Reactor
    • Sending numbers as payload type in actions enhancement

      J

      I'm controlling a HVAC device through the MQTTController. While setting up the entity config in reactor.yaml, I started with this on the action block:

      set_setpoint: topic: "ezlo_mqtt/set/item/%topic%/set/Tsetpoint" payload: expr: "parameters.setpoint" type: raw

      However, as the setpoint is a number in the UI, things were not fully parseable as a number and nothing was outputted to mqtt.

      So I've added this code to MQTTController.js at line 1449 to add the payload type 'number':

      } else if ( 'number' === act.payload.type ) { payload = String( payload ); } else if (''raw' !== ( act.payload.type || 'raw' ) ) {

      After this change, I was able to set the payload type to number:

      set_setpoint: topic: "ezlo_mqtt/set/item/%topic%/set/Tsetpoint" payload: expr: "parameters.setpoint" type: number

      And things worked as intended, being able to send numbers in the actions bit of a rule set.

      Multi-System Reactor
    • MIOS - UI5 web login

      Black Cat

      Can anyone help with the MIOS UI5 weblink? Not the getvera one.
      Still running UI5 on a couple of sensors & lights and need to tweak PLEG but for the life of me I can't remember the link to tunnel back to the trusty machine....

      General Discussion
    • SiteSensor > how to fill in Value Expressions (json data) SOLVED !

      M

      I still use Vera controllers in combination with ReactorSensors. I have several Reactor sensors in use to retrieve weather data from Wunderground (i have a personal weather station), my smartmeter etc.

      Recently I installed solar panels with a SolarEdge inverter. SolarEdge has an API to retrieve my power production data from their cloud.
      Output is in json.

      So I created a new Reactor Sensor. Connection is working (query okay).
      But I encounter problems at the Value Expressions. Either I get ""query okay" but no data or I get "query okay but 1 expressions failed"

      This is the json output

      {"overview":{"lastUpdateTime":"2023-05-12 10:45:57","lifeTimeData":{"energy":476310.0,"revenue":216.577},"lastYearData":{"energy":433001.0},"lastMonthData":{"energy":433001.0},"lastDayData":{"energy":8262.0},"currentPower":{"power":5647.0},"measuredBy":"INVERTER"}}

      So it has different layers/levels.

      I tried to put in the Value Expressions field several combinations to get the energy data of today (8262.0), like:

      response.lastDayData.energy
      response.overview.lastDayData.energy
      response.overview.lastUpdateTime.lastDayData.energy

      all fail...

      Who can help me with this ?

      Vera/openLuup plugins
    • openweather plugin ?

      DesT

      Hey guys....

      long time 😉

      Since Dark weather is no more active, thanks Apple. Anyone switch to openweather to get weather data ?

      Plugins
    • Smart devices and mesh

      J

      The wifi on my router is turned off, and wifi around the house is provided using a mesh - 3 units altogether (one connected directly to the router) that are spread around the house.

      I would like to start automating certain tasks around the house and intend to try adding a few smart sockets to my setup.

      The mesh system I have supports both 2.4GHz and 5GHz, and does not provide me with the option to control them - i.e. turn one or both on/off, give each a different SSID, etc.

      The devices I wish to purchase/use only support 2.4GHz.

      Will turning the mesh units off and temporarily turning the 2.4GHz wifi on the router to allow me to set them up be enough? Will I then be able to return to my usual setup and everything will work as it should?

      Many thanks in advance

      General Discussion
    • Smart bed sensor

      C

      Hey everyone, I'm currently working on developing a bed sensor that can detect when you're out of bed. It could be used to trigger other smart home gadgets, like lights or blinds, temperature etc.
      The sensors are placed under the legs of your bed post. Should look and feel like "smart furniture pads" with size 2 inches in diameter and 1/4 inch thick.
      Before we go any further, I'd love to get your thoughts on this - would a bed sensor like this be something you'd find useful? We're still in the early stages of development, so any feedback you have would be greatly appreciated. Thanks in advance!

      smart möbeltass.JPG

      General Discussion
    • JSON payload in MQTTController entities actions (+ reverse color mapping to RGB)

      M

      Some background
      I'm trying to integrate a Zigbee device into the MSR using zigbee2mqtt bridge and MQTTController. The device in question is a cheap mood light that has following properties that I'd like to control:

      switch (on/off) brightness color

      I'v already managed to get the switch part working and can toggle the light on/off. Also the brightness value is mapped back to MSR. In zigbee2mqtt it has a value range from 0 to 254, so this the reason for the expression:

      expr: 'payload.brightness / 254'

      Here's the entity definition (don't know whether the type should be something else than the Switch)

      zigbee-lidl-mood-light: name: 'Lidl Mood Light' friendly_name: 'Mood Light' type: Switch uses_template: lidl-moodlight

      And the corresponding template (NOTE: rgb_color has not been defined in this example):

      lidl-moodlight: init: "zigbee2mqtt/%friendly_name%/get/state" query: "zigbee2mqtt/%friendly_name%/get/state" capabilities: - power_switch - toggle - dimming primary_attribute: power_switch.state events: "zigbee2mqtt/%friendly_name%": "power_switch.state": json_payload: true expr: 'upper(payload.state) == "ON"' "dimming.level": json_payload: true expr: 'payload.brightness / 254' actions: power_switch: "on": topic: "zigbee2mqtt/%friendly_name%/set/state" payload: 'ON' "off": topic: "zigbee2mqtt/%friendly_name%/set/state" payload: 'OFF' set: topic: "zigbee2mqtt/%friendly_name%/set/state" payload: expr: "parameters.state ? 'ON' : 'OFF'" type: raw toggle: topic: "zigbee2mqtt/%friendly_name%/set/state" payload: 'TOGGLE'

      The problem
      In order to control the brightness or the RGB color values, I would have send a JSON payload in corresponding actions. But I have no idea how to define it in the template. The reason why the switch part is working is that the zigbee2mqtt accepts also plain ON / OFF / TOGGLE string payloads in that case.

      But the brightness should be controlled with the following payload:

      {"brightness": 196}

      And the RGB color like:

      {"color":{"rgb":"46,102,150"}}

      Here's the link for the documentation (the Exposes part defines the messages).

      So how should I define the JSON payload for example for the dimming action? It definitely should be some sort of expressions since I have to map the MSR real value (0...1) to (0...254) for the zigbee2mqtt.

      actions: dimming: set: topic: "zigbee2mqtt/%friendly_name%/set" payload: expr: ????? type: json

      Another problem is the RGB value. I could use the rgb_color capability for the setting but the problem is that the zigbee2mqtt only reports the current color in hue/saturation or xy coordinates.

      Here's an example of published message after setting the color:

      Topic: zigbee2mqtt/Mood Light QoS: 0 { "brightness":254, "color":{ "hue":240, "saturation":100, "x":0.1355, "y":0.0399 }, "color_mode":"xy", "color_temp":574, "linkquality":96, "state":"ON" }

      I would have to map those values back to RGB, but is it even possible with existing constructs in MQTTController's templates?

      Help would be appreciated @toggledbits
      br,
      mgvra

      Multi-System Reactor
    • Another Vera --> Home Assistant migration question

      T

      Good morning all,
      I've got a stable Home Assistant running on a RPI 4 with a Aeotec Z-Stick 7 Plus, and of course the Z-wave JS integration. I've manually moved a handful of devices, and I'm overall much happier with the HA z-wave capability than I am with Vera. There are still some things I'm trying to figure out that I have in Vera that I'm not sure how they'll work in HA, but no deal breakers.

      I've got all of my automation on MSR and off of luup Reactor, so really the only thing left for me is to migrate my Z-wave network. I saw @rafale77's post about using a Zwave.me UZB1 to Zway, but of course that's not what I'm using.

      Is there a similar method that I can use my Aeotec Z-Stick 7 plus to Home Assistant? I have around 70 Z-wave devices (give or take devices that generate multiple instances in Vera), so manual unpairing, including, etc, would be quite a chore.

      Vera
    • Home Assistant push notification for Reactor version update possible?

      T

      Good evening,
      I was wondering if it would be possible to send out a push notification when there is a update to MSR to HA users. I know how to set up notifications through Reactor to HA users, but I'm unsure what to look for in regards to updates. I know that MSR itself will tell me there is an update, but unless I'm logged into MSR in a browser, I'm not always going to see that.

      Just updated to latest-23114-e4060aae MSR
      Home Assistant 2023.4.6
      Supervisor 2023.04.1
      Operating System 10.0

      Multi-System Reactor
    • ChatGPT - finally I can now retyre in piece and quite, knowing everting is in goof hands.

      A

      ChatGPT samples:

      Me:

      Tell me about an iot program called openLuup.

      It:

      OpenLuup is an open source home automation system that is built on the VeraLuup platform. It is designed to be easy to install and configure, and provides users with a powerful and versatile way to control their home automation devices. OpenLuup offers a wide range of features, including support for many popular home automation devices, scheduling, scripting, and integration with other services. OpenLuup is designed to be customizable, allowing users to create their own home automation systems. It is an excellent choice for those looking to create their own home automation system without spending a lot of money.

      Me:

      Write an iot program using openLuup.

      It:

      --openLuup IoT Program-- -- Initialize Variables -- local device_id = "MyHomeDevice" local temperature_sensor_id = "MyTemperatureSensor" local temperature_threshold = 75 -- Create Devices -- luup.create_device("OpenLuup Temperature Sensor", 0, device_id, "D_GenericSensor1.xml", "I_GenericSensor1.xml", "S_TemperatureSensor1.xml", "") luup.variable_set("urn:upnp-org:serviceId:TemperatureSensor1", "CurrentTemperature", 0, device_id) -- Start Timer -- luup.call_delay("check_temperature", 10, "", false) --Function to Check Temperature-- function check_temperature() local current_temperature = luup.variable_get(temperature_sensor_id, "CurrentTemperature", 0) --Check Temperature Threshold-- if current_temperature >= temperature_threshold then --Send Alert-- luup.call_action("urn:micasaverde-com:serviceId:HomeAutomationGateway1", "SendTextMessage", {PhoneNumber="1234567890", Message="ALERT! Temperature exceeded threshold!"}, 0) end --Reset Timer-- luup.call_delay("check_temperature", 10, "", false) end

      Me:

      Write an iot program using openLuup.

      It:

      Write an iot program using openLuup. -- openLuup IOT Program -- -- Variables local lampState = false local lampTime = 0 -- Functions function lampTimer() if lampTime > 0 then lampTime = lampTime - 1 if lampTime == 0 then luup.variable_set('urn:upnp-org:serviceId:SwitchPower1', 'Status', 0, lampDeviceID) lampState = false end end end -- Setup luup.call_delay('lampTimer', 60, 0) -- Main Loop while true do -- Check for motion if luup.variable_get('urn:micasaverde-com:serviceId:MotionSensor1', 'Tripped', motionSensorDeviceID) == '1' then if not lampState then luup.variable_set('urn:upnp-org:serviceId:SwitchPower1', 'Status', 1, lampDeviceID) lampState = true -- Set lamp timer to 5 minutes lampTime = 300 end end luup.sleep(1) end

      What??

      luup.sleep(1)

      Not good - looks like I still have some semblance of a job to fulfill.

      Me:

      An iot program called openLuup was written by akbooer. Who is akbooer?

      It: (note: answer redacted and as I understand it, also incorrect re: AltUI):

      akbooer is the pseudonym of the software developer and home automation enthusiast. He is the creator of the openLuup home automation software, which is an open-source version of the Vera home automation system. He is also the creator of the AltUI graphical user interface for openLuup.

      Me:

      Who created of the AltUI graphical user interface for openLuup.

      and

      Me:

      Who created of the AltUI graphical user interface for the home automation system Vera.

      Names two different people - mmmm.

      Regardless very impressive - give it a few more years.

      General Discussion
    • Disabled groups in reactions

      tunnus

      MSR tooltip says that "disabled groups are ignored, as if they did not exist (conditions don't run)".

      Just want to clarify if it's by design that actions beneath disabled groups should run? They do run, but intuitively I was expecting them to be disabled as well.

      Running the latest build under Docker.

      Multi-System Reactor
    • Any interest in a Subcategory for Homebridge?

      parkerc

      Being an iPad/iPhone user, I use Homebridge for a number of things. Although it runs completely independently from my main Vera home set up.

      Is anyone else using Homebridge and if there is enough interest would a subcategory be of use ?

      Software
    For those who registered but didn't received the confirmation email, please send an email to support@smarthome.community with the email you used
    • Profile
    • Following 0
    • Followers 19
    • Topics 33
    • Posts 2257
    • Best 768
    • Controversial 0
    • Groups 1

    toggledbits

    @toggledbits

    Author of Multi-system Reactor and Reactor for Vera/openLuup, DelayLight, Switchboard, SiteSensor, AutoVirtualThermostat, VirtualSensor, YeeLight (Vera/openLuup), SockProxy, Submasters, LuaView, Emby, IntesisWMPGateway, Rachio, VenstarColorTouch, and a few others. Current maintainer of Sonos and DeusExMachinaII.

    1162
    Reputation
    918
    Profile views
    2257
    Posts
    19
    Followers
    0
    Following
    Joined Last Online
    Website www.toggledbits.com/ Location Greater Atlanta Area, Georgia USA

    toggledbits Unfollow Follow
    Global Moderator

    Best posts made by toggledbits

    • RE: Vera account suspended for a 1000 years

      I was just thinking, these forums remind me of my earliest days working in startups, when you showed up for an interview and the furniture was clearly from a local thrift shop, the coffee station was a folding table or plywood over two saw horses, and your interview was conducted with all parties in jeans and a t-shirt. In those days, the focus was strictly on the work and bringing something exciting into the market. People of every history and skill were brought together. The CEO worked right next to you and could be seen cleaning the office's only toilet on a Friday night before he went home. And he was there on Saturday, and on Sunday, because we only worked on days ending in "y".

      These forums are a refuge. It's a place where technical discussion can lead over corporate policy and the pressure to sanitize and control the view. It's a place where we can take a wide view of the HA market, and not be beholden to one product. We can share success and failure with, and our adulation or bewilderment for, any product in the space. We talk about bugs and needs and challenges. We get work done. We get work done for each other.

      This is shaping up to be a really fun community, and I'm excited to be involved. The direction is forward. Onward!

      posted in Vera
      toggledbits
      toggledbits
    • Release 1.0.0

      Well, it's July 19th, and as previously advertised, Reactor (Multi-System, aka MSR) has been published at release 1.0.0.

      Docker images are on DockerHub, and download package for bare-metal installs is available at https://reactor.toggledbits.com/download/

      Those of you with access to the Mantis Bug Tracker for the project, please continue to use it, particularly if you stick with the "latest" docker image tag (which will continue to be updated periodically, as will the bare-metal tarball). Feel free to open issues there on behalf of other users who do not have accounts if it seems appropriate.

      posted in Multi-System Reactor
      toggledbits
      toggledbits
    • RE: Finally gave up on my Ezlo Plus

      @perh UI stuff is big on my mind these days...

      6zfcgp.jpg

      posted in Blogs
      toggledbits
      toggledbits
    • RE: Vera account suspended for a 1000 years

      Jeeez, he's still ranting. Have any of you ever heard of "confession by projection"?

      Edit: It's time to bring the temperature down over there. We all know who we're dealing with. We've made our point. Thank you all who have chimed in on my behalf as well, and offered words of support here. I'm not leaving until he kicks me off. But it's time to let this one die out, cool the temp and let the forum get back to the business of the community. His anger on display won't change anything anyway; the market will sort him out, not me or anyone else here. For myself, I'm getting on with the business of building tools, and if a single-digit percentage of people use my work, I call that a pretty good day.

      posted in Vera
      toggledbits
      toggledbits
    • Merry Christmas/Happy Holidays

      Just wanted to wish everyone a very Merry Christmas (or Happy Holidays, if that's your preferred salutation, or...?), and also a very happy, healthy and prosperous New Year 2022.

      posted in General Discussion
      toggledbits
      toggledbits
    • Category Topic Guide -- Read Before Posting

      Everyone:

      The quality of questions is a common complaint among those of us that provide "support" for things that we build and offer. As evidence of that, I'll direct you to this post over on the Home Assistant community, which apparently itself was inspired by a similar post in the OpenHAB community.

      It opens by explaining the obvious: they are volunteers (as am I), the ratio of supported to supporters is high (i.e. there are far more people asking for help than people providing it), everyone's time is valuable, and it's actually disrespectful of people's time to not put up front effort into your questions and structure them in a way that speeds the resolution process along. The common sense of this should be obvious: if you have a problem or question for which you need a fast answer or solution, should you not then give as much information as possible so that the first reply could be the answer, rather than being only the first of what becomes a back-and-forth exchange that could take hours or days to conclude?

      So, I am shamelessly plagiarizing the Home Assistant post for my guidelines here, as it is a good summary of both the ubiquitous problem contributors face in these environments, and what is generally needed to make things more manageable and agreeable. I will say, this is a great summary, and it should be applied everywhere you post, not just here. I'm sure everyone here and everywhere reading your posts, not just the contributors, will appreciate it.

      Here we go...

      Language

      I'm opening with this because the Hass post opens with it, but it hasn't been an issue here yet, so simply for the sake of completeness: support here is given in English. Please make your posts in English, if you can. If you can't, please make your post in your preferred language, but start it with a request to the group for a translation; maybe someone can/will help. We'll try web-based translators, too, of course, but technical language is rarely their strong point. This is one of many areas where community help really makes the experience for everyone.

      Try Search First

      As the product matures and the community becomes increasingly adept with it, it’s increasingly likely that your question has been asked and answered already. If you search the forum, you may find an answer and save yourself a lot of time. It may not be a perfect answer to your question, but it could get you close enough to start.

      The forum search here has a tendency to default to "Titles" (as in, search only in post titles), which is a bit restrictive, so remember to expand your search to "Posts," but from there, hopefully, you'll find something useful.

      Try to search only for what is the core of your question - the error message text/keywords (without your specific data), component or add-on name, the operation you want to perform, etc.

      Try the Documentation

      Every version of Reactor has a "Manual" link in the UI's left navigation that will take you to the locally-installed, version-specific documentation. There is also an online version here, but it may document changes and new things that were not available in the version you are using, so be careful there.

      Be Up To Date

      Before reporting an issue, be on the latest release. If you are not on the latest release, upgrade to it and try again before posting. If you post and are on an earlier release, it's almost guaranteed that the first thing you'll be instructed to do is upgrade to the latest release.

      New Topic Guidelines

      If you haven't found anything in Search or Documentation, then make a new topic, following these guidelines:

      If a search or your casual reading brings you to a topic/post is somehow similar to, but not exactly, your question, it's better to start a new topic and link to the similar in your introduction than it is to post a reply on the topic you found. This is especially true if the topic you found has gone stale and hasn't had a reply in months or years.

      A good opening (head) post a new topic will have most, if not all, of the following:

      • A concise title;
      • Details of runtime environment (Reactor version, platform info);
      • If your question is related to a hub/controller, the type of controller and its running software or firmware version information;
      • A complete description of your objective;
      • A description of your approach/solution/implementation so far (what you did, how it's intended to work), and what isn't meeting expectations;
      • Show the work.

      Let's look at the details of that:

      Title. Having a good topic title is essential. It should summarize your post so that without even opening it people can have a good idea of what it’s about. A good title generally:

      • Includes the unique part of the error you’re getting (redact specifics of your system, e.g. device IDs);
      • Contains the integration name, condition or action type, etc.;
      • Describes the thing you’re having an issue with;
      • Is emotionless.

      Examples:

      • Good: Action runs before delay action completes
      • Bad: Timer not working
      • Ugly: Problem/Need help
      • Good: Hubitat - Not able to perform dimming.set on Zooz switch
      • Bad: Can't control Zooz switch
      • Ugly: Switch problem

      If you’re having a problem writing a good topic title, leave it for last — once you’ve written the whole question, it might be easier to write a summary title for it.

      Describe Your Runtime Environment. It doesn't matter if you did it on a post last week, yesterday, or two minutes ago, every post should include a description of your environment, because I don't keep your system configuration in my head, and future readers will need to know. There are too many people and too many details for me to remember those things, anyway. So each post should include:

      • What version of Reactor you are using (upper-right corner of UI);
      • What OS your Reactor is running on (Ubuntu, Windows, Synology DSM, Raspbian, etc.);
      • How you installed/run Reactor: bare metal, Docker, etc.;
      • Specifics of any hubs and devices involved (manufacturer, model, software/firmware versionetc.) in the issue.

      Example: Reactor 21308-afecb92a; docker on Synology; Hubitat or Ver 21262; Raspian bare-metal (RPi4); Vera 7.32; Fibaro FGZ-712

      Describe the objective, not the problem with your implementation. It’s all too easy to fall into the trap of the XY Problem. If you describe your objective first, then others can understand what you’re trying to achieve. Remember, your objective is not a description of how you're implementing your solution, it's a description of the problem you are trying to solve with your implementation.

      • Good: I am trying to get an outdoor light to be on from the day after Thanksgiving through the end of the year.
      • Bad: I'm trying to figure out a condition to detect the day after the fourth Thursday in a month.
      • Ugly: The date condition in the screen shot below doesn't work.
      • Approaching Crime: I tried X and it didn't work (and that's the entire substance of the post).

      The first description is (much) better not just because it's concise about timing, but also complete: it lays out the entire problem, not just the one part of it that's giving you trouble right now. Often, good solutions will vary based on the full understanding of the objective (imagine trying to help someone solve the problem of getting fresh air into a large space if they didn't bother to tell you they were building a submarine). It is confusing to other readers and frustrating to helpers when you focus on one step, and when that's resolved, you then add "OK, and now it also needs to...". In the worst case, it can make the entire discussion prior useless.

      Show Your Work. Think mathematics class in school: you got no credit for having the right answer if you didn't show how you got there. Worse, if you're sure you have the method correct but you got the wrong answer, nobody could see anything to help you figure out why, including yourself. A big part of the completeness of your response is showing what you've done to try to address it:

      • Describe (and show) what you’ve tried, and what the problems were;
      • Almost every question about rules or reactions needs to have accompanying screen shot(s) showing the rules and/or reactions you've built; if your description says "I made a rule/reaction that does X", you need to show it; if you say "I tried to do X but it didn't work", you need to show what you tried to do, and you need to explain what you expected, what happened, and how that didn't meet your expectations;
      • Check the logs, and post log snippets if you find something you think is relevant;
      • Link to some other threads that you’ve found, and tried, and explain why they didn’t help you.

      If you haven't tried anything because you're not sure where to begin, the best way to learn is to experiment. Embrace failure, because it's a great learning tool. Remember you are playing with switches and lights, not launch codes for nuclear missiles, so aside from getting "that look" from your spouse, errors are unlikely to have serious consequences.

      This also seems a good point for me to offer this: I wrote Reactor as a tool for you to use to solve your automation/logic problems, not as a tool for me to use to solve your automation/logic problems. I am going to increasingly leave logic-only posts that don't involve bugs or specific Reactor operational questions to the community for response. Having me answer every question doesn't improve the ability of the group; that needs to change.

      Make good screen shots. If you screen shot your entire display and post it, scaling and downsampling will make it unreadable. If you zoom out your window/browser/screen to get everything in one image it will not be readable. Before taking a screen shot, un-maximize your window and reduce it to a reasonable size, and then screen shot just the window, or better still, grab the relevant rectangle where the action is (but remember, context is important, so be wary of over-cropping — a screen shot of a field with an error flag that doesn't include the condition or action type is probably over-cropped). Do not screen-shot code, log snippets, or formatted text like configs — please use fenced code blocks and paste the real code/data/text (see Format Posts Properly below).

      Make good log snippets. When posting logs, always post several dozen lines before anything you find relevant, and a few lines after. Context is important. Think crime scene: it's much easier to determine what happened when a witness describes it than it is to show up to find a dead body on the floor and nobody around. All of the events and messages leading up to the entry that drew your attention may contain vital clues about what was going on to get to that condition. It is also often useful to post (in addition) the startup messages for the most recent restart of Reactor. Do not screen-shot log snippets — post the actual text in a fenced code block (see Format Posts Properly below).

      Explain Your Work. It is a nightmare to see posts that contain pages of screen shots of rules and reactions, and yet have no explanation of how they are intended to solve the problem. Do not assume that just because we can read every rule and action, we can understand what that means for your system or how you're thinking about the problem and solution. With your screen shots, provide an explanation of what everything does along the way, why things are done the way they are, and what you think they are intended to do.

      Format posts properly. The forums are a tool, and like any tool, you should learn to use it properly if you're going to use it frequently. Learn how to format code, inline and blocks, and use the fenced code block formatting for all code and code-like text (config/YAML, JSON, etc.) and log snippets. Improper formatting can hide errors, or make them more difficult to see. Here's a cheat-sheet for Markdown formatting; it's easy to use fenced code block formatting for code blocks and log snippets.

      Redact personal information. Please remember, when posting logs or screen shots, to redact any personal information. This includes serial numbers, API keys, email addresses, lat/long of your home, etc. Remember you are posting this stuff into a public forum, to be captured by search engines and Internet archivers. Forever.

      Make sense. Don't let your haste to get your question asked overwhelm good communication. Re-read your post and make sure you've addressed all of the above, and that the post is organized and makes sense. In particular, watch your antecedents. I can't tell you how many "I have two switches but when I turn it on the status doesn't change" posts I've had to straighten out before I can even start guessing what the problem is.

      Use (keyword) tags. We're all not using enough keyword tags (full disclosure: I didn't even know they were possible in these forums until recently). Tags can help the search a lot. Common tags may be zwave, hass, hubitat, conditions, reactions, expressions, etc. Hubs, device types, condition or action types are all good candidates for tags. Don't use MSR, msr, or reactor as a tag unless you are posting outside of the Multi-Hub Reactor category; it isn't necessary. Everyone understands that the Reactor category contains Reactor topics/posts, and search lets you limit its breadth to specific categories, so the extra tags are just redundant. In this forum's software (NodeBB), you can enter tags in the bottom of the composer when writing/editing your topic/head post.

      Don't tag people/leads in the head post. If you are starting a new topic and writing the opening post for it, and you begin it by tagging me (or whoever the lead(s) is(are) for whatever category), it comes across as bad manners and demanding of an answer. I don't know of any forum in which the category moderators aren't subscribed to their categories (I certainly am), so notifications of new topics go out automatically and such tagging is redundant.

      Don't DM product questions. If you have a product question or problem, odds are someone else has or will have the same question/problem at some future date, so having the conversation recorded and searchable in the public forum threads is useful (and respectful of the time invested to help you).

      Fix your topic head post. If you are asked to revise your head post because it didn't meet the above guidelines, please edit/correct the head post itself, don't post an add-on reply down below in the thread with the additions or corrections. It's important that the head posts in each topic are high quality and meet these guidelines.

      Replies and Discussion

      Don't non-answer or distract. If someone asks how to do something in a particular way, unless you are certain that it can't possibly be done the way they are asking, don't reply with an answer that doesn't address the method.

      It's sometimes the case that when you feel a need to answer with a different method than OP has inquired about, OP's question/post is posing an X-Y Problem, and in this case, it's likely the post title and description are poor (asking about method rather than goal is a clue), so address that first (e.g. "What is it you are actually trying to accomplish?"). Then you'll have a perfect opportunity to point out different methods.

      Don't "Me Too". Don't reply to just say "I'm having this problem too." You can do that if you have additional information to offer that may help in isolating a problem; that's always welcome. But if all you're saying is "me too," that's not really useful and doesn't contribute to the discussion/solution.

      Don't use a non-contributing reply as a way to start watching a thread. You may find yourself interested in a thread and want to be notified when there are replies. The bad "Facebook way" is to reply "Following..." (or, again, "me too") in the thread, which makes the forums automatically subscribe you to the thread. It clogs the thread with useless replies. The preferred way is to use the "bell" icon button in the topic header to set a watch on the thread.

      Tag people in discussion only when it's relevant to call their attention. Personal tagging can and should be used when mentioning others to thank them for earlier thread responses (i.e. when they are already part of the thread discussion), or add them to the discussion as a link perhaps to another thread on a similar issue going on at the same time, etc. But tagging someone to add them should be considered carefully: consider how welcome that call for attention may be, and how they may feel about the relevance of the discussion or their involvement in it.

      Don't hijack or wander. Hijacking or thread-jacking is making a reply that takes the thread off topic. Instead, start a new thread and link to the related thread if there is a relevant connection.

      Solved It! When your problem is solved, whether you solved it yourself or someone else did, please mark the head post title [SOLVED]. Ideally, also add a link to the end of your head post to the solution post: you can right-click on the date/time of the solution post and choose "Copy Link..." to get the link, and then paste at the end of your head post Solved here: <paste link>. If you solve your own problem, please make your own post describing what you did (and link to that in the head).

      DO NOT FLAIL! If I am working with you on troubleshooting/investigation, asking you to try specific things and give me the results, do not start random experiments, change your entire approach to the problem, make changes I didn't direct, delete things, etc. At that point, I am troubleshooting and need you to be my hands and eyes. If I get the impression that you are making a moving target for me to hit, I'll just stop working with you on it. This is such a serious matter for me that repeated instances may affect your future support.

      __________________________________

      Inspired by this awesome post in the Home Assistant forums, which itself was inspired by this awesome post over in the OpenHAB forums.

      Updated 2023-04-03

      posted in Multi-System Reactor guidelines
      toggledbits
      toggledbits
    • Change in Plans (Don't Panic)

      Everyone, I've had a change in thinking.

      As many of you know, I had decided to not build an MSR interface for eZLO's new controllers, for multiple reasons, not the least of which was that I had chosen not to use an eZLO hub in my future HA. I am currently straddling three hubs: Vera, Home Assistant, and Hubitat. I am actually very much enjoying the flexibility this has provided. But these three hubs are enough for the moment, and when the venerable Vera Plus on which my house has operated since 2017 dies, I will likely just move the rest of my ZWave devices to the other hubs and reduce by one.

      Another reason for my previous decision was the risk of fluidity/instability in the eZLO APIs. Since this is first generation work, and even now as they approach the three-year mark on development and are still in "beta" with much functionality still incomplete or missing altogether (plugin UI framework?... anyone? anyone?), it stands to reason that, like all projects in this phase in particular, choices are made that need to be revisited. To be fair, Hass and Hubitat are not immune from this either, even as much more mature products with greater market penetration. In any case, I've demurred because of the high perceived risk of change and breakage, and didn't want to put myself (again) on the critical path of my own user base waiting for me to catch up. I accept now, however, that events like this are just part and parcel of the environment in which I've chosen to work. As I said, if it's not eZLO changing something, it's going to be Hass, or something else. I haven't had a breaking change hit from the Hubitat side yet, but it's probably just a matter of time. Just as I seek to improve my work, they must seek to improve theirs.

      The upshot is that I've decided to write an eZLO interface, and I've been working on that for a few days and now have a working prototype running. It works with the few devices I have available for it, and there's a lot that's assumed and untested about all the others. Think back to March, when MSR was first released -- the process of going through and stabilizing these interfaces under all the different external conditions, with devices in your environments that I don't, and sometimes cannot, have -- it takes time. Drilling out all of the details of device behaviors and data, and how each hub handles them differently, takes time. But it's going to be a reality. Aside from this, reading the other forums makes me realize just how much this is needed, if only because there appears as yet to be no articulated concrete plan (e.g. words beyond a promise with no date) to support easy migration from a Vera to an eZLO. MSR touts itself as a tool to assist such migrations between hubs. An eZLO interface must exist.

      To set expectations: you'll see the first version of this interface in a build in the next couple of weeks. It will be an add-in. Like MSR itself, I will be limiting the initial audience, and those of you that participate in the early use and testing will be asked to provide lots of diagnostics and feedback (so please don't ask/participate if you're not willing and able to put in the time). It's brand new, unfinished work; there will be lots of bugs, and lots of holes, and it's going to take a lot to get them all squashed and filled, respectively.

      Based on what I've learned so far from this project, I also want to forewarn you that it may include access to my cloud infrastructure for automatic logging (to make our mutual efforts to examine problems easier and faster), at least during the early stages. At the moment, MSR has no hard Internet-access dependencies, so this is a change for this interface work.

      Also, I probably will ultimately be charging a modest monthly or annual subscription for the eZLO interface, which is a change from policy and practice to date. The amount of effort the project has demanded and can demand in future makes it necessary that I consider a business model. I know that gives some pause, but it should also give you confidence that I am thinking of a long-term future. But, those of you who, as of this writing, hold active accounts on the MSR bug tracker and have participated so valuably in the testing and improvement of MSR, are grand-fathered in to a perpetual (personal/non-commercial use) license to MSR and this interface (no fees, at least for what parts are produced by my hand; I cannot control what others may choose to do if/when third party development takes root). I am considering extending that benefit to everyone who has donated to my projects from the start to date; that is, including those who supported Reactor for Vera, without which MSR would never had been born.

      I can probably predict from these forums and others who the active eZLO users are going to be, but if you want to work with me on it, please let me know by reply here. I will be relying on you heavily, because I am not going to be a big consumer of the hub, so a lot of the work will require data collected from you and your hub and investigative work on that evidence, rather than first-hand experience and witnessed events in my own environment. But I'm confident it will work, as much gets done this way already, and investing in more and deeper troubleshooting tools is always a good investment.

      Thanks to all of you who have supported this project. Onward...

      posted in Multi-System Reactor
      toggledbits
      toggledbits
    • Fun Stuff

      In the background of other work, I've been putting together a build system for the OpenWrt version that Ezlo is using on the Plus. Job done. I can build pretty much any package, which may come in handy some day.

      As a test of that, I thought, why not build nodejs... and you know where that leads, right?

      It took some doing. There are a lot of dependencies, and the errors you get when the dependencies aren't met correctly can be cryptic and took quite a bit of research and experimentation to resolve... weeks, in fact, over a couple of hours here, a couple there.

      But it's done and I now have Reactor running on an Ezlo Plus.

      I'm not sure what the long term utility of this might be. Since the new Ezlo philosophy is to upgrade your system automatically on reboots, and so far the upgrades have wiped substantial parts of the file system in my experience, this could be a non-starter as a platform — you wouldn't want your automations to get blown off the machine every time Ezlo upgrades firmware (because you don't know when that's going to be, and Murphy says it will be while you are on vacation with no remote access). But, if there is some place it can be tucked away safely, or if, as probably should be demanded by the user community, updates become elective and user-driven, it actually makes a nice Pi-ish platform to run on.

      On to the next skunkworks project...

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

      Just an FYI for everyone, I'll be on holiday from tomorrow March 10 through March 19, and I'm leaving the laptop on the shelf at home for this one. I can answer emails and forum posts, but I won't likely be checking more than once a day, and I won't doing builds or any bug fixing while away. See you all on the other side!

      posted in Multi-System Reactor
      toggledbits
      toggledbits
    • New toys to play with

      Everyone,

      As a side project, building on some deep innards borrowed from Reactor, I have released two new projects (unrelated to Reactor). Both are published on npmjs (for installation via npm), and on GitHub.

      1. ezmqtt — a standalone app that acts as a conduit between Ezlo hubs and MQTT. It's published on npmjs.com and on Github.
      2. node-red-contrib-ezlo — Node-RED nodes (installable package) for Ezlo hubs. It's published in the Node-RED Nodes Library, at npmjs.com, and on Github

      Why? Because choices are a good thing.

      There are docker containers available for ezmqtt, but I haven't finished the work there, so they may not be quite ready for prime time; but feel free to test/play if you want.

      posted in Software
      toggledbits
      toggledbits

    Latest posts made by toggledbits

    • RE: Home Assistant add-on

      @kellyjelly32 said in Home Assistant add-on:

      After a reboot they are gone. The whole page with global variables is empty.

      OK, that's beyond what I would have guessed from your initial description. I interpreted you to mean that their values are not preserved and are being updated when Reactor starts, but this condition you describe is far beyond that and definitely not the way Reactor is intended to work. That suggests to me that the storage data for at least global expressions, and maybe more you haven't yet detected, isn't being written properly. This could be the fault of a corrupted storage file (i.e. the expressions.json file in the storage subfolder), or improperly configured storage entirely (i.e. the bind mount needed isn't properly set up), or the shutdown by Hass, when it is asked to restart the Reactor add-on, shuts it down in some disorderly way to Reactor/nodejs, so it can't write the storage files (i.e. it gets killed rather than signalled to quit, so it can't perform its cleanup and tidy exit function). If it's the last case (bad shutdown), then you'd probably also notice other changed objects (reactions, rules) are not preserving their changes as well.

      If the file is corrupt, you would find logged errors that look like this:

       <SingleFileStrategy:ERR> [SingleFileStrategy][SingleFileStrategy#/home/pi/Documents/MSR/storage/expressions.json] error reading /home/pi/Documents/MSR/storage/expressions.json: [SyntaxError] Unexpected token { in JSON at position 1 [-]
      

      Check for these messages at startup, and any time you attempt to navigate to the Expressions page in the UI. You may also see similar messages at shutdown. If there are messages at shutdown, as well as messages for other files in storage, then it suggests that the storage isn't properly configured (issue with the bind mount, or file permissions in the mounted directory, for example). In any case, if the file is corrupt, you can just remove it and restart Reactor (and then rebuild your expressions; if you are handy with JSON, you could try to repair the file).

      But yes, in a normally functioning Reactor system, Rules, Reactions, and Expressions that you create should be saved and return after a restart/reboot as they were before the restart/reboot. Something is definitely amiss there, but it could just be a local configuration issue, not an add-on problem (I would assume some of the other folks using the add-on are consumers of global variables and we haven't seen reports like this from others as yet).

      Edit: storage volume (disk) full is also a way to get corruption of storage data and/or unsaved changes.

      posted in Multi-System Reactor
      toggledbits
      toggledbits
    • RE: DelayLight replicate in MSR

      This post needs to be updated/enhanced to meet the posting guidelines.

      posted in Multi-System Reactor
      toggledbits
      toggledbits
    • RE: Home Assistant add-on

      @kellyjelly32 said in Home Assistant add-on:

      "global expressions" are not persistent

      Not sure what this means. Can you explain in more detail?

      @kellyjelly32 said in Home Assistant add-on:

      "global reactions" survive a reboot

      Reactions are stateless. There's no need for them to "survive a reboot" because there's nothing to survive. Again, not sure what this means, and detail would be helpful.

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

      MQTTController 23135

      • In action payload, force conversion of all data types to string for "raw" output, rather than assuming result of expression is a string (although docs say to do that, it's just too easy to omit, and too easy to change it so the requirement is moot).
      • Add parameter: name value form to action payload definition to draw payload value from the named parameter without the need to use an expression (this follows the implementation of action definitions in other Controller instances as well). That is, you can specify, for example, parameter: level instead of using expr: parameters.level (assuming the parameter value requires no scaling or other modifications to be compatible with the device). [docs]
      posted in Multi-System Reactor
      toggledbits
      toggledbits
    • RE: Sending numbers as payload type in actions enhancement

      OK. I can address the error message. Best of both worlds.

      posted in Multi-System Reactor
      toggledbits
      toggledbits
    • RE: Sending numbers as payload type in actions enhancement

      You can just send it raw, which has the same effect as your (unnecessary) code addition. In fact, you can just send it JSON, too, since a JSON-ified number is just the number as a string, same-same. Alternately, you can also use:

          payload:
            expr: "str(parameters.setpoint)"
      
      posted in Multi-System Reactor
      toggledbits
      toggledbits
    • RE: JSON payload in MQTTController entities actions (+ reverse color mapping to RGB)

      MQTTController 23116 is now available for download; it has hsltorgb(hue,sat,lev) and rgbtohsl(r,g,b) functions available in expressions.

      posted in Multi-System Reactor
      toggledbits
      toggledbits
    • RE: JSON payload in MQTTController entities actions (+ reverse color mapping to RGB)

      @mgvra said in JSON payload in MQTTController entities actions (+ reverse color mapping to RGB):

      So it is this implicit parameters object that contains the value (level) to be set.

      Yes, parameters will contain the values of any parameters the action requires/defines.

      @mgvra said in JSON payload in MQTTController entities actions (+ reverse color mapping to RGB):

      In the case of step dimming, is this the notation?
      expr: > { "brightness": parameters.step * 255 }

      Well, from the look of it, no. I think your device is going to set the brightness to whatever value is in step, not increment or decrement the brightness by that amount. If your device offers another topic to increment or decrement, you will need to use that instead.

      If your device doesn't have up/down brightness topics, you need to emulate them by using what we already know about the device. The entity has the current brightness level on it, so emulating step dimming is a matter of doing the math. Here's an example with fixed 10% up/down. The entity object is loaded with the action's subject entity, so we can access the current dimming level using its attribute:

      actions:
        dimming:
          up:
            topic: "zigbee2mqtt/%friendly_name%/set"
            payload: 
              type: json
              expr: >
                { "brightness": min(1, entity.attributes.dimming.level + 0.1) * 255 }
          down:
            topic: "zigbee2mqtt/%friendly_name%/set"
            payload: 
              type: json
              expr: >
                { "brightness": max(0, entity.attributes.dimming.level - 0.1) * 255 }
      

      Note that the dimming capability does not have any parameters for the up and down actions.

      posted in Multi-System Reactor
      toggledbits
      toggledbits
    • RE: JSON payload in MQTTController entities actions (+ reverse color mapping to RGB)

      @mgvra You're on the right track. For an action like dimming.set, where a JSON payload is to be sent, you set the json type as you've done, and then you just need to make sure that the payload value is an object.

      actions:
          dimming:
            set:
              topic: "zigbee2mqtt/%friendly_name%/set"
              payload: 
                type: json
                expr: >
                  { "brightness": parameters.level * 255 }
      

      That last line evaluates to an expression language object data type containing a single key brightness whose value is the result of the subexpression, which in this case is the parameter value level given to the action scaled up to the device's units (I guessed; do what works here).

      The important thing to realize here is that the expression is producing an object, not a string that looks like JSON. The type: json flag will cause MQTTController to convert the object to its JSON representation, whatever that requires.

      Don't forget you can set MQTTController's log level to 5 while doing this work to troubleshoot what you are doing and see more clearly what is ultimately being sent.

      I do have functions for converting between HS(L), RGB, and XY. Currently they are only available to HubitatController, but I can easily extend them to MQTTController as well. The trick there, however, is that your device's implementation is the same (e.g. for HSL 0° is red, 120° is green, 240° is blue, etc.). There's a de facto standard, but some devices have their own way.

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

      Reactor build 23114

      • Conditions: add is NOT TRUE and is NOT FALSE operators. The is NOT TRUE operator (for example) is unlike the is FALSE operator in that, if the tested value is null, the is NOT TRUE operator result would be true, while the is FALSE operator result would be false. This distinction facilitates some tests where it may be desirable to handle null as equivalent to either true or false without having to provide an additional, separate is NULL condition (and possibly an enclosing OR group).
      • DynamicGroupController: document group actions; this makes it an official feature (was experimental).
      • Engine/Rule: Clean up a misspelled method name.
      • InfluxFeed docs: update supported and recommended versions. [doc]
      • HubitatController: Tweak reconnect timing decay (allow for longer decay when hub cannot be contacted for an extended period).
      • Reactions: Clarify what "Disabled" means in the constraints of a Group action (incl. Repeat...While) of a reaction. It does not disable the actions in the group. The disable flag applies to the constraint conditions only, having the same effect as it would on rule-based triggers and constraints (i.e. it becomes as if the constraint conditions do not exist). [docs] and [docs]
      • HassController: Bless Hass to 2023.4.6
      posted in Multi-System Reactor
      toggledbits
      toggledbits