Thanks very much. I specified it as you described and toggle works just fine now.

I'll change the username and password and no, the template was not copied to the reactor.yaml file.

I started out by following the docs (see below) on how to set it up but got a bit confused. It gives an example of setting up a Shelly, but then says to use the tasmota_generic_relay template. This is how I ended up with the 0 (from channel 0).

Anyway all good now. Thanks again for the very quick reply. Looking forward to experimenting with MQTT and Tasmota to see if I can get improved reliability from my Sonoff devices.

Easy Device Configuration - Using Existing Template
As an example, let's say we have a Shelly1 configured with the topic shelly1_43DFD2 that is configured to operate as a single relay to operate a stairway light. To create an entity for this device, we can use the tasmota_generic_relay template. The template supports multiple relays, but since only one relay is configured in Tasmota, the published topics from the node will have a "unit number" (identifying which relay if more than one), so we'll specify no unit number by giving it an empty string:

...other stuff
config: "mqtt://127.0.0.1:1883/"
entities:
shelly1_stairway:
name: "Stairway Light"
topic: shelly1_43DFD2
uses_template: shelly_relay
channel: 0

MSR is currently running the latest-21342

I thought I would give MQTT controller a try for one of the many Sonoff devices I have in my home. My aim is to remove the HTTP Switch app in my Vera Plus and control all my devices from MSR using the MQTT controller.

I have carried out the following steps:
Flashed a new Sonoff Basic with Tasmota, configured it for MQTT and enabled it.
Installed MQTT Controller on MSR and added the basic configuration in the reactor.yaml file and re-started reactor.
The device is discovered in entities and when clicking on the attributes power_switch.on, power-switch.off, power-switch.set everything works just fine.
The problem I have is with toggle. This always works to toggle the device ON but when toggled again does not turn it OFF.

I've attached my reactor.yaml file and the template which it uses. Hopefully someone can shed some light on why it won't toggle OFF.

Thanks

I ran the install script again and nodejs is now updated to the latest version.
pi@raspberrypi:~ $ node -v
v16.13.0
I also copied the reactor.service file as advised and MSR is working fine.

Thanks for your help

I've recently updated to latest build 21332 and notice in the Readme file that I should update nodejs to 16.13.0 or higher before end of March. I've had a go at doing this, but think I've not done it correctly as I get the following responses in the terminal:

pi@raspberrypi:~ $ node -v
v14.17.0
pi@raspberrypi:~ $ nodejs -v
v16.13.0

Is this correct? If not then what steps do I need to carry out to update nodejs properly.

Any help from the group would be much appreciated.

OK. It's all good now. I rebooted my system and all my icons are back and I'm able to access all the options now. Thanks for your help.

@toggledbits

No joy with that I'm afraid. This is the outcome of the update. Any clues here?

pi@raspberrypi:~ $ cd ~/Documents/reactor
pi@raspberrypi:~/Documents/reactor $ npm update --no-save
npm WARN bootstrap@4.6.0 requires a peer of popper.js@^1.16.1 but none is installed. You must install peer dependencies yourself.

• bootstrap-icons@1.5.0
• jsdoc@3.6.7
• influx@5.9.2
• uuid@8.3.2
  added 25 packages from 23 contributors, updated 2 packages and audited 102 packages in 8.223s

9 packages are looking for funding
run npm fund for details

found 1 moderate severity vulnerability
run npm audit fix to fix them, or npm audit for details
npm WARN bootstrap@4.6.0 requires a peer of popper.js@^1.16.1 but none is installed. You must install peer dependencies yourself.

• diskusage-ng@1.0.2
  removed 25 packages, updated 1 package and audited 77 packages in 2.926s

8 packages are looking for funding
run npm fund for details

found 1 moderate severity vulnerability
run npm audit fix to fix them, or npm audit for details
pi@raspberrypi:~/Documents/reactor $ sudo systemctl restart reactor

@togglebits,

Not sure when this happened, but now when I create a new rule I get the boxes open up for Triggers and Set Reaction only. Clicking in any of the Constraints, Reset Reaction or Expressions boxes does not expand them and allow me to enter anything.
I'm getting round it for now by copying an existing rule which has Triggers, Set Reactions, Reset Reactions and Expressions in it and then modifying this to be my new rule.
Any thoughts on how to make these boxes available again?

