Good morning,
I'm trying to figure out if there is a way to evaluate if a command was completed and retry if it did not complete.
I have 14 iBlinds 3.1 z-wave controllers in my home. 95% of the time, they work just fine. Occasionally, I'll get a blind that does not open on the first attempt. When I go into Home Assistant, and manually open or close the blind, it works.
I have 3 reactions set up for each room. One to open, one to close, and one partial open for sun glare. Each of them is set up as below.
5afc9924-4300-4718-9e23-8855c4a3a9fd-image.png
The reactions are set up to wait for 5 seconds before going onto the next blind, so the z-wave network doesn't get overwhelmed.
In addition, the set command to run the reactions has "Wait for completion" checked.
3919fc06-c1f1-4c49-bf95-716028d18a27-image.png
I also have a routine set up whenever a z-wave device reports as non-functional (dead), it'll get pinged to wake it up. This usually works to wake them up.
16df4bff-c733-4ec2-a55c-c964238ada3b-image.png
Appreciate any ideas to make this more reliable.
I'm running:
Reactor latest-24190-bd310acc, Bare-metal on Fedora WaveJSController [0.1.23326] Home Assistant: 2024.7.0I think this feature request could be accomplished with the use of two or more rules, but it would be great if there was a way to wait for an event or trigger to occur before continuing on in the reactions.
For example, I have a rule that will turn on some exterior lights if you arrive home after the porch lights have been turned off. Right now this rule randomly will turn off between 5-10 minutes after the person has entered the geofence. On some occasions this 5-10 minutes isn't long enough, say if you are unloading the car or something. I would like to kick off the reaction, but pause it part way through and wait for the door to close and lock, then continue it on. Hubitat Rule Machine has a "Wait for event" option, but I really want to keep all my logic within MSR.
Good morning,
I'm going through my ruleset this morning, trying to get away from haas>blahblablah entries and completely migrate them all to zwavejs>xx-0 entries where possible.
I have 3 Aeon MultiSensor 6 devices in my home, all USB powered.
When using Haas entries, I see an entry for hass>binary_sensor_guest_bedroom_multisensor_home_security_motion_detection, and motion_sensor.state (primary)
Screenshot 2024-07-25 at 8.25.53 AM.png
Under ZwaveJS, this entry appears to be missing.
Screenshot 2024-07-25 at 8.26.51 AM.png
From the Entities page:
battery_power.level=1
battery_power.since=1721910337433
binary_sensor.state=false
humidity_sensor.units="%"
humidity_sensor.value=46
light_sensor.units="Lux"
light_sensor.value=5
tamper.state=false
temperature_sensor.units="°F"
temperature_sensor.value=73.8
x_debug.dt={}
x_zwave_values.Basic_currentValue=0
x_zwave_values.Battery_isLow=false
x_zwave_values.Battery_level=100
x_zwave_values.Binary_Sensor_Any=false
x_zwave_values.Configuration_Automatic_Report_Group_1_Battery_1=1
x_zwave_values.Configuration_Automatic_Report_Group_1_Humidity_64=1
x_zwave_values.Configuration_Automatic_Report_Group_1_Luminance_128=1
x_zwave_values.Configuration_Automatic_Report_Group_1_Temperature_32=1
x_zwave_values.Configuration_Automatic_Report_Group_1_Ultraviolet_16=1
x_zwave_values.Configuration_Automatic_Report_Group_2_Battery_1=0
x_zwave_values.Configuration_Automatic_Report_Group_2_Humidity_64=0
x_zwave_values.Configuration_Automatic_Report_Group_2_Luminance_128=0
x_zwave_values.Configuration_Automatic_Report_Group_2_Temperature_32=0
x_zwave_values.Configuration_Automatic_Report_Group_2_Ultraviolet_16=0
x_zwave_values.Configuration_Automatic_Report_Group_3_Battery_1=0
x_zwave_values.Configuration_Automatic_Report_Group_3_Humidity_64=0
x_zwave_values.Configuration_Automatic_Report_Group_3_Luminance_128=0
x_zwave_values.Configuration_Automatic_Report_Group_3_Temperature_32=0
x_zwave_values.Configuration_Automatic_Report_Group_3_Ultraviolet_16=0
x_zwave_values.Configuration_Automatic_Reporting_Interval_Group_1=3600
x_zwave_values.Configuration_Automatic_Reporting_Interval_Group_2=3600
x_zwave_values.Configuration_Automatic_Reporting_Interval_Group_3=3600
x_zwave_values.Configuration_Automatic_Temperature_Reporting_Unit=2
x_zwave_values.Configuration_Battery_Level_Threshold=10
x_zwave_values.Configuration_Current_Power_Mode_65280=0
x_zwave_values.Configuration_Humidity_Above_Lower_Limit_32=0
x_zwave_values.Configuration_Humidity_Below_Lower_Limit_2=0
x_zwave_values.Configuration_Humidity_Change_Threshold=10
x_zwave_values.Configuration_Humidity_Recover_Limit=5
x_zwave_values.Configuration_Humidity_Sensor_Calibration=0
x_zwave_values.Configuration_LED_Blinking=0
x_zwave_values.Configuration_Lighting_Recover_Limit=10
x_zwave_values.Configuration_Lock_Configuration=0
x_zwave_values.Configuration_Low_Battery_Threshold=20
x_zwave_values.Configuration_Low_Temperature_Alarm_15_C=0
x_zwave_values.Configuration_Lower_Humidity_Limit=50
x_zwave_values.Configuration_Lower_Lighting_Limit=100
x_zwave_values.Configuration_Lower_Temperature_Limit_4294901760=320
x_zwave_values.Configuration_Lower_Temperature_Limit_Unit_3840=2
x_zwave_values.Configuration_Lower_Ultraviolet_Limit=4
x_zwave_values.Configuration_Luminance_Above_Lower_Limit_64=0
x_zwave_values.Configuration_Luminance_Below_Lower_Limit_4=0
x_zwave_values.Configuration_Luminance_Change_Threshold=100
x_zwave_values.Configuration_Luminance_Sensor_Calibration=0
x_zwave_values.Configuration_Motion_Sensor_Report_Type_to_Send=2
x_zwave_values.Configuration_PIR_Sensitivity=3
x_zwave_values.Configuration_PIR_Sensor_Timeout=20
x_zwave_values.Configuration_Recover_Limit_Temperature_Unit_255=2
x_zwave_values.Configuration_Report_Above_Humidity_Threshold_32=0
x_zwave_values.Configuration_Report_Above_Luminance_Threshold_64=0
x_zwave_values.Configuration_Report_Above_Temperature_Threshold_16=0
x_zwave_values.Configuration_Report_Above_Ultraviolet_Threshold_128=0
x_zwave_values.Configuration_Report_Below_Humidity_Threshold_2=0
x_zwave_values.Configuration_Report_Below_Luminance_Threshold_4=0
x_zwave_values.Configuration_Report_Below_Temperature_Threshold_1=0
x_zwave_values.Configuration_Report_Below_Ultraviolet_Threshold_8=0
x_zwave_values.Configuration_Reset_Parameters_101_103_to_Default_Values=null
x_zwave_values.Configuration_Reset_Parameters_111_113_to_Default_Values=null
x_zwave_values.Configuration_Reset_to_Factory_Default_Setting=null
x_zwave_values.Configuration_Selective_Reporting=0
x_zwave_values.Configuration_Sleep_State_255=2
x_zwave_values.Configuration_Temperature_Above_Lower_Limit_16=0
x_zwave_values.Configuration_Temperature_Below_Lower_Limit_1=0
x_zwave_values.Configuration_Temperature_Calibration_Offset_65280=0
x_zwave_values.Configuration_Temperature_Calibration_Unit_255=2
x_zwave_values.Configuration_Temperature_Change_Threshold_4294901760=20
x_zwave_values.Configuration_Temperature_Recover_Limit_65280=20
x_zwave_values.Configuration_Temperature_Threshold_Unit_3840=2
x_zwave_values.Configuration_Ultraviolet_Above_Lower_Limit_128=0
x_zwave_values.Configuration_Ultraviolet_Below_Lower_Limit_8=0
x_zwave_values.Configuration_Ultraviolet_Change_Threshold=2
x_zwave_values.Configuration_Ultraviolet_Recover_Limit=2
x_zwave_values.Configuration_Ultraviolet_Sensor_Calibration=0
x_zwave_values.Configuration_Upper_Humidity_Limit=60
x_zwave_values.Configuration_Upper_Lighting_Limit=1000
x_zwave_values.Configuration_Upper_Temperature_Limit_4294901760=824
x_zwave_values.Configuration_Upper_Temperature_Limit_Unit_3840=2
x_zwave_values.Configuration_Upper_Ultraviolet_Limit=8
x_zwave_values.Configuration_Wake_Device_for_10_minutes_After_Power_On=1
x_zwave_values.Configuration_Wake_Up_Timeout=15
x_zwave_values.Manufacturer_Specific_manufacturerId=134
x_zwave_values.Manufacturer_Specific_productId=100
x_zwave_values.Manufacturer_Specific_productType=258
x_zwave_values.Multilevel_Sensor_Air_temperature=73.8
x_zwave_values.Multilevel_Sensor_Humidity=46
x_zwave_values.Multilevel_Sensor_Illuminance=5
x_zwave_values.Multilevel_Sensor_Ultraviolet=0
x_zwave_values.Notification_Home_Security_Cover_status=0
x_zwave_values.Notification_Home_Security_Motion_sensor_status=0
x_zwave_values.Notification_alarmLevel=0
x_zwave_values.Notification_alarmType=0
x_zwave_values.Version_firmwareVersions=["1.17"]
x_zwave_values.Version_hardwareVersion=100
x_zwave_values.Version_libraryType=3
x_zwave_values.Version_protocolVersion="4.54"
x_zwave_values.Wake_Up_controllerNodeId=1
x_zwave_values.Wake_Up_wakeUpInterval=3600
zwave_device.capabilities=[32,48,49,112,113,114,128,132,134]
zwave_device.endpoint=0
zwave_device.failed=false
zwave_device.generic_class="Multilevel Sensor"
zwave_device.impl_sig="23326:1:22315:1"
zwave_device.is_beaming=false
zwave_device.is_listening=true
zwave_device.is_routing=true
zwave_device.is_secure=false
zwave_device.manufacturer_info=[134,258,100]
zwave_device.max_data_rate=null
zwave_device.node_id=53
zwave_device.specific_class="Routing Multilevel Sensor"
zwave_device.status=4
zwave_device.status_text="alive"
zwave_device.version_info=[null,"1.17"]
zwave_device.wakeup_interval=3600
I'm running:
Reactor latest-24190-bd310acc, Bare-metal on Fedora
WaveJSController [0.1.23326]
Home Assistant: 2024.7.0
I'm fetching certain data five past every hour, but I would like to do it closer to the hour, e.g. 1 or 2 past (but not at the hour).
I experimented with the following rule that almost works (triggers also at the hour which is not the intention). Any advice for a solution?
It would be nice to have an ability to bookmark a direct link to a dashboard item. In my case I would use this feature to access a virtual switch directly.
Hi @toggledbits
Would you please consider adding an extra sublevel in the rulesets?
I have grouped my rules in rooms/ areas. This works great for me, but I would also like to group rules for the same functionality (in a room). This would make the rules easier to find and name.
Please let me know if this is an option. Thanks!
@togglebits I am curious as to why the tilt_sensor.state (primary) = NULL. I believe it should show true or false. I have to use binary_sensor.state instead in my rules.
Again, not sure if this is related to Reactor/ZwaveJSController implementation or the actual Z-Wave JS UI docker version. I have copied, below, the attributes of the tilt sensor in hopes it can help.
Thanks in advance.
Reactor version 23302
ZWaveJSController version 23254
Z-Wave JS UI version 9.3.0.724519f
zwave-js version 12.2.3
@toggledbits,
I have this device attached to my system, but use a DSC panel. If you need testers to move forward, I'm happy to help.
I'm curious what your thinking the use case is for this. I currently have it integrated into HomeAssistant, and it works fine for the most part. The one thing I can't do is bypass zones, which I would like to have the ability to do.
Are you looking at more direct control for the panel, as opposed to having to jump through HA (or another system) first?
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.I have the following ruleset which I though had been working well until this morning when I noticed it's not.
I've put four weather conditions in an in array and one of them is the current weather condition - but the rule is not true. Now the cloud cover percentage is not yet met but this is an or rule so as long as the "Current Conditions" are met then it should go true.
What's the obvious thing I'm missing here? (I've tried spaces/no spaces in the in and no difference.)
Hi,
Running the latest MSR latest-24152-3455578a with the latest HA 2024.6.1. When trying to call a service I get the following in the MSR logs. Is this a version mismatch? I am not seeing anything in the HA logs.
[latest-24152]2024-06-11T10:29:56.162Z <Rule:INFO> rule-Monitor-DHW (rule-lsvq5k3x in Central Heating) started [latest-24152]2024-06-11T10:29:58.625Z <HassController:WARN> HassController#hass unknown service opentherm_gw.set_hot_water_setpoint in x_hass.call_service action on Thermostat#hass>climate_living_room_otgw [latest-24152]2024-06-11T10:29:58.626Z <HassController:INFO> HassController#hass: sending payload for x_hass.call_service on Thermostat#hass>climate_living_room_otgw action: [Object]{ "type": "call_service", "service_data": { "gateway_id": "living_room_otgw", "temperature": 65 }, "domain": "opentherm_gw", "service": "set_hot_water_setpoint", "target": { "entity_id": "climate.living_room_otgw" } } [latest-24152]2024-06-11T10:29:58.627Z <HassController:ERR> HassController#hass request 1718101798626<6/11/2024, 12:29:58 PM> (call_service) failed: [Object]{ "id": 1718101798626, "type": "result", "success": false, "error": { "code": "invalid_format", "message": "extra keys not allowed @ data['entity_id']" } } [latest-24152]2024-06-11T10:29:58.627Z <HassController:WARN> HassController#hass action x_hass.call_service([Object]{ "service": "opentherm_gw.set_hot_water_setpoint", "data": "{ \"gateway_id\": \"living_room_otgw\", \"temperature\": 65 }" }) on Thermostat#hass>climate_living_room_otgw failed!Cheers Rene
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:
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-moodlightAnd 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: jsonAnother 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
That's probably more appropriate to post on Mantis for @toggledbits, but since I know there's at least @Crille publishing templates, my intent with this post is to open a broader discussion.
Long story short: I'm starting to slowly add new template for Shelly Plus and I noticed I'll end up with a dozen more templates, all similar but simply different in trivial details, all sharing a large amount of code and all needing special cares when fixing bugs/adding features (as the latest wifi_status addition).
So, I'm wondering if it's time to start thinking of some sort of inheritance in templates, where I could just create a generic shelly_gen1 and use it as a base for shelly_relay, and this be used as the base for shelly_relay_power and so on.
I could probably achieve this with some sort of scripting on my side to generate templates via code, but maybe there's a better way of doing this, or it's already on the radar.
I need a handful of victims volunteers to help test previews of the next build of Reactor. A long-standing request was for "a simple login mechanism," but in practice, adding user authentication and competent access control turned out to be a pretty big project with a lot of big changes on both server and client sides. It's a bit more than I'm comfortable testing myself and springing out to everyone at once, so I'd like to work with a small group to put it through "sea trials."
Major changes/features include:
User authentication with hashed password storage; User group configuration with application restriction (admin, dashboard, API); Detailed control over API access, with user- and token-based authentication/authorization; Improvements to the HTTPS service; Improvements to UI coordination with the core for Rules and Reactions.If this sounds like something you'd like to help with, drop me a reply here in this thread or privately.
[Solution: Reactor 24115 is not compatible with MQTTController > 24120]
Reactor latest-24115 bare metal.
All MQTT entities stop working after updating MQTTController to 24142, downgrade to 24120 and they are back. Templates and configured entities has not been changed between versions.
I'm not sure if uses_template should be replaced by ìnclude in entity configuration in reactor.yaml but I guess not, I've tried it and it did not do any difference.
I have not tried to update Reactor to userauth version.
Example entity in reactor.yaml that uses MQTTController included template:
entities: "takflakt_kallare": name: "Takfläkt källare" topic: "Källartemp" unit: "" uses_template: tasmota_generic_relay init: "cmnd/%topic%/POWER%unit%"Any hints? Do you need more info, please let me know.
Log from startup:
I'm slowly migrating all my stuff to MQTT under MSR, so I have a central place to integrate everything (and, in a not-so-distant future, to remove virtual devices from my Vera and leave it running zwave only).
Anyway, here's my reactor-mqtt-contrib package:
![](https://github.com/fluidicon.png)
Contrib MQTT templates for Reactor. Contribute to dbochicchio/reactor-mqtt-contrib development by creating an account on GitHub.
Simply download yaml files (everything or just the ones you need) and you're good to go.
I have mapped my most useful devices, but I'll add others soon. Feel free to ask for specific templates, since I've worked a lot in the last weeks to understand and operate them.
The templates are supporting both init and query, so you have always up-to-date devices at startup, and the ability to poll them. Online status is supported as well, so you can get disconnected devices with a simple expression.
Many-many thanks to @toggledbits for its dedication, support, and patience with me and my requests 🙂
Is the following config correct?
- id: time_series name: "Out temp" capabilities: temperature_sensor: attributes: value: model: time series entity: "hass>sensor_outdoor_temperature" attribute: "temperature_sensor.value" interval: 5 # minutes retention: 20 # minutes aggregate: wma primary_attribute: temperature_sensor.value type: ValueSensorSpecifically, is "depth" directive needed/mandatory here? Reason I'm asking is that I'm not getting a "final" value in MSR, only debug values are shown:
temperature_sensor.units=null temperature_sensor.value=null x_virtualentity.last_request_time=null x_virtualentity.request_failures=null x_virtualentity.template=null x_virtualentity.timeseries_debug=[{"time":1716537360000,"value":22.1},{"time":1716537660000,"value":22},{"time":1716537960000,"value":22},{"time":1716538260000,"value":21.9},{"time":1716538560000,"value":22}]Good morning,
I apologize if this subject has been covered. I did try the search, but I'm not coming up with any topics on my issue.
I'm running userauth-24137-57b41335, bare metal installation on Fedora 39 Server.
I have a rule set up to turn the Eco mode off on my Nest Thermostat when the thermostat is set to Away (Rule State: Away Mode), the user (Driver) presence in my car changes to true, and the destination is set to home.
93804f7c-62d6-42c0-ae04-ff602011a6fd-image.png
This works fine for most days, where I'm headed home from work (commute is about 45 minutes). What I don't want it to do is set change it to Eco mode if my ETA is more than an hour.
There is a sensor/entity for Time to Arrival when the Destination is set. What it appears to provide is the Time OF arrival/ETA, not time until arrival. If it was Time until Arrival, and it was a numeric value, I could simply test if the value is less than 60 and be done with it.
I pulled up the history through Home Assistant for my morning commute and this appears to be what it is providing.
c2a32739-c84f-4a05-95d9-73793ed818f5-image.png
So what I need to do is to do a calculation of the the ETA from the sensor value and subtract the current time, and get a value in minutes that I can determine if it's less than 60.
I believe I can do this with the local expression, but I don't see anything for the system time, or local time. Also, do the local expressions update themselves if the sensors do?
Good morning,
I'm running userauth-24137-57b41335 on Fedora 39, bare metal installation.
ZWaveJSController 0.1.23254
Home Assistant:
Core, 2024.5.3 Supervisor, 2024.05.1 Operating System, 12.3 Frontend, 20240501.1I'm trying to troubleshoot a Dynamic Group Controller and notification alert that I've set up for low battery level.
In my Reactor.config, I have the following lines:
name: "Dynamic Group Controller" implementation: DynamicGroupController config: groups: "zwavejs_dead": select: - include_group: "zwavejs" filter_expression: "entity?.attributes?.zwave_device?.status == 3" group_actions: true "low_battery": select: - include_capability: battery_power filter_expression: > entity.attributes.battery_power.level < 0.35The idea here is that I should only have members of this group that have a battery level below 35%. When I go into Entities, I show a whole slew of devices, none of which have a battery level below the threshold.
a77e445b-ab78-4752-a624-3c4117f34f90-image.png
I also tried setting up a rule to generate a push notification once a day, but with all of the group members, I've had to disable the rule. I believe I have it set up correctly, but I'm not 100% sure. I want the notification to tell me the battery level for that device as well.
289b4f68-03ba-49c0-8275-f0f197d13a3a-image.png
ce24a76e-6865-40bd-bd85-632e54d315a8-image.png dc837424-deb5-4ef7-8f0d-3676f1769535-image.png
Can anyone point to me what I may have misconfigured to get these results?
I should also note I'm only interested in ZWaveJS devices. It's showing me battery status for my iPad and car as well, which I don't need it to send me.
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
orVer 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 useMSR
,msr
, orreactor
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 postSolved 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
-
T toggledbits pinned this topic on
-
T toggledbits locked this topic on
-
T toggledbits referenced this topic on
-
T toggledbits referenced this topic on
-
T toggledbits referenced this topic on
-
T toggledbits referenced this topic on
-
T toggledbits referenced this topic on
-
T toggledbits referenced this topic on
-
T toggledbits referenced this topic on
-
T toggledbits referenced this topic on
-
T toggledbits referenced this topic on
-
T toggledbits referenced this topic on
-
T toggledbits referenced this topic on
-
-
T toggledbits referenced this topic on
-
T toggledbits referenced this topic on
-
-
T toggledbits referenced this topic on
-
T toggledbits referenced this topic on
-
T toggledbits referenced this topic on
-
T toggledbits referenced this topic on
-
T toggledbits referenced this topic on
-
T toggledbits referenced this topic on
-
T toggledbits referenced this topic on
-
T toggledbits referenced this topic on
-
T toggledbits referenced this topic on
-
T toggledbits referenced this topic on
-
T toggledbits referenced this topic on
-
T toggledbits referenced this topic on
-
T toggledbits referenced this topic on