Is there a way to get a variable from a rule into an expression of some other rule?
Just like what Vera Reactor did with the Export button then allowing you to reference that variable in another rule set. I'm guessing there's a function like there was in vera getstate()? Thanks
Hopefully my question is clear, it's late 🙂
Every now and then my openLuup stops responding. This is the LuaUPnP.log when it happens:
2021-08-20 14:59:39.827 :: openLuup LOG ROTATION :: (runtime 11.0 days) 2021-08-20 14:59:39.831 openLuup.server:: GET /data_request?id=sdata HTTP/1.1 tcp{client}: 0x55b6023b8088 2021-08-20 14:59:39.853 openLuup.server:: request completed (49215 bytes, 4 chunks, 22 ms) tcp{client}: 0x55b6023b8088 2021-08-20 14:59:39.854 openLuup.io.server:: HTTP:3480 connection closed openLuup.server.receive closed tcp{client}: 0x55b6023b8088 2021-08-20 14:59:40.826 openLuup.io.server:: HTTP:3480 connection from 127.0.0.1 tcp{client}: 0x55b600f46ab8 2021-08-20 14:59:40.829 openLuup.server:: GET /data_request?id=sdata HTTP/1.1 tcp{client}: 0x55b600f46ab8 2021-08-20 14:59:40.846 openLuup.server:: request completed (49215 bytes, 4 chunks, 16 ms) tcp{client}: 0x55b600f46ab8 2021-08-20 14:59:40.847 openLuup.io.server:: HTTP:3480 connection closed openLuup.server.receive closed tcp{client}: 0x55b600f46ab8 2021-08-20 14:59:41.827 openLuup.io.server:: HTTP:3480 connection from 127.0.0.1 tcp{client}: 0x55b600d1ad98 2021-08-20 14:59:41.829 openLuup.server:: GET /data_request?id=sdata HTTP/1.1 tcp{client}: 0x55b600d1ad98 2021-08-20 14:59:41.838 openLuup.server:: request completed (49215 bytes, 4 chunks, 8 ms) tcp{client}: 0x55b600d1ad98 2021-08-20 14:59:41.838 openLuup.io.server:: HTTP:3480 connection closed openLuup.server.receive closed tcp{client}: 0x55b600d1ad98 2021-08-20 14:59:42.827 openLuup.io.server:: HTTP:3480 connection from 127.0.0.1 tcp{client}: 0x55b6016b9848 2021-08-20 14:59:42.829 openLuup.server:: GET /data_request?id=sdata HTTP/1.1 tcp{client}: 0x55b6016b9848 2021-08-20 14:59:42.847 openLuup.server:: request completed (49215 bytes, 4 chunks, 17 ms) tcp{client}: 0x55b6016b9848 2021-08-20 14:59:42.876 openLuup.io.server:: HTTP:3480 connection closed openLuup.server.receive closed tcp{client}: 0x55b6016b9848 2021-08-20 14:59:43.054 luup.watch_callback:: 30003.DS18B20.Temperature called [37]virtualSensorWatchCallback() function: 0x55b600c2fff0 2021-08-20 14:59:43.054 luup.variable_set:: 38.urn:toggledbits-com:serviceId:VirtualSensor1.PreviousRawValue was: 28.3 now: 28.5 #hooks:0 2021-08-20 14:59:43.054 luup.variable_set:: 38.urn:toggledbits-com:serviceId:VirtualSensor1.RawValue was: 28.5 now: 28.4 #hooks:0 2021-08-20 14:59:43.054 luup.variable_set:: 38.urn:upnp-org:serviceId:TemperatureSensor1.CurrentTemperature was: 28.5 now: 28.4 #hooks:0 2021-08-20 14:59:43.054 luup.variable_set:: 38.urn:toggledbits-com:serviceId:VirtualSensor1.PreviousValue was: 28.3 now: 28.5 #hooks:0 2021-08-20 14:59:43.054 luup.variable_set:: 38.urn:toggledbits-com:serviceId:VirtualSensor1.LastUpdate was: 1629464323 now: 1629464383 #hooks:0 2021-08-20 14:59:43.265 openLuup.server:: request completed (3193 bytes, 1 chunks, 5550 ms) tcp{client}: 0x55b60162e488 2021-08-20 14:59:43.267 openLuup.io.server:: HTTP:3480 connection closed openLuup.server.receive closed tcp{client}: 0x55b60162e488 2021-08-20 14:59:43.278 openLuup.io.server:: HTTP:3480 connection from 127.0.0.1 tcp{client}: 0x55b6023c8458 2021-08-20 14:59:43.278 openLuup.server:: GET /data_request?id=status&DataVersion=516611499&Timeout=15&MinimumDelay=100&output_format=json&_r=1629464383277 HTTP/1.1 tcp{client}: 0x55b6023c8458 2021-08-20 14:59:43.381 openLuup.server:: request completed (1091 bytes, 1 chunks, 102 ms) tcp{client}: 0x55b6023c8458 2021-08-20 14:59:43.381 openLuup.io.server:: HTTP:3480 connection closed openLuup.server.receive closed tcp{client}: 0x55b6023c8458 2021-08-20 14:59:43.392 openLuup.io.server:: HTTP:3480 connection from 127.0.0.1 tcp{client}: 0x55b6013d6cc8 2021-08-20 14:59:43.393 openLuup.server:: GET /data_request?id=status&DataVersion=516611500&Timeout=15&MinimumDelay=100&output_format=json&_r=1629464383391 HTTP/1.1 tcp{client}: 0x55b6013d6cc8 2021-08-20 14:59:43.496 openLuup.server:: request completed (3196 bytes, 1 chunks, 4981 ms) tcp{client}: 0x55b601a37db8 2021-08-20 14:59:43.826 openLuup.io.server:: HTTP:3480 connection from 127.0.0.1 tcp{client}: 0x55b601d05a08 2021-08-20 14:59:43.828 openLuup.server:: GET /data_request?id=sdata HTTP/1.1 tcp{client}: 0x55b601d05a08 2021-08-20 14:59:43.844 openLuup.server:: request completed (49215 bytes, 4 chunks, 15 ms) tcp{client}: 0x55b601d05a08 2021-08-20 14:59:43.844 openLuup.io.server:: HTTP:3480 connection closed openLuup.server.receive closed tcp{client}: 0x55b601d05a08 2021-08-20 14:59:44.524 openLuup.server:: GET /data_request?id=lu_status2&output_format=json&DataVersion=516611500&Timeout=60&MinimumDelay=1500&_=1629292536029 HTTP/1.1 tcp{client}: 0x55b601a37db8 2021-08-20 14:59:44.828 openLuup.io.server:: HTTP:3480 connection from 127.0.0.1 tcp{client}: 0x55b6023a7d18 2021-08-20 14:59:44.831 openLuup.server:: GET /data_request?id=sdata HTTP/1.1 tcp{client}: 0x55b6023a7d18 2021-08-20 14:59:44.844 openLuup.server:: request completed (49215 bytes, 4 chunks, 12 ms) tcp{client}: 0x55b6023a7d18 2021-08-20 14:59:44.844 openLuup.io.server:: HTTP:3480 connection closed openLuup.server.receive closed tcp{client}: 0x55b6023a7d18 2021-08-20 14:59:45.514 openLuup.server:: GET /data_request?id=variableget&DeviceNum=0&serviceId=urn:micasaverde-com:serviceId:HomeAutomationGateway1&Variable=Mode&_=1629292536030 HTTP/1.1 tcp{client}: 0x55b601ab8228 2021-08-20 14:59:45.617 openLuup.server:: request completed (1 bytes, 1 chunks, 102 ms) tcp{client}: 0x55b601ab8228 2021-08-20 14:59:45.827 openLuup.io.server:: HTTP:3480 connection from 127.0.0.1 tcp{client}: 0x55b600b8de38 2021-08-20 14:59:45.828 openLuup.server:: GET /data_request?id=sdata HTTP/1.1 tcp{client}: 0x55b600b8de38 2021-08-20 14:59:45.834 openLuup.server:: request completed (49215 bytes, 4 chunks, 5 ms) tcp{client}: 0x55b600b8de38 2021-08-20 14:59:45.836 openLuup.io.server:: HTTP:3480 connection closed openLuup.server.receive closed tcp{client}: 0x55b600b8de38 2021-08-20 14:59:46.828 openLuup.io.server:: HTTP:3480 connection from 127.0.0.1 tcp{client}: 0x55b6018a53f8 2021-08-20 14:59:46.830 openLuup.server:: GET /data_request?id=sdata HTTP/1.1 tcp{client}: 0x55b6018a53f8 2021-08-20 14:59:46.841 openLuup.server:: request completed (49215 bytes, 4 chunks, 11 ms) tcp{client}: 0x55b6018a53f8 2021-08-20 14:59:46.842 openLuup.io.server:: HTTP:3480 connection closed openLuup.server.receive closed tcp{client}: 0x55b6018a53f8 2021-08-20 14:59:47.829 openLuup.io.server:: HTTP:3480 connection from 127.0.0.1 tcp{client}: 0x55b600d2d938 2021-08-20 14:59:47.832 openLuup.server:: GET /data_request?id=sdata HTTP/1.1 tcp{client}: 0x55b600d2d938 2021-08-20 14:59:47.854 openLuup.server:: request completed (49215 bytes, 4 chunks, 21 ms) tcp{client}: 0x55b600d2d938 2021-08-20 14:59:47.855 openLuup.io.server:: HTTP:3480 connection closed openLuup.server.receive closed tcp{client}: 0x55b600d2d938 2021-08-20 14:59:47.962 luup.variable_set:: 10086.urn:upnp-org:serviceId:TemperatureSensor1.CurrentTemperature was: 28.3 now: 28.5 #hooks:0 2021-08-20 14:59:48.370 openLuup.server:: request completed (1359 bytes, 1 chunks, 4977 ms) tcp{client}: 0x55b6013d6cc8 2021-08-20 14:59:48.372 openLuup.server:: request completed (1359 bytes, 1 chunks, 3847 ms) tcp{client}: 0x55b601a37db8 2021-08-20 14:59:48.373 openLuup.io.server:: HTTP:3480 connection closed openLuup.server.receive closed tcp{client}: 0x55b6013d6cc8 2021-08-20 14:59:48.384 openLuup.io.server:: HTTP:3480 connection from 127.0.0.1 tcp{client}: 0x55b601e62df8 2021-08-20 14:59:48.385 openLuup.server:: GET /data_request?id=status&DataVersion=516611502&Timeout=15&MinimumDelay=100&output_format=json&_r=1629464388383 HTTP/1.1 tcp{client}: 0x55b601e62df8 2021-08-20 14:59:48.813 openLuup.server:: GET /data_request?id=lu_status2&output_format=json&DataVersion=516611502&Timeout=60&MinimumDelay=1500&_=1629292536031 HTTP/1.1 tcp{client}: 0x55b601a37db8 2021-08-20 14:59:48.829 openLuup.io.server:: HTTP:3480 connection from 127.0.0.1 tcp{client}: 0x55b600c44bf8 2021-08-20 14:59:48.832 openLuup.server:: GET /data_request?id=sdata HTTP/1.1 tcp{client}: 0x55b600c44bf8 2021-08-20 14:59:48.854 openLuup.server:: request completed (49215 bytes, 4 chunks, 21 ms) tcp{client}: 0x55b600c44bf8 2021-08-20 14:59:48.856 openLuup.io.server:: HTTP:3480 connection closed openLuup.server.receive closed tcp{client}: 0x55b600c44bf8 2021-08-20 14:59:49.829 openLuup.io.server:: HTTP:3480 connection from 127.0.0.1 tcp{client}: 0x55b600e1fea8 2021-08-20 14:59:49.830 openLuup.server:: GET /data_request?id=sdata HTTP/1.1 tcp{client}: 0x55b600e1fea8 2021-08-20 14:59:49.835 openLuup.server:: request completed (49215 bytes, 4 chunks, 5 ms) tcp{client}: 0x55b600e1fea8 2021-08-20 14:59:49.835 openLuup.io.server:: HTTP:3480 connection closed openLuup.server.receive closed tcp{client}: 0x55b600e1fea8 2021-08-20 14:59:50.831 openLuup.io.server:: HTTP:3480 connection from 127.0.0.1 tcp{client}: 0x55b601cfa118 2021-08-20 14:59:50.832 openLuup.server:: GET /data_request?id=sdata HTTP/1.1 tcp{client}: 0x55b601cfa118 2021-08-20 14:59:50.837 openLuup.server:: request completed (49215 bytes, 4 chunks, 4 ms) tcp{client}: 0x55b601cfa118 2021-08-20 14:59:50.838 openLuup.io.server:: HTTP:3480 connection closed openLuup.server.receive closed tcp{client}: 0x55b601cfa118 2021-08-20 14:59:51.833 openLuup.io.server:: HTTP:3480 connection from 127.0.0.1 tcp{client}: 0x55b601462bb8 2021-08-20 14:59:51.835 openLuup.server:: GET /data_request?id=sdata HTTP/1.1 tcp{client}: 0x55b601462bb8 2021-08-20 14:59:51.852 openLuup.server:: request completed (49215 bytes, 4 chunks, 17 ms) tcp{client}: 0x55b601462bb8 2021-08-20 14:59:51.854 openLuup.io.server:: HTTP:3480 connection closed openLuup.server.receive closed tcp{client}: 0x55b601462bb8 2021-08-20 14:59:52.834 openLuup.io.server:: HTTP:3480 connection from 127.0.0.1 tcp{client}: 0x55b6016b1c98 2021-08-20 14:59:52.836 openLuup.server:: GET /data_request?id=sdata HTTP/1.1 tcp{client}: 0x55b6016b1c98 2021-08-20 14:59:52.847 openLuup.server:: request completed (49215 bytes, 4 chunks, 11 ms) tcp{client}: 0x55b6016b1c98 2021-08-20 14:59:52.848 openLuup.io.server:: HTTP:3480 connection closed openLuup.server.receive closed tcp{client}: 0x55b6016b1c98 2021-08-20 14:59:53.193 luup.variable_set:: 10005.urn:micasaverde-com:serviceId:SceneController1.sl_SceneActivated was: 255 now: 255 #hooks:0 2021-08-20 14:59:53.193 luup.variable_set:: 10006.urn:micasaverde-com:serviceId:HaDevice1.sl_TamperAlarm was: 0 now: 0 #hooks:0 2021-08-20 14:59:53.193 luup.variable_set:: 10094.urn:micasaverde-com:serviceId:HaDevice1.sl_BatteryAlarm was: 0 now: 0 #hooks:0 2021-08-20 14:59:53.193 luup.variable_set:: 10096.urn:micasaverde-com:serviceId:HaDevice1.sl_BatteryAlarm was: 10 now: 10 #hooks:0 2021-08-20 14:59:53.193 luup.variable_set:: 10098.urn:micasaverde-com:serviceId:HaDevice1.sl_BatteryAlarm was: 10 now: 10 #hooks:0 2021-08-20 14:59:53.193 luup.variable_set:: 10104.urn:micasaverde-com:serviceId:HaDevice1.sl_BatteryAlarm was: 10 now: 10 #hooks:0 2021-08-20 14:59:53.194 luup.variable_set:: 10106.urn:micasaverde-com:serviceId:HaDevice1.sl_BatteryAlarm was: 0 now: 0 #hooks:0 2021-08-20 14:59:53.194 luup.variable_set:: 10109.urn:micasaverde-com:serviceId:HaDevice1.sl_BatteryAlarm was: 0 now: 0 #hooks:0 2021-08-20 14:59:53.194 luup.variable_set:: 10112.urn:micasaverde-com:serviceId:DoorLock1.sl_UserCode was: UserID="4" UserName="Ella" now: UserID="4" UserName="Ella" #hooks:0 2021-08-20 14:59:53.194 luup.variable_set:: 10112.urn:micasaverde-com:serviceId:DoorLock1.sl_LockButton was: 1 now: 1 #hooks:0 2021-08-20 14:59:53.194 luup.variable_set:: 10112.urn:micasaverde-com:serviceId:DoorLock1.sl_PinFailed was: 1 now: 1 #hooks:0 2021-08-20 14:59:53.194 luup.variable_set:: 10112.urn:micasaverde-com:serviceId:HaDevice1.sl_BatteryAlarm was: 0 now: 0 #hooks:0 2021-08-20 14:59:53.194 luup.variable_set:: 10131.urn:micasaverde-com:serviceId:HaDevice1.sl_TamperAlarm was: 0 now: 0 #hooks:0 2021-08-20 14:59:53.194 luup.variable_set:: 10132.urn:micasaverde-com:serviceId:HaDevice1.sl_TamperAlarm was: 0 now: 0 #hooks:0 2021-08-20 14:59:53.194 luup.variable_set:: 10133.urn:micasaverde-com:serviceId:HaDevice1.sl_TamperAlarm was: 0 now: 0 #hooks:0 2021-08-20 14:59:53.194 luup.variable_set:: 10165.urn:micasaverde-com:serviceId:HaDevice1.sl_Alarm was: SMOKE now: SMOKE #hooks:0 2021-08-20 14:59:53.194 luup.variable_set:: 10165.urn:micasaverde-com:serviceId:HaDevice1.sl_TamperAlarm was: 0 now: 0 #hooks:0 2021-08-20 14:59:53.194 luup.variable_set:: 10188.urn:micasaverde-com:serviceId:HaDevice1.sl_TamperAlarm was: 1 now: 1 #hooks:0 2021-08-20 14:59:53.194 luup.variable_set:: 10188.urn:micasaverde-com:serviceId:HaDevice1.sl_Alarm was: TAMPER_ALARM now: TAMPER_ALARM #hooks:0 2021-08-20 14:59:53.194 luup.variable_set:: 10191.urn:micasaverde-com:serviceId:HaDevice1.sl_BatteryAlarm was: 10 now: 10 #hooks:0 2021-08-20 14:59:53.299 openLuup.server:: request completed (5449 bytes, 1 chunks, 4485 ms) tcp{client}: 0x55b601a37db8 2021-08-20 14:59:53.505 openLuup.server:: request completed (5449 bytes, 1 chunks, 5119 ms) tcp{client}: 0x55b601e62df8 2021-08-20 14:59:53.511 openLuup.io.server:: HTTP:3480 connection closed openLuup.server.receive closed tcp{client}: 0x55b601e62df8 2021-08-20 14:59:53.513 openLuup.server:: GET /data_request?id=lu_status2&output_format=json&DataVersion=516611523&Timeout=60&MinimumDelay=1500&_=1629292536032 HTTP/1.1 tcp{client}: 0x55b601a37db8 2021-08-20 14:59:53.522 openLuup.io.server:: HTTP:3480 connection from 127.0.0.1 tcp{client}: 0x55b600bc7068 2021-08-20 14:59:53.524 openLuup.server:: GET /data_request?id=status&DataVersion=516611523&Timeout=15&MinimumDelay=100&output_format=json&_r=1629464393521 HTTP/1.1 tcp{client}: 0x55b600bc7068 2021-08-20 14:59:53.834 openLuup.io.server:: HTTP:3480 connection from 127.0.0.1 tcp{client}: 0x55b601b8cbe8 2021-08-20 14:59:53.835 openLuup.server:: GET /data_request?id=sdata HTTP/1.1 tcp{client}: 0x55b601b8cbe8 2021-08-20 14:59:53.840 openLuup.server:: request completed (49215 bytes, 4 chunks, 5 ms) tcp{client}: 0x55b601b8cbe8 2021-08-20 14:59:53.841 openLuup.io.server:: HTTP:3480 connection closed openLuup.server.receive closed tcp{client}: 0x55b601b8cbe8 2021-08-20 14:59:54.834 openLuup.io.server:: HTTP:3480 connection from 127.0.0.1 tcp{client}: 0x55b6013dacd8 2021-08-20 14:59:54.836 openLuup.server:: GET /data_request?id=sdata HTTP/1.1 tcp{client}: 0x55b6013dacd8 2021-08-20 14:59:54.849 openLuup.server:: request completed (49215 bytes, 4 chunks, 12 ms) tcp{client}: 0x55b6013dacd8 2021-08-20 14:59:54.850 openLuup.io.server:: HTTP:3480 connection closed openLuup.server.receive closed tcp{client}: 0x55b6013dacd8 2021-08-20 14:59:55.835 openLuup.io.server:: HTTP:3480 connection from 127.0.0.1 tcp{client}: 0x55b602316198 2021-08-20 14:59:55.836 openLuup.server:: GET /data_request?id=sdata HTTP/1.1 tcp{client}: 0x55b602316198 2021-08-20 14:59:55.841 openLuup.server:: request completed (49215 bytes, 4 chunks, 5 ms) tcp{client}: 0x55b602316198 2021-08-20 14:59:55.842 openLuup.io.server:: HTTP:3480 connection closed openLuup.server.receive closed tcp{client}: 0x55b602316198 2021-08-20 15:00:10.955 openLuup.io.server:: HTTP:3480 connection from 127.0.0.1 tcp{client}: 0x55b601547598 2021-08-20 15:00:10.955 openLuup.io.server:: HTTP:3480 connection from 127.0.0.1 tcp{client}: 0x55b6016c7cf8 2021-08-20 15:00:10.955 openLuup.io.server:: HTTP:3480 connection from 127.0.0.1 tcp{client}: 0x55b600b75158 2021-08-20 15:00:10.955 openLuup.io.server:: HTTP:3480 connection from 127.0.0.1 tcp{client}: 0x55b60187d188 2021-08-20 15:00:10.955 openLuup.io.server:: HTTP:3480 connection from 127.0.0.1 tcp{client}: 0x55b6011a5bf8 2021-08-20 15:00:10.955 openLuup.io.server:: HTTP:3480 connection from 127.0.0.1 tcp{client}: 0x55b60115ecd8 2021-08-20 15:00:10.955 openLuup.io.server:: HTTP:3480 connection from 127.0.0.1 tcp{client}: 0x55b601018c18 2021-08-20 15:00:10.956 openLuup.io.server:: HTTP:3480 connection from 127.0.0.1 tcp{client}: 0x55b60175d068 2021-08-20 15:00:10.956 openLuup.io.server:: HTTP:3480 connection from 127.0.0.1 tcp{client}: 0x55b60224ced8 2021-08-20 15:00:10.956 openLuup.io.server:: HTTP:3480 connection from 127.0.0.1 tcp{client}: 0x55b6017869d8 2021-08-20 15:00:10.956 openLuup.io.server:: HTTP:3480 connection from 127.0.0.1 tcp{client}: 0x55b601ab40e8 2021-08-20 15:00:10.956 openLuup.io.server:: HTTP:3480 connection from 127.0.0.1 tcp{client}: 0x55b601914178 2021-08-20 15:00:10.956 openLuup.io.server:: HTTP:3480 connection from 127.0.0.1 tcp{client}: 0x55b60100a228 2021-08-20 15:00:10.956 openLuup.io.server:: HTTP:3480 connection from 127.0.0.1 tcp{client}: 0x55b60197a998 2021-08-20 15:00:10.956 openLuup.io.server:: HTTP:3480 connection from 127.0.0.1 tcp{client}: 0x55b601103238 2021-08-20 15:00:10.956 openLuup.io.server:: MQTT:1888 connection from 127.0.0.1 tcp{client}: 0x55b600c62438 2021-08-20 15:00:10.956 openLuup.io.server:: MQTT:1888 connection from 127.0.0.1 tcp{client}: 0x55b601eaabf8 2021-08-20 15:00:10.956 openLuup.io.server:: MQTT:1888 connection from 127.0.0.1 tcp{client}: 0x55b6017c95b8 2021-08-20 15:00:10.956 openLuup.io.server:: MQTT:1888 connection from 127.0.0.1 tcp{client}: 0x55b600d6e508 2021-08-20 15:00:10.956 openLuup.io.server:: MQTT:1888 connection from 127.0.0.1 tcp{client}: 0x55b601dd2168 2021-08-20 15:00:10.956 openLuup.io.server:: MQTT:1888 connection from 127.0.0.1 tcp{client}: 0x55b60155eb68 2021-08-20 15:00:10.957 openLuup.io.server:: MQTT:1888 connection from 127.0.0.1 tcp{client}: 0x55b6016ddcd8 2021-08-20 15:00:10.957 openLuup.io.server:: MQTT:1888 connection from 127.0.0.1 tcp{client}: 0x55b602384ca8 2021-08-20 15:00:10.957 openLuup.io.server:: MQTT:1888 connection from 127.0.0.1 tcp{client}: 0x55b60230cc78 2021-08-20 15:00:10.957 openLuup.io.server:: MQTT:1888 connection from 127.0.0.1 tcp{client}: 0x55b6017e3338 2021-08-20 15:00:10.957 openLuup.io.server:: MQTT:1888 connection from 127.0.0.1 tcp{client}: 0x55b600965de8 2021-08-20 15:00:10.957 openLuup.io.server:: MQTT:1888 connection from 127.0.0.1 tcp{client}: 0x55b601e23608 2021-08-20 15:00:10.957 openLuup.io.server:: MQTT:1888 connection from 127.0.0.1 tcp{client}: 0x55b6018da2f8 2021-08-20 15:00:10.957 openLuup.io.server:: MQTT:1888 connection from 127.0.0.1 tcp{client}: 0x55b600c9aa08 2021-08-20 15:00:10.957 openLuup.io.server:: MQTT:1888 connection from 127.0.0.1 tcp{client}: 0x55b600bbf0f8 2021-08-20 15:00:10.957 openLuup.io.server:: MQTT:1888 connection from 127.0.0.1 tcp{client}: 0x55b601334518 2021-08-20 15:00:10.958 openLuup.io.server:: MQTT:1888 connection from 127.0.0.1 tcp{client}: 0x55b60183b5f8 2021-08-20 15:00:10.958 openLuup.io.server:: MQTT:1888 connection from 127.0.0.1 tcp{client}: 0x55b6015682a8 2021-08-20 15:00:10.958 openLuup.io.server:: MQTT:1888 connection from 127.0.0.1 tcp{client}: 0x55b6018869e8 2021-08-20 15:00:10.958 openLuup.io.server:: MQTT:1888 connection from 127.0.0.1 tcp{client}: 0x55b6008839c8 2021-08-20 15:00:10.958 openLuup.io.server:: MQTT:1888 connection from 127.0.0.1 tcp{client}: 0x55b60154ed58 2021-08-20 15:00:10.959 openLuup.io.server:: MQTT:1888 connection from 127.0.0.1 tcp{client}: 0x55b601a259e8 2021-08-20 15:00:10.959 openLuup.io.server:: MQTT:1888 connection from 127.0.0.1 tcp{client}: 0x55b600f617c8 2021-08-20 15:00:10.959 openLuup.io.server:: MQTT:1888 connection from 127.0.0.1 tcp{client}: 0x55b6015884c8 2021-08-20 15:00:10.959 openLuup.io.server:: MQTT:1888 connection from 127.0.0.1 tcp{client}: 0x55b601c85fe8 2021-08-20 15:00:10.959 openLuup.io.server:: MQTT:1888 connection from 127.0.0.1 tcp{client}: 0x55b602275ae8 2021-08-20 15:00:10.959 openLuup.io.server:: MQTT:1888 connection from 127.0.0.1 tcp{client}: 0x55b60190ab88 2021-08-20 15:00:10.959 openLuup.io.server:: MQTT:1888 connection from 127.0.0.1 tcp{client}: 0x55b601692038 2021-08-20 15:00:10.959 openLuup.io.server:: MQTT:1888 connection from 127.0.0.1 tcp{client}: 0x55b601fcea78 2021-08-20 15:00:10.960 openLuup.io.server:: MQTT:1888 connection from 127.0.0.1 tcp{client}: 0x55b601ca7f28 2021-08-20 15:00:10.960 openLuup.io.server:: MQTT:1888 connection from 127.0.0.1 tcp{client}: 0x55b601fd37f8 2021-08-20 15:00:10.960 openLuup.io.server:: MQTT:1888 connection from 127.0.0.1 tcp{client}: 0x55b6020ec968 2021-08-20 15:00:10.961 openLuup.server:: GET /data_request?id=variableget&DeviceNum=0&serviceId=urn:micasaverde-com:serviceId:HomeAutomationGateway1&Variable=Mode&_=1629292536033 HTTP/1.1 tcp{client}: 0x55b601ab8228 2021-08-20 15:00:10.967 luup_log:0: 32Mb, 3.3%cpu, 11.0days 2021-08-20 15:00:10.972 openLuup.server:: request completed (3361 bytes, 1 chunks, 17459 ms) tcp{client}: 0x55b601a37db8 2021-08-20 15:00:10.973 openLuup.server:: request completed (3361 bytes, 1 chunks, 17449 ms) tcp{client}: 0x55b600bc7068 2021-08-20 15:00:10.990 luup.variable_set:: 10116.urn:upnp-org:serviceId:TemperatureSensor1.CurrentTemperature was: 21.8 now: 21.9 #hooks:0 2021-08-20 15:00:10.990 luup.variable_set:: 10129.urn:micasaverde-com:serviceId:HumiditySensor1.CurrentLevel was: 58.8 now: 58.7 #hooks:0 2021-08-20 15:00:10.991 openLuup.io.server:: MQTT:1888 connection closed tcp{client}: 0x55b600ba45a8 2021-08-20 15:00:10.991 openLuup.mqtt:: closed tcp{client}: 0x55b600ba45a8 2021-08-20 15:00:10.992 openLuup.mqtt:: mqttthing_Klimat kllaren_838dee2e UNSUBSCRIBE from tele/Källartemp/SENSOR tcp{client}: 0x55b600ba45a8 2021-08-20 15:00:10.992 openLuup.mqtt:: ERROR publishing application message for mqtt:tele/Källartemp/SENSOR : closed 2021-08-20 15:00:10.992 openLuup.io.server:: HTTP:3480 connection from 127.0.0.1 tcp{client}: 0x55b601c8c288 2021-08-20 15:00:10.992 openLuup.io.server:: HTTP:3480 connection closed openLuup.server.receive closed tcp{client}: 0x55b600bc7068 2021-08-20 15:00:10.992 openLuup.server:: GET /data_request?id=sdata HTTP/1.1 tcp{client}: 0x55b601547598 2021-08-20 15:00:10.993 openLuup.io.server:: MQTT:1888 connection closed tcp{client}: 0x55b600a62818 2021-08-20 15:00:10.993 openLuup.mqtt:: RECEIVE ERROR: closed tcp{client}: 0x55b600a62818 2021-08-20 15:00:10.994 openLuup.mqtt:: mqttthing_Uttag garaget_6f4265a1 UNSUBSCRIBE from openLuup/update/10149/SwitchPower1/Status tcp{client}: 0x55b600a62818 2021-08-20 15:00:10.994 openLuup.io.server:: MQTT:1888 connection closed tcp{client}: 0x55b600ba8428 2021-08-20 15:00:10.994 openLuup.mqtt:: RECEIVE ERROR: closed tcp{client}: 0x55b600ba8428 2021-08-20 15:00:10.994 openLuup.mqtt:: mqttthing_Takflkt hallen_6da387bf UNSUBSCRIBE from tele/TakfläktHall/LWT tcp{client}: 0x55b600ba8428 2021-08-20 15:00:10.994 openLuup.mqtt:: mqttthing_Takflkt hallen_6da387bf UNSUBSCRIBE from stat/TakfläktHall/POWER2 tcp{client}: 0x55b600ba8428 2021-08-20 15:00:10.994 openLuup.io.server:: MQTT:1888 connection closed tcp{client}: 0x55b600e59b88 2021-08-20 15:00:10.994 openLuup.mqtt:: RECEIVE ERROR: closed tcp{client}: 0x55b600e59b88 2021-08-20 15:00:10.994 openLuup.mqtt:: mqttthing_Klimat sovrummet_0d664e41 UNSUBSCRIBE from openLuup/update/20010/HumiditySensor1/CurrentLevel tcp{client}: 0x55b600e59b88 2021-08-20 15:00:10.994 openLuup.mqtt:: mqttthing_Klimat sovrummet_0d664e41 UNSUBSCRIBE from openLuup/update/20021/TemperatureSensor1/CurrentTemperature tcp{client}: 0x55b600e59b88 2021-08-20 15:00:10.994 openLuup.io.server:: MQTT:1888 connection closed tcp{client}: 0x55b600bd02d8 2021-08-20 15:00:10.994 openLuup.mqtt:: RECEIVE ERROR: closed tcp{client}: 0x55b600bd02d8 2021-08-20 15:00:10.994 openLuup.mqtt:: mqttthing_Entrdrr_6acda58a UNSUBSCRIBE from openLuup/update/10095/SecuritySensor1/Tripped tcp{client}: 0x55b600bd02d8 2021-08-20 15:00:10.995 openLuup.io.server:: MQTT:1888 connection closed tcp{client}: 0x55b600bb6cf8 2021-08-20 15:00:10.995 openLuup.mqtt:: RECEIVE ERROR: closed tcp{client}: 0x55b600bb6cf8 2021-08-20 15:00:10.995 openLuup.mqtt:: mqttthing_Temperatur poolen_a589d192 UNSUBSCRIBE from tele/Pooltemp/SENSOR tcp{client}: 0x55b600bb6cf8 2021-08-20 15:00:10.995 openLuup.io.server:: MQTT:1888 connection closed tcp{client}: 0x55b6009ff868 2021-08-20 15:00:10.995 openLuup.mqtt:: RECEIVE ERROR: closed tcp{client}: 0x55b6009ff868 2021-08-20 15:00:10.995 openLuup.mqtt:: mqttthing_Rrelsesensor hallen_cf7c8293 UNSUBSCRIBE from openLuup/update/20013/SecuritySensor1/Tripped tcp{client}: 0x55b6009ff868 2021-08-20 15:00:10.995 openLuup.io.server:: MQTT:1888 connection closed tcp{client}: 0x55b600a23e28 2021-08-20 15:00:10.995 openLuup.mqtt:: RECEIVE ERROR: closed tcp{client}: 0x55b600a23e28 2021-08-20 15:00:10.995 openLuup.mqtt:: mqttthing_Luftfuktighet badrum_d79a0ffb UNSUBSCRIBE from openLuup/update/10190/HumiditySensor1/CurrentLevel tcp{client}: 0x55b600a23e28 2021-08-20 15:00:10.995 openLuup.io.server:: MQTT:1888 connection closed tcp{client}: 0x55b600bb33b8 2021-08-20 15:00:10.995 openLuup.mqtt:: RECEIVE ERROR: closed tcp{client}: 0x55b600bb33b8 2021-08-20 15:00:10.995 openLuup.mqtt:: mqttthing_Ljussensor hallen_19569c17 UNSUBSCRIBE from openLuup/update/20006/LightSensor1/CurrentLevel tcp{client}: 0x55b600bb33b8 2021-08-20 15:00:10.995 openLuup.io.server:: MQTT:1888 connection closed tcp{client}: 0x55b600a136b8 2021-08-20 15:00:10.995 openLuup.mqtt:: RECEIVE ERROR: closed tcp{client}: 0x55b600a136b8 2021-08-20 15:00:10.995 openLuup.mqtt:: mqttthing_Ljussensor trningsrum_ebf319c5 UNSUBSCRIBE from openLuup/update/20004/LightSensor1/CurrentLevel tcp{client}: 0x55b600a136b8 2021-08-20 15:00:10.995 openLuup.io.server:: MQTT:1888 connection closed tcp{client}: 0x55b600babaa8 2021-08-20 15:00:10.995 openLuup.mqtt:: RECEIVE ERROR: closed tcp{client}: 0x55b600babaa8 2021-08-20 15:00:10.995 openLuup.mqtt:: mqttthing_Solceller watt_e351a23b UNSUBSCRIBE from openLuup/update/10163/LightSensor1/CurrentLevel tcp{client}: 0x55b600babaa8 2021-08-20 15:00:10.995 openLuup.io.server:: MQTT:1888 connection closed tcp{client}: 0x55b6004a9de8 2021-08-20 15:00:10.995 openLuup.mqtt:: RECEIVE ERROR: closed tcp{client}: 0x55b6004a9de8 2021-08-20 15:00:10.995 openLuup.mqtt:: mqttthing_Luftfuktighet dusch_91df9a58 UNSUBSCRIBE from openLuup/update/20008/HumiditySensor1/CurrentLevel tcp{client}: 0x55b6004a9de8 2021-08-20 15:00:10.995 openLuup.io.server:: MQTT:1888 connection closed tcp{client}: 0x55b600b84628 2021-08-20 15:00:10.995 openLuup.mqtt:: RECEIVE ERROR: closed tcp{client}: 0x55b600b84628 2021-08-20 15:00:10.996 openLuup.mqtt:: mqttthing_Altandrr kk_db6d3edd UNSUBSCRIBE from openLuup/update/10097/SecuritySensor1/Tripped tcp{client}: 0x55b600b84628 2021-08-20 15:00:10.996 openLuup.io.server:: MQTT:1888 connection closed tcp{client}: 0x55b600be6548 2021-08-20 15:00:10.996 openLuup.mqtt:: RECEIVE ERROR: closed tcp{client}: 0x55b600be6548 2021-08-20 15:00:10.996 openLuup.mqtt:: mqttthing_Test datarum_adbe85e6 UNSUBSCRIBE from openLuup/update/20007/Dimming1/LoadLevelTarget tcp{client}: 0x55b600be6548 2021-08-20 15:00:10.996 openLuup.mqtt:: mqttthing_Test datarum_adbe85e6 UNSUBSCRIBE from openLuup/update/20007/SwitchPower1/Status tcp{client}: 0x55b600be6548And then in syslog:
Aug 20 15:00:11 username systemd[1]: openluup.service: Control process exited, code=exited status=7 Aug 20 15:00:11 username systemd[1]: openluup.service: Failed with result 'exit-code'.
Feedback / issues with openLuup's built-in MQTT server
Hi,
I need help to create a search within MSR that shows me the name of all sensors in a certain status.
User case: Based on the information from category_num and subcategory_num, return in a string or array the name of all devices that meet the Tripped = 1 status.
Example: generate a warning message of all the windows that are open before triggering the alarm.
Which function should I use in MSR? What would this search look like?
Thanks.
For MSR users with SiteSensor still installed back on Vera, you might want to consider letting MSR take over those duties. Here's a quick run-down of how I imported one of my SiteSensor recipes into a Rule on MSR, using OpenWeather API* as an example.
STEP 1: Copy the Basics from Vera
(a) Go to your Vera > Devices, locate SiteSensor (the main instance, not one of its children devices) and click ► for details then click SETTINGS.
(b) Copy and paste (into Notepad or other text editor) the Request URL along with each of the defined expressions.
STEP 2: Create a Rule on MSR
(c) Jump into Rule Sets and click "Create Rule". Click its title to rename the rule 'OpenWeather (API)" and click 'Rename'.
(d) Decide on appropriate Triggers (in my case, it's an OR group that includes an [INTERVAL] set to "Every 3 hours" plus a few [ENTITY ATTRIBUTE] entries reacting to things like entering/leaving home, waking up, etc.).
(e) In Set Reacion, create an [HTTP REQUEST] > [GET] action.
(f) Paste your old "Request URL" into the "Request URL" box.
FYI GET calls to OpenWeather API* take the form:
http://api.openweathermap.org/data/2.5/weather?zip=<your_ZIP_code>&id=<your_Wx_ID>&appid=<app-id>&units=imperial(g) Create four new blank Expressions (name them openWx, Tx, Hx and Rx).
(h) Click SAVE & EXIT
STEP 3: Process the Response
(i) Re-open rule "OpenWeather (API)" by clicking the 'Edit' icon.
(j) Within the [HTTP REQUEST] action, assign "Capture response to:" ► openWx
(k) Down in Expressions, click "[+]Add Expresssion" then enter the following:
Tx := round(openWx.main.temp,1)
// yields current outdoor temperature
Hx := round(openWx.main.humidity)
// yields current humidity conditions
Rx := openWx.rain ? ( openWx.rain['3h'] ? openWx.rain['3h'] : 0) : 0
// yields predicted rainfall, if present; otherwise 0
(l) Click SAVE & EXIT. Enjoy!
Naturally, your specific needs and workflow will differ from the one I've outlined here. For instance, you may wish to explore the contents of the JSON object in openWx for additional data of interest to you, and define variables to match.
My goal here has been to illustrate some key concepts needed for moving from SiteSensor over to MSR:
Some syntax is the same, such as dot notation for object.item.access; Other syntax has changed, such as the use of ternary A ? B : C in place of IF (A, B, C); Manually setting an [INTERVAL] in lieu of SiteSensor's timed schedule;Pro tip: If your workflow demands that other Rules react to the output of the "OpenWeather (API)" rule, then be sure to create all of the aforementioned Expressions under "Global Expressions" instead, so they become accessible across all Rule Sets.
Once the transition is complete, you can either DISARM SiteSensor on Vera or remove it entirely with "Remove Device" (which will automatically remove all of its child devices).
*Additional reading:
OpenWeather API : https://openweathermap.org/api
FREE SUBSCRIPTION REQUIRED TO USE THIS SERVICE
PRO TIP: See below for optimal way to incorporate OpenWeatherMap into your MSR workflow(s), by enabling the service directly in the reactor.yaml config file.
I have a Hikvision camera for a month and have been playing with it. Now I read a post of cw-kid (post : System integration roadmap) that you can control the camera by HTTP API request. That's cool if that also will work for me. Can someone explain what to enter in MSR for HTTPS request command to do so. (Marked red arrows)
93ca9c9a-9ab1-443c-9201-5efcff3a45e2-image.png
I want to turn the smart supplement light on and off at a specific time. Now I do that with scheduled switch, but it is better to control that with sunrise and sunset function with MSR. I'm curious how it works.
Tried to google, but didn't find a proper solution. Linux environment is chrooted Debian 10 running on Synology NAS.
I created a normal user ("homer") and when trying to su to it with a command "su - homer", it takes about 50 seconds to complete.
Any ideas how to fix this?
I don't know if this was a result of the 21256 update or 21257, but all of my constraints triggers are showing no data. Even if the device has a triggered change. In addition, it is not showing the Conditional match either. In my screenshot, the Front door - auto locks (Day Time) is all true, but it has to be true for 15 minutes. I am not seeing the timer counter either. I tried a couple of browsers and even my tablet. No Data is seen on every rule. The actions are still running though. My lock did auto lock after 15 minutes.
2021-09-15_100734.jpg
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.
@toggledbits Is there a way to get Current Alerts as an entity so I could monitor those and send notifications if needed.
My usecase is sometimes openLuup crashes and MSR picks that up pretty quick, sending a pushover notification to me would get my attention to restart it.
Of course there are many ways to monitor connectivity but since MSR already is doing that it would be neat to take advantage of it.
Hello anyone,
is there a simple trick to send native HASS notifications from MSR? I guess I could call a scene or something with some parameters but I have little experience so would need some clear pointers on this. Thanks in advance!
Hello @toggledbits ,
I'm testing the MSR and have connected VERA, EZLO and Home Assistant to it, i tried to do some automation but i'm missing the sustained for option in triggers
350b4212-73dc-467d-9f6a-ab36851b3b67-image.png
i'm i missing something?
Best regards
Hey guys,
I am new here and decided to move my 10+ year old vera installation to hass.
Decision based upon the activity in this forum, the new Reactor plugin and my NX584 alarm panel being supported by HA.
These have been challenging days where I learned a lot about docker and a lot of other new stuff.
On my path I now stumbled upon an error in importing the reactor files from a recent vera backup into my new rector docker container running on a Qnap TS473A.
The error is:
Fetching current rulesets...
Can't parse config from tools/verabackup.tar: SyntaxError: Unexpected token e in JSON at position 0
at JSON.parse (<anonymous>)
at /opt/reactor/tools/import_reactor_backup.js:382:22
at processTicksAndRejections (internal/process/task_queues.js:95:5)
The backup file must be from a current version of Vera Reactor. This file reports undefined
I am running Reactor 3.8 which is supposed to be the latest according to the auto update.
Any pointers anyone?
I'm trying to migrate a couple of SiteSensors to MSR, and implementing those as rules with HTTP request reactions. MSR build in use is 21243.
Some challenges though, as I'm capturing an array and because I need those values in the array in multiple rules, I have to use global expressions. Seems that these global expressions/variables are not updating after initialization, but if I try local expressions, they update normally.
Screenshot 2021-09-09 at 23.24.52.png
(for testing purposes I'm switching between "g_UplinkResponse" and "temp_local_array" in capture response)
Screenshot 2021-09-09 at 23.37.47.png
Global expressions:
Screenshot 2021-09-09 at 23.29.23.png
So "g_temp_var" and "temp_local_var" should yield the same result, but in this case the values are different (85.9 vs. 36.8, the latter being the most current & correct value)
I also have a test rule using "g_temp_var" just to induce change, but the value stays the same.
Screenshot 2021-09-09 at 23.36.00.png
@toggledbits, have I understood something wrong or could this be a bug?
Have you ever considered running openLuup under LuaJIT instead of Lua5.1 interpreter?
For kicks, I switched my installation to the latest LuaJIT2.1 beta3 dating from 2017 and being a lua5.1 interpreter it is a drop in replacement. I had to move the lfs library from one folder to another likely because of an include path difference but I am seeing a further speed/efficiency improvement vs. lua5.1.
My CPU load has dropped another 25% to now hover around 2.2% down from 2.8%. I have yet to make sure that everything else works but so far everything appears to be the same.
The luajit site claims up to 5x speed increase through the interpreter and 120x improvement through the compiler vs the standard lua5.1.
Screen Shot 2020-07-05 at 23.10.02.png
My initial interest was from being able to access some ffi libraries to handle video streams...
PS: Wow it is pretty impressive under load... browsing through ALTUI which used to cause spikes of CPU utilization from 2.8% to 4.8% now only go from 2.3% to 2.6%. It almost looks like noise. I am running it on a pretty fast x64 thread so it may not be that significant but this could make a big difference on ARM.
Using MSR on Docker. The automation is to send xml body to my Hikvision camera to change the WDR based on the time of day. But getting the following error:
TypeError: Cannot read property 'length' of undefined
at Engine._resume_reaction (/opt/reactor/server/lib/Engine.js:1319:192)
at Engine._process_reaction_queue (/opt/reactor/server/lib/Engine.js:1114:100)
My MSR rule:
HTTP Request: PUT
HTTP Request: http://camipaddr/ISAPI/Image/channels/1/WDR/day
HTTP Header: Content-Type: application/xml; charset="UTF-8"
HTTP Body:
<?xml version="1.0" encoding="UTF-8"?>
<WDR version="2.0" xmlns="http://www.hikvision.com/ver20/XMLSchema">
<mode>open</mode>
<WDRLevel>40</WDRLevel>
</WDR>
Any idea why I am getting the above error?
Thanks.
I am new to this forum. I have been building an Alexa-based smart home for a few years. Overall, works well. I have a curious problem with a smart light. I set up a Kasa smart bulb in a ceiling can fixture. It worked well for at least 2 years. Then it began turning on randomly. Eventually, it began turning off randomly.I swapped out an identical bulb from another fixture and the problem persisted. I just replaced the ceiling fixture with a new one, properly installed, and the problem remained.
I replaced the Kasa bulb with a PlusMinus bulb. I can control it correctly, but the replacement bulb behaves in the same random on/off way.
Any ideas? I am at a loss!
Thanks.
Hi,
Am I correct in assuming that MSR cannot be installed on a pi running HASS.OS?
Thanks.
Hi all,
I am running MSR along HA on a RPi-4. MSR is talking to HA as well as my vera plus. Following a power outage MSR is showing a bunch of error messages complaining about entities not being available along with a yellow triangle besides my rules. My guess is that upon power restoral, MSR becomes ready before vera or HA.
Question:
Assuming that the devices/system used by MSR becomes fully functional, will the rules still properly works or the initial error and the yellow triangle means that they are not operational?I underatand that the ideal situation would be to install UPS (several in my case) on everything related to automation. Falling short of that, I was wondering if there would be a benefit to have something in the MSR configuration to pause its startup, providing dependencies enough time to become ready. This would prevent a bunch of (unnecessary) error message following a power outage. In my case, following a power outage, waiting a couple more minutes is not really an issue.
Tx
@toggledbits
I have Reactor running under openLuup (which is running inside vwout's Docker container).
On the activities tab, it tells me I should update to a newer version of the device information database. When I go to the Tools tab, for a fraction of a second I can see the green "Update Device Info" button along with the Troubleshooting & Support and Device Spy sections. But after that fraction of a second, they disappear and I only see the Test Tools and Update Device Information Database sections, to just above where the Green button used to be.
I've tried this on both Edge and Firefox with the same behavior (with extensions both on and off).
Any suggestions?
Before I unleash the dragon, is this the correct command format? (Answer: YES)
luup.call_action('urn:micasaverde-com:serviceId:ZWaveNetwork1','SendData',{Node='24',Data='x70 4 8 1 3'},1)
I ran that exact command in Vera's APPS > DEVELOP APPS > Test Luup Code (Lua) window -- immediately after waking up the battery-powered remote by tapping one of its buttons -- and it worked perfectly!
LED does what it's supposed to do now. THANK YOU ALL!
Having spent years as a professional portrait photographer, I came by many tricks of the trade involving readily available materials. One such trick is known as an "Oil Spot Photometer", which can help you equalize the brightness of two or more light sources.
For simple setup instructions, visit:
When an oil spot on a card is illuminated equally from both sides, it mysteriously disappears. This allows you to compare the brightness of the light sources on either side of the card.
The implications for Home Automation, of course, is knowing the preset dim levels needed to balance a room's lighting, without guessing. Just bear in mind that dimmer levels and bulb output are rarely linear, so you may have to take photometer readings at various brightness levels to create a lookup table (for use in MSR, etc.).
I'm enjoying this thread as it develops, but will stand by until someone wraps MSR into a Docker package that I can install/run on my Docker-enabled Synology NAS.
Like everyone else, "I'm at full candy corn" (so the Stewie Griffith saying goes) on this project and can't wait to give it a whirl!
Sorry this happened. None of us deserved being kicked out. Especially after twelve dedicated years in my case! The forum was fun and helpful until the moment a certain someone began posting, sadly.
Such is my life. I proofread 1000-page reports for the Army Corps of Engineers and book authors all the time. Nothing gets past me.
It's moments like this that I'm grateful for online Forums where the open exchange of ideas and experience works to everyone's advantage, without fear of reprisal from those "in charge". 
It's been a pleasure watching the evolution of MSR. In fact, it's my primary reason for becoming active on this Forum.
@crille said in My newbie questions:
Thank you all.
I'll manage my use case either with scenes or MSR, just think Veras approach gives a good overview of what happens when I change House mode.
You're right in saying Vera got that particular facility right. Funny, I only discovered that "House Modes options" page very late in the game (i.e. around 2013?) and never bothered to use it beyond un-Arm'ing everything then forgetting about it. (I don't use any physical sensors, anyway.)
But I will say +1 to moving everything to MSR (or at least Reactor for the time being) and away from Scenes and naked Lua. Main reasons: Editability and Portability.
Of course, all your Lua code snippets can be run by Reactor, if that's your thing. I found that every Scene I ever created on Vera could be accomplished more succinctly by Reactor, with the added luxury of Expressions and its powerful runtime logic.
Literally the only Scene I have left on Vera is one which resets Reactor whenever it "trips" (throttles due to too much activity in a short time span). Period. Done. Buh-bye.
ezlo is sinking or swimming (mostly the former) without the benefit of many highly knowledgeable beta testers due to Forum banning. I would not let my dog's dog submit Feedback reports at this stage. At least their employees are (by necessity!) being a lot more responsive, seeing as all the "free labor" has been evicted.
I remember looking at PLEG once... ONCE... and running away. Found Reactor just last year and wonder what I ever did without it.
I know that Sunset and Sunrise times are included with GET calls to:
http://api.openweathermap.org/data/2.5/weather
All you need is an API key and your ZIP code (or other identifier) in the calling URL.
Try establishing a Global Expression containing this definition:
getEntity( "weather>default" ).attributes.wx
The resulting object should include the data you seek.
EDIT: Except, oops, it does not. Sorry, false start.
I think Patrick will take your feedback to heart. What's funny is that I constantly get "Sunrise" and "Sunset" confused (as terms) in my head, so I always have to pay extra special attention when creating such rules. I was so focused that the switch-a-roo escaped my conscious notice.
I had noticed that, too, and wondered if it would impact anyone's workflow. (I so rarely use that condition, it slipped my mind to mention.)
Great feedback! You're not alone in your concern that (a) Vera is EOL, and (b) eZLO may prove to be vaporware in the end (so many bold promises, nothing out of alpha/beta yet). MSR is the much-needed bridge to tide us over and relieve our aging Vera hubs of duty.
Regarding House Mode in MSR, I see those values as (string) = 'home', 'away', etc. But yes, arrays in MSR are zero-indexed, compared with RfV's old 1-based lists. I never once used the Rule migration tool, so perhaps your feedback was connected with that?
@sebby said... (see above screenshot)
Based on your screenshot, it kinda looks like you can't (yet) override the two preset drop-down choices in that menu, in order to insert your own ${{ }} expression? (I'm not using 'Latest' so haven't tested myself.)
I always know the day the cookie expires, even before MSR sends me the warning, because a very specific nighttime Rule (to turn off the screen of my Echo Spot) will fail to run, so the Echo Spot doesn't go "boop" at bedtime.
@noelab said in Synology Docker installation:
just to ask, Is there Importing ReactorSensors from Vera Reactor in synology docker method?
So far as I know, the answer is "Yes" - because that's a built-in feature of MSR, and not dependent on the platform on which it is installed.
Coincidentally, I never used the "Import" feature despite having dozens of rather involved Rules back on Reactor for Vera. My reasoning was, (a) I will likely build them better from scratch, (b) this is my chance to re-think a lot of my logic, and (c) with MSR being immensely more powerful, it was a good excuse to learn lexpjs and contribute (as I wound up doing far more than anticipated) to the bug/suggestion log along the way.
MSR 1.0.0 is a masterpiece. Hope you enjoy the transition.
Quick operational question about VeraAlexa...
I've got a nice Rule in MSR monitoring the 'LastResponse' variable, watching for mention of a "cookie". It then sends me an email, reminding me to visit alexa.amazon.com in order for the cookie to be created again.
My question is: Must I also then go into my 'Alexa' device on Vera and manually change the 'Configured' value from 1 back to 0? I have been doing that, even adding a browser refresh after, but notice such a step is not mentioned in the "no cookie" message. So I'm probably overthinking things.
Thanks for any clarification!
The way that Patrick is suggesting I believe is the more versatile and manageable approach.
Importing ReactorSensors from Vera Reactor - Reactor - Multi-Hub Automation