MSR is installed on a Raspberry Pi 4B (8GB) - Bare Metal (without Docker) and is the latest-21228-05d7497

@sweetgenius said in Version 1.0 Pre-release Discussion:

Would a Menu item for accessing the reactor log file or portion of the log be possible.Or ideally a way to monitor the log in real time from the GUI for troubleshooting?

+1 for this.

@togglebits The following rule is one of two which have stopped working since updating to 21096. I guess they're easily fixed by changing the local expressions to global ones, but is this a bug or by design?

Bye the way. Well pleased with how Alerts shows up the errors.

Followed the guide and Pushover is now set up and working fine.

Thanks. Should have known to look there. Will give it a try.

Hi,

I've been using Pushover in VeraAlerts, but now want to send my notifications from MSR.
I see in the reactor config directory that the notification. yaml file includes Pushover, but is showing #TBD. Is this where I need to set up my Pushover user key etc. and if so what and how should the information be entered?

Any help would be appreciated.

@togglebits

Just confirming that this working ok now since upgrade to 21081

Many Thanks

Patrick, Just confirming this is now working ok for me.

Thanks for the fixes Patrick.

I've now tried them on my test rules and both (PR#64 and 65) work fine.

I've also updated all my imported rules to use the "delay reset" on the "Follow" output mode. These are all working now with the added bonus of being able to monitor the delays counting down.

Thanks again for the brilliant MSR.

Ok, so this is how the rules for Delay1 and Delay 2 are now setup.

Each rule works perfectly fine when run on its own. The problem I have now is when one runs at the same time as the other.

To prevent any conflict, all my other rules in MSR are disabled, as are my Reactors in Vera.

In the following screenshot, Delay 2 (20s) is started and shortly after Delay 1 (10s) is started. Delay 1 completes first and its associated lamp switches off. Then Delay 2 completes but its associated lamp remains on.
What can't be seen in the screenshot is as well as the text being green for Delay 2 the whole box is also flashing green.
Everything works ok, except the lamp does not switch off after Delay 2 completes.

As can be seen from the logs, Delay 2 <Reset> does not occur.

