I had an existing rule that turns on my Kitchen ceiling lights to 100% when motion is detected.
I want to make a change so that when Vera is in Night Mode the lights will instead turn on to 25% brightness.
I have added a Constraints Group in to the Set Reaction and set it to OR :
Is this likely to work or not ?
Or do I need two Constraints Groups within the Set Reaction ?
I can test it later on when its time to put Vera in to Night mode.
How are folks handling situations where they want to have Conditional Actions or Branching Logic in their Set Reactions for a rule? Are you creating Duplicating the same trigger and setting different conditions and Actions?
Is there an approach where you combine a main rule with your entity triggers with sub rules that trigger off Expressions? You then could write your conditions as Set Variable actions in the Main Rule for the Expressions that evaluate to true or false. Each sub rule would trigger based on the expression changing to true and then could also change it back to false after.
Not sure if that's worth the complexity for the reusability and control over duplicate triggers.
Posted this in Vera forum with no response:
Seeing this in reactor UI:
A newer version of the device information database is available. Please use the update function on the Tools tab to get it. This process is quick and does not require a Luup reload or browser refresh–you can immediately come back here and go right back to work! The new version is 865.877, and you are currently using 557.352…
Hit update in Tools and get an error: “The update could not be retrieved. If this problem persists, consult the documentation.”
Looked through logs and not seeing anything specific. You have a keyword I should search for?
I am not a programmer, so I am picking this up piece by piece.
I would like to use a rule-based expression to store the current value of a dimmer, change the dimmer value, then change it back to the stored value.
I have a working global expression that I have used.getEntity( "VeraShop>device_24" ).attributes.dimming.level
I have a blank global expression ready to use in "set variable" that is available to set.
I am stuck with the formatting of the "set variable" field to set the variable. If I get pointed in the right direction, I am fairly confident I can get the rest going on my own. .
Thanks in advance
This was working and tested previously, but now doesn't seem to be.
I turned the heating on earlier, however I have since turned if off again. However the trigger in this rule still says the current set point value is 21. Its not its currently 10.
A window was just opened and a TTS heard, which drew my attention to this rule now as it should not of fired its actions.
Vera variable now:
Thermostat device information from the Entities:battery_power.level=0.49 battery_power.since=1620139135000 hvac_control.mode=null hvac_control.state=null hvac_heating_unit.setpoint=21 hvac_heating_unit.state=null hvac_heating_unit.units="c" power_switch.state=null value_sensor.units="c" value_sensor.value=18.1 x_vera_device.configured=true x_vera_device.device_number=189 x_vera_device.device_type="urn:schemas-upnp-org:device:Heater:1" x_vera_device.failed=false x_vera_device.mapped_by="*;device_type=urn:schemas-upnp-org:device:Heater:1" x_vera_device.mapped_class="heatonly_thermostat" x_vera_svc_micasaverde_com_HaDevice1.AutoConfigure="-1" x_vera_svc_micasaverde_com_HaDevice1.BatteryDate="1620139135" x_vera_svc_micasaverde_com_HaDevice1.BatteryLevel="49" x_vera_svc_micasaverde_com_HaDevice1.CommFailure="0" x_vera_svc_micasaverde_com_HaDevice1.CommFailureAlarm="1612455867,0" x_vera_svc_micasaverde_com_HaDevice1.CommFailureTime="0" x_vera_svc_micasaverde_com_HaDevice1.Commands="heater_setpoint" x_vera_svc_micasaverde_com_HaDevice1.Configured="1" x_vera_svc_micasaverde_com_HaDevice1.FirstConfigured="1485879775" x_vera_svc_micasaverde_com_HaDevice1.LastUpdate="1607103908" x_vera_svc_micasaverde_com_HaDevice1.ModeSetting="1:;2:H,10.0;3:H,10.0;4:H,10.0" x_vera_svc_micasaverde_com_HaDevice1.PollRatings="5.00" x_vera_svc_micasaverde_com_HaDevice1.WakeupRatings="5.00" x_vera_svc_micasaverde_com_HaDevice1.sl_BatteryAlarm="0" x_vera_svc_micasaverde_com_ZWaveDevice1.AssociationGet="2,190,;" x_vera_svc_micasaverde_com_ZWaveDevice1.AssociationNum="5" x_vera_svc_micasaverde_com_ZWaveDevice1.AssociationSet="2,190" x_vera_svc_micasaverde_com_ZWaveDevice1.Capabilities="18,150,0,1,8,0,B,|49:1,67,112,114,128,132:2,133,134," x_vera_svc_micasaverde_com_ZWaveDevice1.ConfiguredAssoc="2,190" x_vera_svc_micasaverde_com_ZWaveDevice1.ConfiguredName="" x_vera_svc_micasaverde_com_ZWaveDevice1.ConfiguredVariable="1-variable 1,1d,255,2-variable 2,1d,1,3-variable 3,1d,10" x_vera_svc_micasaverde_com_ZWaveDevice1.ConfiguredWakeupInterval="300" x_vera_svc_micasaverde_com_ZWaveDevice1.FirmwareInfo="" x_vera_svc_micasaverde_com_ZWaveDevice1.LastArr="1620138237,69" x_vera_svc_micasaverde_com_ZWaveDevice1.LastNnu="1620137632,69" x_vera_svc_micasaverde_com_ZWaveDevice1.LastReset="1485882104" x_vera_svc_micasaverde_com_ZWaveDevice1.LastRouteUpdate="1620109432" x_vera_svc_micasaverde_com_ZWaveDevice1.LastWakeup="1620152934" x_vera_svc_micasaverde_com_ZWaveDevice1.ManufacturerInfo="89,1,3" x_vera_svc_micasaverde_com_ZWaveDevice1.MeterScale="" x_vera_svc_micasaverde_com_ZWaveDevice1.MeterType="" x_vera_svc_micasaverde_com_ZWaveDevice1.MultiChCapabilities="" x_vera_svc_micasaverde_com_ZWaveDevice1.MultiChEndpoint="" x_vera_svc_micasaverde_com_ZWaveDevice1.NodeInfo="31,43,70,72,80,84,85,86," x_vera_svc_micasaverde_com_ZWaveDevice1.PollNoReply="378" x_vera_svc_micasaverde_com_ZWaveDevice1.PollOk="16295" x_vera_svc_micasaverde_com_ZWaveDevice1.PollSettings="10800" x_vera_svc_micasaverde_com_ZWaveDevice1.SensorBiType="" x_vera_svc_micasaverde_com_ZWaveDevice1.SensorMlScale="" x_vera_svc_micasaverde_com_ZWaveDevice1.SensorMlType="" x_vera_svc_micasaverde_com_ZWaveDevice1.SetPointInfo="H1," x_vera_svc_micasaverde_com_ZWaveDevice1.SubscribedAlarms="" x_vera_svc_micasaverde_com_ZWaveDevice1.TemperatureScale="1,0,2" x_vera_svc_micasaverde_com_ZWaveDevice1.VariablesGet="1,255,2,1,3,10," x_vera_svc_micasaverde_com_ZWaveDevice1.VariablesSet="1-variable 1,1d,255,2-variable 2,1d,1,3-variable 3,1d,10" x_vera_svc_micasaverde_com_ZWaveDevice1.VersionInfo="2,2,78,6,0" x_vera_svc_micasaverde_com_ZWaveDevice1.WakeupInterval="300" x_vera_svc_micasaverde_com_ZWaveNetwork1.ConsecutivePollFails="0" x_vera_svc_micasaverde_com_ZWaveNetwork1.LastPollSuccess="1620149034" x_vera_svc_upnp_org_Dimming1.LoadLevelTarget="58" x_vera_svc_upnp_org_HVAC_UserOperatingMode1.ModeStatus="HeatOn" x_vera_svc_upnp_org_SwitchPower1.Target="0" x_vera_svc_upnp_org_TemperatureSensor1.CurrentTemperature="18.10" x_vera_svc_upnp_org_TemperatureSetpoint1.AllSetpoints="10.00,0.00,5.00" x_vera_svc_upnp_org_TemperatureSetpoint1.CurrentSetpoint="10.00" x_vera_svc_upnp_org_TemperatureSetpoint1.NewCurrentSetpointC="23" x_vera_svc_upnp_org_TemperatureSetpoint1.NewCurrentSetpointF="73.4" x_vera_svc_upnp_org_TemperatureSetpoint1.Range="0,0/0,0;0,0/0,0;5,30/41,86" x_vera_svc_upnp_org_TemperatureSetpoint1.SetpointTarget="10.00" x_vera_svc_upnp_org_TemperatureSetpoint1_Heat.CurrentSetpoint="21.00" zwave_device.capabilities="18,150,0,1,8,0,B,|49:1,67,112,114,128,132:2,133,134," zwave_device.failed=false zwave_device.manufacturer_info="89,1,3" zwave_device.node_id=57 zwave_device.version_info="2,2,78,6,0" Capabilities: battery_power, hvac_control, hvac_heating_unit, power_switch, toggle, value_sensor, x_vera_device, x_vera_svc_micasaverde_com_HVAC_OperatingState1, x_vera_svc_micasaverde_com_HaDevice1, x_vera_svc_micasaverde_com_ZWaveDevice1, x_vera_svc_micasaverde_com_ZWaveNetwork1, x_vera_svc_upnp_org_Dimming1, x_vera_svc_upnp_org_HVAC_UserOperatingMode1, x_vera_svc_upnp_org_SwitchPower1, x_vera_svc_upnp_org_TemperatureSensor1, x_vera_svc_upnp_org_TemperatureSetpoint1, x_vera_svc_upnp_org_TemperatureSetpoint1_Heat, zwave_device Actions: hvac_control.set_mode, hvac_heating_unit.set_setpoint, power_switch.off, power_switch.on, toggle.toggle, x_vera_device.set_variable, x_vera_svc_micasaverde_com_HaDevice1.AllowPairing, x_vera_svc_micasaverde_com_HaDevice1.Poll, x_vera_svc_micasaverde_com_HaDevice1.Reconfigure, x_vera_svc_micasaverde_com_HaDevice1.Remove, x_vera_svc_micasaverde_com_HaDevice1.SetPollFrequency, x_vera_svc_micasaverde_com_HaDevice1.StressTest, x_vera_svc_micasaverde_com_HaDevice1.ToggleState, x_vera_svc_micasaverde_com_ZWaveNetwork1.AddNodes, x_vera_svc_micasaverde_com_ZWaveNetwork1.BackupDongle, x_vera_svc_micasaverde_com_ZWaveNetwork1.DownloadNetwork, x_vera_svc_micasaverde_com_ZWaveNetwork1.HealNetwork, x_vera_svc_micasaverde_com_ZWaveNetwork1.PollAllNodes, x_vera_svc_micasaverde_com_ZWaveNetwork1.PutByte, x_vera_svc_micasaverde_com_ZWaveNetwork1.ReconfigureAllNodes, x_vera_svc_micasaverde_com_ZWaveNetwork1.RemoveNodes, x_vera_svc_micasaverde_com_ZWaveNetwork1.ResetNetwork, x_vera_svc_micasaverde_com_ZWaveNetwork1.SendData, x_vera_svc_micasaverde_com_ZWaveNetwork1.SetPolling, x_vera_svc_micasaverde_com_ZWaveNetwork1.SimulateIncomingData, x_vera_svc_micasaverde_com_ZWaveNetwork1.UpdateNeighbors, x_vera_svc_micasaverde_com_ZWaveNetwork1.UpdateNetwork, x_vera_svc_upnp_org_Dimming1.PauseRamp, x_vera_svc_upnp_org_Dimming1.ResumeRamp, x_vera_svc_upnp_org_Dimming1.SetLoadLevelTarget, x_vera_svc_upnp_org_Dimming1.SetOnEffect, x_vera_svc_upnp_org_Dimming1.SetOnEffectLevel, x_vera_svc_upnp_org_Dimming1.SetRampRate, x_vera_svc_upnp_org_Dimming1.SetStepDelta, x_vera_svc_upnp_org_Dimming1.StartRampDown, x_vera_svc_upnp_org_Dimming1.StartRampToLevel, x_vera_svc_upnp_org_Dimming1.StartRampUp, x_vera_svc_upnp_org_Dimming1.StepDown, x_vera_svc_upnp_org_Dimming1.StepUp, x_vera_svc_upnp_org_Dimming1.StopRamp, x_vera_svc_upnp_org_HVAC_UserOperatingMode1.SetEnergyModeTarget, x_vera_svc_upnp_org_HVAC_UserOperatingMode1.SetModeTarget, x_vera_svc_upnp_org_HVAC_UserOperatingMode1.SetName, x_vera_svc_upnp_org_SwitchPower1.SetTarget, x_vera_svc_upnp_org_TemperatureSensor1.SetApplication, x_vera_svc_upnp_org_TemperatureSensor1.SetName, x_vera_svc_upnp_org_TemperatureSetpoint1.SetApplication, x_vera_svc_upnp_org_TemperatureSetpoint1.SetCurrentSetpoint, x_vera_svc_upnp_org_TemperatureSetpoint1.SetName, x_vera_svc_upnp_org_TemperatureSetpoint1_Heat.SetApplication, x_vera_svc_upnp_org_TemperatureSetpoint1_Heat.SetCurrentSetpoint, x_vera_svc_upnp_org_TemperatureSetpoint1_Heat.SetName, zwave_device.poll
In the rule if I change the trigger to use this Entity Attribute instead, then now its correctly showing 10 as the current set point.
Besides having integrated the xiaomi vacuum cleaner robot to my system, I have actually also integrated a large number of air filters to my automation system (homeassistant -> bridged into openLuup) for quite sometime. I have been using them mostly to monitor the air quality in different rooms. All of these devices are wifi but are communicating through a local API. I was looking today at replacing also my foobot which is my very last cloud dependent devices (and a non critical one) and found/ordered this:60.99US $ 38% OFF|Xiaomi Mijia Air Quality Tester 3.97 60.99US $ 38% OFF|Xiaomi Mijia Air Quality Tester 3.97
Smarter Shopping, Better Living! Aliexpress.com
It can very likely be integrated into home-assistant and then openLuup the same way I have with my filters but what I found particularly interesting is its low cost and the fact that it can also serve as a BT gateway! Why is this getting me excited? Because I have long regretted the loss of Plantlink which was a zigbee platform for soil/plant monitoring which unfortunately was cloud dependent and went belly up. I have since been automating my garden watering based on predictive algorithm only, without sensors. (yes still with openLuup). I am now looking forward to see how this will workout as my better half is very invested in gardening these days...
In my Vera config I have two SiteSensors (one for Ambient Wx, one for OpenWxMap) that point to two unique Reactor devices for controlling HVAC in my home. This is done for redundancy - if the Ambient API drops it returns zero data which then triggers a standalone Master API Reactor device to flip on the OWM SiteSensor and corresponding HVAC Reactor device to continue controlling the house conditions.
Once the Ambient API returns to available the Master API Reactor device flips back to the Ambient SiteSensor and corresponding HVAC Reactor device, turning OFF the SiteSensor for OWM to save on API calls.
I've been able to duplicate one half of this, including the Master API role, in MSR. But... here's the tricky part... I can't turn "off" the MSR Rule Sets for the OWM version. As such, HVAC is sent conflicting data and doesn't know what to do.
Before I go alls deep into explaining how all of this currently works, am I missing something somewhere that would allow me to trigger the on/off of MSR Rule Sets?
Knowing that MSR Preview may not yet fully implement LuaXP (CORRECTION: MSR uses a different language lexpjs), I could not resist whipping up some text expressions for fun. Whereupon two things popped out at me:The new scaling (0.00 - 1.00) of Dimming Level will require a rewrite of certain Expressions that I use to balance my light levels. For example, it was my custom to monitor one lamp's brightness (0 - 100) with Reactor Luup, then set another lamp to 93% of that level, using this Expression: floor(getstate( 9, "urn:upnp-org:serviceId:Dimming1", "LoadLevelTarget" ) * 0.93)
Now, in MSR, it will become necessary to modify that to read:floor ((getEntity( "vera>device_9" ).attributes.dimming.level * 0.93)*100)/100
which effectively scales the value up x 100 (so that floor() can act upon it correctly), then downscale it / 100. Just an FYI to ponder.I'm noticing that every edit, however minor, of an Expression in MSR requires an immediate SAVE click before the 'Run' button will become active. That is to say, I cannot repeatedly evaluate the Expression during editing, without clicking SAVE first.
Only mentioning this latter behavior since it departs so dramatically from Reactor Luup's paradigm.
OK, people, here we go! At long last, Multi-System Reactor developer preview is available!
The package can be downloaded from the Reactor bug tracker, a MantisBT system (at https://reactor.toggledbits.com/mantisbt/). There is a download button in the left margin, as well as links to the documentation, which you will need for installation.
UPDATE 2021-02-24 -- To keep spammers off, I've locked down registration on the Bug Tracker. To get access to the Bug Tracker and preview downloads, please PM me (not reply here) your full name and email address and I will set up an account for you.
This version of MSR will run on Linux systems, including RPi's under Raspios Buster, running node.js version 12.10 or higher (v14.15.1). For RPi users, there is an installation script that will install a local copy of node.js (for the logged-in user).
Bugs reports will be handled through the bug tracker only. Discussion and questions in this forum are fine, though (if that leads to a bug report, we'll transition).
This version supports Vera (and openLuup to the degree it's compatible with Vera Luup), Hubitat, and Home Assistant. Some of the device support on the H platforms is still a bit basic, but it is largely controlled by configuration and progress can be made quickly.
The documentation beyond installation is a mess. Of course, I started with the existing documentation and have been massaging into MSR's particulars, but it still has a long way to go on the detail.
I know I don't have to say this, but I will anyway... let me know how it goes!
I am a pretty active forum user over on the QNAP forum and there has been a number of viral threads there and on reddit about the spread of ransomware on these NAS.
I wanted to post here to say that this is a fresh reminder to be very cautious with the current state of the affair when it comes to smarthomes and the trend towards IOT we are observing from all these companies attempting to make our homes cloud dependent, opening so called "secure tunnels" to their servers which can turn into very real exposures to your LAN (home network).
In order to mitigate it, QNAP released a firmware which now has autoupdate enabled by default (reminds me one other company...) and IMHO is the climax of absurdity but in fact when I come to think about it is how the amazon echos and ecobees work for example without even offering the ability to disable.
I am in no way a security expert but have had enough exposure and interest about it to recommend using a real firewall for your home network to block these backdoors if you have a smarthome and avoid these cloud oriented platforms and devices as if they were COVID.
Inspired by my love for MSR as a logic engine, as well as my undying nostalgia for two early console games -- Merlin (1978) by Parker Brothers and Lights Out (1995) by Tiger -- I decided to try my hand at recreating "LIGHTS OUT" just using MSR.
After an evening of playing around with Expressions inside a single Rule, my gambit succeeded. The result is a 3x3 version of "Lights Out" that can be played on any suitably configured Dashboard (Home Remote, Imperihome, MSR's built-in, etc.), where multiple buttons can be arranged in a grid. To play without a Dashboard, one can advance play manually and monitor game status under Rule Sets.
Each button press must send an HTTP GET Request (examples to follow) to MSR. (Alternatively, game play could involve inputs from another Rule or even physical device.) In turn, MSR will toggle the virtual switch corresponding to that position on the grid along with those adjacent to it in the up/down/left/right directions. The objective is to turn all of the devices (e.g. lights) OFF.
NOTE: This on/off behavior (of devices) is not yet implemented, as it would require nine virtual or actual switches that I have not installed. (Suitable candidate: Multi-switch VS in Switchboard on Vera.) Instead, as a proof of concept, the 3x3 playing grid is -- for now at least -- represented internally by a 9-element array of 0's (Off) and 1's (On). A player 'wins' once the array contains all zeroes.
In the posts below, I present how I crafted "Lights Out" in MSR.
One of the things I really like about Home Assistant are these "input_boolean", "input_number", "input_text" and "input_select" components that serve as data containers. The "input_boolean" component, for example, functions in the same way as a virtual switch, holding a boolean state and allowing you to modify that state. The "input_select" holds a defined set of values, as opposed to "input_text" which just accepts anything. There's even an "input_datetime" object.
I can see these being far more useful than trying to shoehorn more flexible behavior into virtualized models of existing devices, so this is the direction I'm thinking of going for MSR. One thing I really like is that the flexibility of them is sufficient to eliminate the need for expressionless variables in many, if not most, cases.
@akbooer, have you thought about using rapidjson instead of cjson?xpol/lua-rapidjson xpol/lua-rapidjson
A JSON module for Lua based on the very fast RapidJSON library. - xpol/lua-rapidjson
I am testing it on ALTUI and doesn't appear to be as strict as cjson while being even faster.miloyip/nativejson-benchmark miloyip/nativejson-benchmark
C/C++ JSON parser/generator benchmark. Contribute to miloyip/nativejson-benchmark development by creating an account on GitHub.
Benchmarks comparing dkjson, cjson and rapidjson halfway down the page:Performance compared to lua-cjson. · Issue #275 · Tencent/rapidjson Performance compared to lua-cjson. · Issue #275 · Tencent/rapidjson
I have write a json module for lua based on RapidJSON. The performance test result over lua-cjson is: On windows: My json module performance a bit slower than cjson when processing booleans nulls s...performance/nulls.json: (x10000) module decoding encoding dkjson 1.5754740238 0.0276830196 cjson 0.0551309586 0.0487358570 rapidjson 0.0545330048 0.0497119427 performance/booleans.json: (x10000) module decoding encoding dkjson 1.4916000366 0.5738999844 cjson 0.0556819439 0.0495460033 rapidjson 0.0491378307 0.0377278328 performance/guids.json: (x10000) module decoding encoding dkjson 2.3570721149 3.0556299686 cjson 0.1626739502 0.1092689037 rapidjson 0.1135668755 0.0830221176 performance/paragraphs.json: (x10000) module decoding encoding dkjson 8.5023150444 31.5211300850 cjson 0.8555159569 0.6739630699 rapidjson 0.3181121349 0.1543619633 performance/floats.json: (x10000) module decoding encoding dkjson 2.1173479557 1.7756278515 cjson 0.1096220016 0.3009288311 rapidjson 0.0733149052 0.1116719246 performance/integers.json: (x10000) module decoding encoding dkjson 1.7672340870 1.3564231396 cjson 0.0811710358 0.2808339596 rapidjson 0.0581030846 0.0484278202 performance/mixed.json: (x10000) module decoding encoding dkjson 16.8118801117 13.2526481152 cjson 1.3187069893 0.7380268574 rapidjson 1.3779308796 0.4688320160
Edit: I have implemented it across all of my plugins without the openLuup.json wrapper and have been running error free. Will let you know in a couple of days if I would recommend this but it is looking very good so far... It can completely and seemlessly replace dkjson.
installation instruction:luarocks install rapidjson --server https://luarocks.org/dev
Then run a replace of dkjson and cjson to rapidjson in every lua file in the openluup and plugin lua file folder.
Ezlo have made an announcement about their new web GUI.Apr 26 EZLO WEB UI in Beta EZLO WEB UI in Beta
Ezlo WEB UI Beta release notes: We are releasing ability to do backup of all user data for Linux controllers with Ezlo WEB UI. It will be possible to: Create a backup. Restore from the backup Have the visibility for backup creation progress Settings Ezlo mobile apps already have support for...
Its very alpha however. Hopefully their dev's can get it in to shape and add our feature requests ?
Can you banned guys still see the screen shots on the threads?
There are no recent topics.