Multi-System Reactor

691 Topics 6.8k Posts
  • 0 Votes
    6 Posts
    615 Views

    Interesting, so I found Sam Cater's blog, the source for your first link. That was necessary to build the image for RPi because docker would not even build the container on Alpine 3.13 or 3.14 without the patch. I did not anticipate that effect of the patch would penetrate the container, but I can see how it could.

    I'm not inclined to back off back to 3.12, though. As your link points out, newer versions of Grafana and Mosquitto are affected in the same way, and I'm sure the other tools mentioned will soon follow. We're all in the same boat. So, I'm going to incorporate this step into the installation instructions for docker container users on Raspbian Buster.

  • 0 Votes
    7 Posts
    188 Views

    I already have the Recently Changed Entities issue fixed. I'm not going to release until later today. There is another issue working on this release, and I have some experimental work ready for you all to look at as well.

  • [Solved] Column width for Entities in MSR UI

    6
    0 Votes
    6 Posts
    191 Views

    Ultimately I'd like to make these all adjustable, but that's going to take a good bit more work. I tried, and it wasn't a quick and easy job, and I was mostly focused on the grid for the Status on the UI side of this release. More to follow...

  • 0 Votes
    9 Posts
    147 Views

    @toggledbits Sorry - your support is too on the ball 👍 - I had deleted the post as I realized it was non sensical and created a new post

  • 0 Votes
    3 Posts
    83 Views

    @toggledbits ok, done.

  • Trying to setup InfluxDB breaks my MSR install

    15
    0 Votes
    15 Posts
    286 Views

    FYI only/anecdotally: I am using both 1.8 with Grafana and 2.0 with it's native graphing. Grafana is subtly prettier, for sure, but I'm not sure it outweighs the convenience of having one less piece of software to install. The only thing I haven't verified for 2.0's graphing is that you can do equations/functions as additional traces. I do that on my temp+humidity graphs in Grafana to compute the dew point; it didn't jump out at me how to do it in 2.0's native graphing, so I owe that a few minutes at some point, but at the moment, I'm trying to button up a ton of work to roll out in a new (MSR) release.

    9ee26b8a-88c4-4918-9eba-f60a04129b2a-image.png

    64755938-b468-458f-80ac-adbf793d2659-image.png

  • "Plugins"/firm-coded rulesets in MSR?

    10
    0 Votes
    10 Posts
    293 Views

    @perh I've been using MSR for my HVAC since the beginning. I use what I've dubbed "Arm For" rulesets.

    3243d41d-b31e-4609-acda-fbca91415d76-image.png

    3c57fe00-6b66-42a5-aa6d-910c085b3cea-image.png

    These "control" nothing. The individual rulesets referencing these do that.

    baed7d20-1862-4522-b854-d97b0db24ad3-image.png As the Ambient API will sometimes drop I have a backup source thru OpenWeatherMap, hence the trigger re the Ambient being null.

    Is there a better way? Probably. This has worked wonderfully for years (starting with RFV and moving to MSR.)

  • 0 Votes
    1 Posts
    208 Views
    No one has replied
  • 0 Votes
    10 Posts
    268 Views

    Ah, yes... if you need to reuse the fetched entity several times, it's definitely better to use a do...done block as the loop body and keep the result of getEntity() in a local variable, so you're only doing that fetch one time. You can then use the local variable as many times as needed... a cache of sorts. I'm with you...

  • 0 Votes
    1 Posts
    95 Views
    No one has replied
  • Vera plugin devices just appear in MSR?

    6
    0 Votes
    6 Posts
    182 Views

    OK thanks guys for the information appreciate it.

  • 0 Votes
    16 Posts
    380 Views

    Installed the new version yesterday along with the new guard and all is still fine this morning. Considering that it was failing very quickly before, I consider that issue fixed.

  • 0 Votes
    5 Posts
    663 Views

    For those of you encountering the same issue, after further testing, I stumbled across the fact that the Entity Id that must be used now is "select_preset_wled" versus "light_wled" as was the case before HA 2021.12. When selected, the service drop down should only come up with "select.select_option" and the corresponding option field needs to be populated with the name of the preset you created in WLED (not the number). Note: if you have multiple WLED's set up, your selectable Entity ID list would contain: select_preset_wled, select_preset_wled_1, select_preset_wled_2 and so on...all referring to each of the WLED lights not the actual presets of that light. Hope that helps....

  • 0 Votes
    10 Posts
    238 Views

    @toggledbits Just confirmation that this all did do what it was to do: I was still in my office and watched the xmas lights do their thing!

  • This topic is deleted!

    6
    0 Votes
    6 Posts
    39 Views
  • 0 Votes
    22 Posts
    733 Views

    Hi, it seems working ok. Thanks! If you need more infos to test, just tell me how I can produce them.

    L Bulb FibaroDimmer2 ezlo>device_61425874129e29124dfcd75e 0.65 7:30:07 PM dimming.level=0.65 dimming.step=0.1 energy_sensor.units="KWh" energy_sensor.value=11.3400001525879 power_sensor.units="W" power_sensor.value=6.90000009536743 power_switch.state=true x_ezlo_device.battery_powered=false x_ezlo_device.category="dimmable_light" x_ezlo_device.manufacturer="Fibaro" x_ezlo_device.model="FGD-212" x_ezlo_device.parent="" x_ezlo_device.reachable=true x_ezlo_device.ready=true x_ezlo_device.room="613e2024129e2912114c093b" x_ezlo_device.status="idle" x_ezlo_device.subcategory="dimmable_in_wall" x_ezlo_device.type_id="271_258_4096" x_ezlo_item.dimmer=65 x_ezlo_item.dimmer_down=0 x_ezlo_item.dimmer_stop=0 x_ezlo_item.dimmer_up=0 x_ezlo_item.electric_meter_kwh=11.3400001525879 x_ezlo_item.electric_meter_watt=6.90000009536743 x_ezlo_item.hw_state="hardware_failure" x_ezlo_item.load_error_state="unknown" x_ezlo_item.meter_reset=0 x_ezlo_item.over_current_state="unknown" x_ezlo_item.over_load_state="unknown" x_ezlo_item.power_surge_state="no_surge" x_ezlo_item.switch=true x_ezlo_item.voltage_drop_drift_state="unknown" x_ezlo_object.id="61425874129e29124dfcd75e" zwave_device.capabilities=null zwave_device.failed=false zwave_device.manufacturer_info=["Fibaro","FGD-212",null] zwave_device.node_id=27 zwave_device.version_info=null Capabilities: dimming, energy_sensor, power_sensor, power_switch, x_ezlo_device, x_ezlo_item, x_ezlo_object, zwave_device Actions: dimming.down, dimming.set, dimming.up, power_switch.off, power_switch.on, power_switch.set, x_ezlo_device.device_check, x_ezlo_device.set_item_value, x_ezlo_device.set_name, x_ezlo_device.set_room, x_ezlo_device.status_check, zwave_device.poll, zwave_device.reconfigure, zwave_device.refresh, zwave_device.reset_meters, zwave_device.set_config, zwave_device.update_neighbors

    another

    K Bulb Domitech ezlo>device_61423589129e29124dfcd756 0.65 7:35:42 PM dimming.level=0.65 dimming.step=0.1 power_switch.state=true x_ezlo_device.battery_powered=false x_ezlo_device.category="dimmable_light" x_ezlo_device.manufacturer="Domitech" x_ezlo_device.model="ZE27EU" x_ezlo_device.parent="" x_ezlo_device.reachable=true x_ezlo_device.ready=true x_ezlo_device.room="613e2020129e2912114c093a" x_ezlo_device.status="idle" x_ezlo_device.subcategory="dimmable_bulb" x_ezlo_device.type_id="526_19522_12596" x_ezlo_item.dimmer=65 x_ezlo_item.dimmer_down=0 x_ezlo_item.dimmer_stop=0 x_ezlo_item.dimmer_up=0 x_ezlo_item.switch=true x_ezlo_object.id="61423589129e29124dfcd756" zwave_device.capabilities=null zwave_device.failed=false zwave_device.manufacturer_info=["Domitech","ZE27EU",null] zwave_device.node_id=26 zwave_device.version_info=null Capabilities: dimming, power_switch, x_ezlo_device, x_ezlo_item, x_ezlo_object, zwave_device Actions: dimming.down, dimming.set, dimming.up, power_switch.off, power_switch.on, power_switch.set, x_ezlo_device.device_check, x_ezlo_device.set_item_value, x_ezlo_device.set_name, x_ezlo_device.set_room, x_ezlo_device.status_check, zwave_device.poll, zwave_device.reconfigure, zwave_device.refresh, zwave_device.reset_meters, zwave_device.set_config, zwave_device.update_neighbors

    another

    H Bulb Widom dimmer ezlo>device_6147578c129e29124dfcd814 1 7:36:56 PM dimming.level=1 dimming.step=0.1 energy_sensor.units="KWh" energy_sensor.value=0.651000022888184 power_sensor.units="W" power_sensor.value=2.47000002861023 power_switch.state=true x_ezlo_device.battery_powered=false x_ezlo_device.category="dimmable_light" x_ezlo_device.manufacturer="Unknown" x_ezlo_device.model="Unknown" x_ezlo_device.parent="" x_ezlo_device.reachable=true x_ezlo_device.ready=true x_ezlo_device.room="613e2012129e2912114c0938" x_ezlo_device.status="idle" x_ezlo_device.subcategory="dimmable_in_wall" x_ezlo_device.type_id="329_4628_2560" x_ezlo_item.dimmer=100 x_ezlo_item.dimmer_down=0 x_ezlo_item.dimmer_stop=0 x_ezlo_item.dimmer_up=0 x_ezlo_item.electric_meter_kwh=0.651000022888184 x_ezlo_item.electric_meter_watt=2.47000002861023 x_ezlo_item.meter_reset=0 x_ezlo_item.switch=true x_ezlo_object.id="6147578c129e29124dfcd814" zwave_device.capabilities=null zwave_device.failed=false zwave_device.manufacturer_info=["Unknown","Unknown",null] zwave_device.node_id=41 zwave_device.version_info=null Capabilities: dimming, energy_sensor, power_sensor, power_switch, x_ezlo_device, x_ezlo_item, x_ezlo_object, zwave_device Actions: dimming.down, dimming.set, dimming.up, power_switch.off, power_switch.on, power_switch.set, x_ezlo_device.device_check, x_ezlo_device.set_item_value, x_ezlo_device.set_name, x_ezlo_device.set_room, x_ezlo_device.status_check, zwave_device.poll, zwave_device.reconfigure, zwave_device.refresh, zwave_device.reset_meters, zwave_device.set_config, zwave_device.update_neighbors
  • This topic is deleted!

    Locked
    1
    0 Votes
    1 Posts
    11 Views
    No one has replied
  • 0 Votes
    9 Posts
    280 Views

    Master @toggledbits 🙂

    Following the line "I show you the way, I don't give you the transport":), the MSR indicates in Entities the time of the last device status change. Where is this information stored?

    e9bcef0d-fd5c-4e4a-b2fa-0ade8eeb52e7-image.png

    Use case: I want to monitor all devices, and the ones that are not communicating for more than 48 hours should know and take action.

    For sure there are some that can not even, because it would be a problem, then I create an exception list. But initially, I want to see everything that has not been communicated in 48 hours.

    The principle is almost the same as Hubitat's WatchDog APP, but I want to have my own, and not be dependent on Hubitat's communication or action. I also understand that it has more validity, because it is a way to ensure that the MSR is talking to all devices, and not only to Hubitat.

    Thanks.

  • 0 Votes
    5 Posts
    172 Views

    He's got a case-insensitive test going; it'll be fine. The problem arises mostly when you send a new mode to Hubitat... that's where you need to be careful and get the case correct.

  • 0 Votes
    19 Posts
    303 Views

    @toggledbits ok, thanks!

Recent Topics