2021-02-27T01:31:12.388Z Engine:INFO Delay 1<SET> all actions completed.
2021-02-27T01:31:29.320Z Rule:INFO Rule#rule-klmc7wxx (Delay 2) reset.
2021-02-27T01:31:29.328Z Rule:INFO Rule#rule-klifbnfi (Delay 1) reset.
2021-02-27T01:31:29.332Z Engine:INFO Enqueueing "Delay 2<RESET>" (rule-klmc7wxx:R)
2021-02-27T01:31:29.333Z Engine:INFO Enqueueing "Delay 1<RESET>" (rule-klifbnfi:R)
2021-02-27T01:31:29.334Z Engine:NOTICE Starting reaction Delay 2<RESET> [RuleReaction#rule-klmc7wxx:R]
2021-02-27T01:31:29.336Z Engine:NOTICE Starting reaction Delay 1<RESET> [RuleReaction#rule-klifbnfi:R]
2021-02-27T01:31:29.357Z Engine:NOTICE Resuming reaction Delay 2<RESET> from step 1
2021-02-27T01:31:29.359Z Engine:INFO Delay 2<RESET> all actions completed.
2021-02-27T01:31:29.431Z Engine:NOTICE Resuming reaction Delay 1<RESET> from step 1
2021-02-27T01:31:29.433Z Engine:INFO Delay 1<RESET> all actions completed.
2021-02-27T01:31:57.809Z Rule:NOTICE Rule#rule-klmc7wxx configuration changed; reloading
2021-02-27T01:31:57.812Z Rule:NOTICE Rule#rule-klmc7wxx stopping rule
2021-02-27T01:31:57.819Z Rule:NOTICE Rule Rule#rule-klmc7wxx stopped
2021-02-27T01:31:57.820Z Rule:INFO Rule#rule-klmc7wxx (Delay 2) started
2021-02-27T01:32:07.911Z Rule:INFO Rule#rule-klifbnfi (Delay 1) triggered!
2021-02-27T01:32:07.915Z Engine:INFO Enqueueing "Delay 1<SET>" (rule-klifbnfi:S)
2021-02-27T01:32:07.916Z Engine:NOTICE Starting reaction Delay 1<SET> [RuleReaction#rule-klifbnfi:S]
2021-02-27T01:32:07.979Z Engine:NOTICE Resuming reaction Delay 1<SET> from step 1
2021-02-27T01:32:07.980Z Engine:INFO Delay 1<SET> all actions completed.
2021-02-27T01:32:24.901Z Rule:INFO Rule#rule-klifbnfi (Delay 1) reset.
2021-02-27T01:32:24.905Z Engine:INFO Enqueueing "Delay 1<RESET>" (rule-klifbnfi:R)
2021-02-27T01:32:24.906Z Engine:NOTICE Starting reaction Delay 1<RESET> [RuleReaction#rule-klifbnfi:R]
2021-02-27T01:32:24.974Z Engine:NOTICE Resuming reaction Delay 1<RESET> from step 1
2021-02-27T01:32:24.975Z Engine:INFO Delay 1<RESET> all actions completed.
2021-02-27T01:32:29.114Z Rule:INFO Rule#rule-klmc7wxx (Delay 2) triggered!
2021-02-27T01:32:29.124Z Engine:INFO Enqueueing "Delay 2<SET>" (rule-klmc7wxx:S)
2021-02-27T01:32:29.125Z Engine:NOTICE Starting reaction Delay 2<SET> [RuleReaction#rule-klmc7wxx:S]
2021-02-27T01:32:29.175Z Engine:NOTICE Resuming reaction Delay 2<SET> from step 1
2021-02-27T01:32:29.176Z Engine:INFO Delay 2<SET> all actions completed.
2021-02-27T01:32:34.920Z Rule:INFO Rule#rule-klifbnfi (Delay 1) triggered!
2021-02-27T01:32:34.924Z Engine:INFO Enqueueing "Delay 1<SET>" (rule-klifbnfi:S)
2021-02-27T01:32:34.926Z Engine:NOTICE Starting reaction Delay 1<SET> [RuleReaction#rule-klifbnfi:S]
2021-02-27T01:32:34.973Z Engine:NOTICE Resuming reaction Delay 1<SET> from step 1
2021-02-27T01:32:34.974Z Engine:INFO Delay 1<SET> all actions completed.
2021-02-27T01:32:51.969Z Rule:INFO Rule#rule-klifbnfi (Delay 1) reset.
2021-02-27T01:32:51.974Z Engine:INFO Enqueueing "Delay 1<RESET>" (rule-klifbnfi:R)
2021-02-27T01:32:51.975Z Engine:NOTICE Starting reaction Delay 1<RESET> [RuleReaction#rule-klifbnfi:R]
2021-02-27T01:32:52.047Z Engine:NOTICE Resuming reaction Delay 1<RESET> from step 1
2021-02-27T01:32:52.049Z Engine:INFO Delay 1<RESET> all actions completed.

That's great that you found it.

I modified both my test rules to use the "delay reset" on the "Follow" output mode and changed the Set Reaction to switch the lights on and the Reset Reaction to switch them off again (much better way of doing it). Unfortunately, it hasn't fixed the problem, so I'm guessing the error you found affects this way of doing it as well. Will wait for the next daily build and test it again.

Ok. Thanks for the explanation. You guessed right about how I want it to work. I'll try using "delay reset" on the "Follow" output mode instead.

I was careful about how I did the test and have just carried it out again. There is nothing in the reset reactions of either rule and I made sure not re-activate the motion sensor associated with the 10 second rule after the 3 second pulse. I'm the only one in the house at the moment, so no-one else interfering with the test.
It's always the case that the first timer does not end on time once the second timer is started.

Not sure I understand what you mean by delay option. Is there something else I should be setting?

I seem to be having some issues with delays, so I set up a test as follows:

If the second rule is disabled, the first rule works as I expect - when motion is detected in the Hall, the Hall lamp switches on and then off again 10 seconds later.

With both rules enabled - when motion is detected in the Hall the Hall lamp switches on, but then if motion is detected in the Dining room, the Dining room lamp switches on, but the Hall lamp does not switch off after the 10 seconds , but after the 30 seconds when both lamps switch off at the same time.

Is this a bug, or just my understanding of how it should work?