@archers Very Cool gadget. I soldered to the flash pins, which given the size of the contacts was challenging, but managed to make it work. Now waiting for my BLE sensors to arrive.
Energy Monitoring built into the dual relay!
Hi Everyone,
I am just starting to move over from Vera to Home Assistant using MSR.
On vera I had been using DelayLight. I have tried to replicate it with help from youtube (https://www.youtube.com/watch?v=fc_ij0D1hXE) Reactor for Vera #006 - Emulating DelayLight in Reactor.
I have created 6 rules that sort of work. but I am just wondering if this is best practice or should can it be built in 1 rule like the old vera way?
I've done a bit of repackaging of MSR to make it work as an add-on under Home Assistant mostly for my own purposes but hopefully it makes it a bit easier to install and get going.
Contribute to mrw298/hassio-reactor-addon development by creating an account on GitHub.
Hi!
I tried to find an answer in both the forum and by myself, without any luck. I'm trying to make my Echo device play a mp3 file. The same mp3 file is easy to play with other smart speakers (Sonos, Google/Nest) - that it no problem. Same approch do not work with Echo devices. The mp3 files I want to use is located on my HA installation (config/www/audio), running on ver. 2023.5.4. I have MSR ver 23114.
Is there a way to do this easily?
Thanks!
/Fanan
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'm controlling a HVAC device through the MQTTController. While setting up the entity config in reactor.yaml, I started with this on the action block:
set_setpoint: topic: "ezlo_mqtt/set/item/%topic%/set/Tsetpoint" payload: expr: "parameters.setpoint" type: rawHowever, as the setpoint is a number in the UI, things were not fully parseable as a number and nothing was outputted to mqtt.
So I've added this code to MQTTController.js at line 1449 to add the payload type 'number':
} else if ( 'number' === act.payload.type ) { payload = String( payload ); } else if (''raw' !== ( act.payload.type || 'raw' ) ) {After this change, I was able to set the payload type to number:
set_setpoint: topic: "ezlo_mqtt/set/item/%topic%/set/Tsetpoint" payload: expr: "parameters.setpoint" type: numberAnd things worked as intended, being able to send numbers in the actions bit of a rule set.
I still use Vera controllers in combination with ReactorSensors. I have several Reactor sensors in use to retrieve weather data from Wunderground (i have a personal weather station), my smartmeter etc.
Recently I installed solar panels with a SolarEdge inverter. SolarEdge has an API to retrieve my power production data from their cloud.
Output is in json.
So I created a new Reactor Sensor. Connection is working (query okay).
But I encounter problems at the Value Expressions. Either I get ""query okay" but no data or I get "query okay but 1 expressions failed"
This is the json output
{"overview":{"lastUpdateTime":"2023-05-12 10:45:57","lifeTimeData":{"energy":476310.0,"revenue":216.577},"lastYearData":{"energy":433001.0},"lastMonthData":{"energy":433001.0},"lastDayData":{"energy":8262.0},"currentPower":{"power":5647.0},"measuredBy":"INVERTER"}}So it has different layers/levels.
I tried to put in the Value Expressions field several combinations to get the energy data of today (8262.0), like:
response.lastDayData.energy
response.overview.lastDayData.energy
response.overview.lastUpdateTime.lastDayData.energy
all fail...
Who can help me with this ?
The wifi on my router is turned off, and wifi around the house is provided using a mesh - 3 units altogether (one connected directly to the router) that are spread around the house.
I would like to start automating certain tasks around the house and intend to try adding a few smart sockets to my setup.
The mesh system I have supports both 2.4GHz and 5GHz, and does not provide me with the option to control them - i.e. turn one or both on/off, give each a different SSID, etc.
The devices I wish to purchase/use only support 2.4GHz.
Will turning the mesh units off and temporarily turning the 2.4GHz wifi on the router to allow me to set them up be enough? Will I then be able to return to my usual setup and everything will work as it should?
Many thanks in advance
Hey everyone, I'm currently working on developing a bed sensor that can detect when you're out of bed. It could be used to trigger other smart home gadgets, like lights or blinds, temperature etc.
The sensors are placed under the legs of your bed post. Should look and feel like "smart furniture pads" with size 2 inches in diameter and 1/4 inch thick.
Before we go any further, I'd love to get your thoughts on this - would a bed sensor like this be something you'd find useful? We're still in the early stages of development, so any feedback you have would be greatly appreciated. Thanks in advance!
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
Good morning all,
I've got a stable Home Assistant running on a RPI 4 with a Aeotec Z-Stick 7 Plus, and of course the Z-wave JS integration. I've manually moved a handful of devices, and I'm overall much happier with the HA z-wave capability than I am with Vera. There are still some things I'm trying to figure out that I have in Vera that I'm not sure how they'll work in HA, but no deal breakers.
I've got all of my automation on MSR and off of luup Reactor, so really the only thing left for me is to migrate my Z-wave network. I saw @rafale77's post about using a Zwave.me UZB1 to Zway, but of course that's not what I'm using.
Is there a similar method that I can use my Aeotec Z-Stick 7 plus to Home Assistant? I have around 70 Z-wave devices (give or take devices that generate multiple instances in Vera), so manual unpairing, including, etc, would be quite a chore.
Good evening,
I was wondering if it would be possible to send out a push notification when there is a update to MSR to HA users. I know how to set up notifications through Reactor to HA users, but I'm unsure what to look for in regards to updates. I know that MSR itself will tell me there is an update, but unless I'm logged into MSR in a browser, I'm not always going to see that.
Just updated to latest-23114-e4060aae MSR
Home Assistant 2023.4.6
Supervisor 2023.04.1
Operating System 10.0
ChatGPT samples:
Me:
Tell me about an iot program called openLuup.
It:
OpenLuup is an open source home automation system that is built on the VeraLuup platform. It is designed to be easy to install and configure, and provides users with a powerful and versatile way to control their home automation devices. OpenLuup offers a wide range of features, including support for many popular home automation devices, scheduling, scripting, and integration with other services. OpenLuup is designed to be customizable, allowing users to create their own home automation systems. It is an excellent choice for those looking to create their own home automation system without spending a lot of money.
Me:
Write an iot program using openLuup.
It:
--openLuup IoT Program-- -- Initialize Variables -- local device_id = "MyHomeDevice" local temperature_sensor_id = "MyTemperatureSensor" local temperature_threshold = 75 -- Create Devices -- luup.create_device("OpenLuup Temperature Sensor", 0, device_id, "D_GenericSensor1.xml", "I_GenericSensor1.xml", "S_TemperatureSensor1.xml", "") luup.variable_set("urn:upnp-org:serviceId:TemperatureSensor1", "CurrentTemperature", 0, device_id) -- Start Timer -- luup.call_delay("check_temperature", 10, "", false) --Function to Check Temperature-- function check_temperature() local current_temperature = luup.variable_get(temperature_sensor_id, "CurrentTemperature", 0) --Check Temperature Threshold-- if current_temperature >= temperature_threshold then --Send Alert-- luup.call_action("urn:micasaverde-com:serviceId:HomeAutomationGateway1", "SendTextMessage", {PhoneNumber="1234567890", Message="ALERT! Temperature exceeded threshold!"}, 0) end --Reset Timer-- luup.call_delay("check_temperature", 10, "", false) endMe:
Write an iot program using openLuup.
It:
Write an iot program using openLuup. -- openLuup IOT Program -- -- Variables local lampState = false local lampTime = 0 -- Functions function lampTimer() if lampTime > 0 then lampTime = lampTime - 1 if lampTime == 0 then luup.variable_set('urn:upnp-org:serviceId:SwitchPower1', 'Status', 0, lampDeviceID) lampState = false end end end -- Setup luup.call_delay('lampTimer', 60, 0) -- Main Loop while true do -- Check for motion if luup.variable_get('urn:micasaverde-com:serviceId:MotionSensor1', 'Tripped', motionSensorDeviceID) == '1' then if not lampState then luup.variable_set('urn:upnp-org:serviceId:SwitchPower1', 'Status', 1, lampDeviceID) lampState = true -- Set lamp timer to 5 minutes lampTime = 300 end end luup.sleep(1) endWhat??
luup.sleep(1)Not good - looks like I still have some semblance of a job to fulfill.
Me:
An iot program called openLuup was written by akbooer. Who is akbooer?
It: (note: answer redacted and as I understand it, also incorrect re: AltUI):
akbooer is the pseudonym of the software developer and home automation enthusiast. He is the creator of the openLuup home automation software, which is an open-source version of the Vera home automation system. He is also the creator of the AltUI graphical user interface for openLuup.
Me:
Who created of the AltUI graphical user interface for openLuup.
and
Me:
Who created of the AltUI graphical user interface for the home automation system Vera.
Names two different people - mmmm.
Regardless very impressive - give it a few more years.
MSR tooltip says that "disabled groups are ignored, as if they did not exist (conditions don't run)".
Just want to clarify if it's by design that actions beneath disabled groups should run? They do run, but intuitively I was expecting them to be disabled as well.
Running the latest build under Docker.
@archers Very Cool gadget. I soldered to the flash pins, which given the size of the contacts was challenging, but managed to make it work. Now waiting for my BLE sensors to arrive.
Energy Monitoring built into the dual relay!
I was seeing similar network issues and also came to the conclusion that the socket library was most likely at fault. My solution is to use Mosquitto as my main broker, which accepts all MQTT traffic (topic # in 0) with all my MQTT devices pointing to it, and then Mosquitto filters push traffic to openLuup. Below is my config file that displays the filters:
allow_anonymous true
password_file /mosquitto/data/PW.txt
listener 1883
connection openLuup
address 127.0.0.1:1882
topic tele/# out
topic stat/# out
topic BlueIris/# out
topic # in 0
cleansession false
notifications true
username *****
password *******
bridge_protocol_version mqttv311
try_private false
log_timestamp true
log_timestamp_format %Y-%m-%d--T_%H:%M:%S
As you can see, Mosquitto runs on the same server as openLuup. It is started by a docker compose file. The config filters eliminated the network errors on openLuup and my openLuup install now runs for days on end without any errors at all. I also have HA running on the same server via docker compose, though I only use it for its Hacs Alexa integration. I pipe my Alexa calls to HA using an HA token and a crude plugin that I wrote. I have not found a use for HA outside of openLuup yet, though there are some interesting integrations I will eventually try out.
As regards MQTT I don't think you need to worry about network traffic so much as mqtt is an extremely light protocol, at least in so far as compared to cameras and hi-def wireless etc ( I have a bunch of these high bandwidth devices on my network in their own subnets). I have found that the thing that tends to bog down is the lua socket function and as long as you limit its connections, you will probably alleviate most of the network problems.
Nginx is one of the best web servers available, specializing in load balancing millions of connections, and from what I've read, it is written in Lua. Which suggests that the lua socket module itself is causing the network issues as Nginx most likely rolled their own network library.
@akbooer I think I found the culprit causing the random connection disconnects to Mosquitto. The LWT payload for a given device is a simple string, which doesn't seem to decode in the json decode call. So I added the below code to send a json string to the decoder. The errors have disappeared and I now see the LWT variable in the service variables. The variable reads "LWT : Online"
--line 165
local valid = {SENSOR = true, STATE = true, RESULT = true, LWT = true}
--line 172
-- begin code
local info, err = json.decode (message)
if message then
if not info then -- json did not decode because of single string parameter
message = '{' .. '"' .. mtype .. '"' .. ':' .. '"' .. message .. '"' .. '}'
end
end
-- end code
local info, err = json.decode (message)
This is probably not the way you would handle the error, but it does work.
@akbooer Tasmota energy sensor
{
"Time": "2021-03-28T21:51:01",
"ENERGY": {
"TotalStartTime": "2020-06-07T00:10:43",
"Total": 2356.063,
"Yesterday": 7.056,
"Today": 6.459,
"Period": 24,
"Power": 285,
"ApparentPower": 302,
"ReactivePower": 99,
"Factor": 0.95,
"Voltage": 123,
"Current": 2.453
}
}
No, you can still configure UDP. You just need login credentials now.
If I have a few moments, I will try to set up one of my Pi machines this weekend with an instance of Mosquitto. My HA server that runs my docker Mosquitto is headless, and I run Ubuntu server, so command line captures of packets are just a drag. My Pi has an hdmi port so I should be able to load the gui version of wireshark, and then test/capture the traffic between the two instances. I will let you know.
@rafale77 hey Rafale,
I went down the very same road a while back and threw in towel because the polling by the MQTT plugin created CPU drags that stopped openLuup from functioning "reliably". The instability was also in part because I use two other must-have plugins that rely on polling, and I imagine that the combination of the three was creating a scenario that caused intermittent failures. And I too ended up implementing MQTT in Home Assistant and then using RealDB's virtual HTTP plugin to send commands to my WiFi devices--albeit not knowing the status of the devices in openLuup after the send.
I'm looking at RigPapa's socket proxy and WebSocket plugins to see if I can transform my polling plugins to Async. The MQTT plugin is too complex for me to convert though, so if you take a crack at it, and are successful, I would very much appreciate you publishing your results, as MQTT is becoming a must for me.
@akbooer I hate to add more to the pile... but I'm still seeing a receive error for the connection to mosquitto. openLuup 2021.04.29b
Here's the log error:
2021-05-01 14:22:38.815 openLuup.io.server:: MQTT:1882 connection closed tcp{client}: 0x5579919e9c58
2021-05-01 14:22:38.816 openLuup.mqtt:: RECEIVE ERROR: closed tcp{client}: 0x5579919e9c58
2021-05-01 14:22:43.935 luup.io.incoming:: bytes received: 51, status: OK tcp{client}: 0x557990e7f528
2021-05-01 14:22:48.435 luup.io.incoming:: bytes received: 51, status: OK tcp{client}: 0x557990e7f528
2021-05-01 14:22:49.763 luup.variable_set:: 10181.urn:micasaverde-com:serviceId:EnergyMetering1.KWHReading was: 1619904116 now: 1619904168 #hooks:0
2021-05-01 14:22:50.158 openLuup.io.server:: HTTP:3480 connection closed openLuup.server.receive closed tcp{client}: 0x557991971ff8
2021-05-01 14:22:53.834 openLuup.io.server:: MQTT:1882 connection from 127.0.0.1 tcp{client}: 0x5579920dc0b8
2021-05-01 14:22:53.834 openLuup.mqtt:: client is in ERROR empty
2021-05-01 14:22:53.834 openLuup.mqtt:: credentials is in ERROR empty
2021-05-01 14:22:53.834 openLuup.mqtt:: subscriptions is in ERROR empty
using the below error trapping in function "MQTTservlet"
local function MQTTservlet (client)
if client == nil then
_log ("client is in ERROR nil")
else
if table.concat(client) == "" then
_log ("client is in ERROR empty")
else
_log (table.concat {"MQTT ERROR: ", table.concat(client)})
end
end
if credentials == nil then
_log ("credentials is in ERROR nil")
else
if table.concat(credentials) == "" then
_log ("credentials is in ERROR empty")
else
_log (table.concat {"MQTT ERROR: ", table.concat(credentials)})
end
end
if subscriptions == nil then
_log ("subscriptions is in ERROR nil")
else
if table.concat(subscriptions) == "" then
_log ("subscriptions is in ERROR empty")
else
_log (table.concat {"MQTT ERROR: ", table.concat(subscriptions)})
end
end
return function () incoming (client, credentials, subscriptions) end
end
I can't find a deeper layer in the stack where I can trap for the incoming message to see what's in the message that is throwing the error. As near as I can tell, if openLuup tries to connect to a running mosquitto instance, then it fails to see the topics and messages, and passes empty--but not nil--strings when the servlet interface sees incoming bytes.
If I restart mosquitto, openLuup then sees the topics and messages and the error messages stop--and the connection to mosquitto remains stable.
This behavior does not occur when I aim an IOT device directly at openLuup--in that the connection to the device always resumes when openLuup reloads--in other words, I don't need to restart the IOT device to enable the connection.
@akbooer Below is the relevant output of a typical packet between mosquitto and a mosquitto bridged instance. In this case, mosquitto is sending update data to the bridge regarding a tasmota device/switch I use to remotely reboot my Vera. The format is definitely MQTT 3.1 and not 5.0, as 5.0 would not parse correctly in the wireshark viewer. The data payload is at the top of the window as Wireshark will truncate long messages. I can PM you the entire capture as it's not much, but may contain technical info that's best kept private. Let me know.
I'll try to capture some traffic between openLuup and mosquitto later.
{"Version":"9.1.0(tasmota)","BuildDateTime":"2020-11-07T11:57:45","Module or Template":"Gosund-WP5","RestartReason":"Software/System restart","Uptime":"6T05:50:22","Hostname":"power_MainVera-0278","IPAddress":"10.17.2.33","RSSI":"100","Signal (dBm)":"-17","WiFi LinkCount":5,"WiFi Downtime":"0T00:00:10","MqttCount":14,"LoadAvg":19}
Frame 9: 433 bytes on wire (3464 bits), 433 bytes captured (3464 bits) on interface eth0, id 0
Ethernet II, Src: Advansus_0a:8c:3a (00:19:0f:0a:8c:3a), Dst: 96:62:08:fb:22:8a (96:62:08:fb:22:8a)
Internet Protocol Version 4, Src: 10.17.2.41, Dst: 10.17.2.110
Transmission Control Protocol, Src Port: 40664, Dst Port: 1882, Seq: 3, Ack: 3, Len: 367
MQ Telemetry Transport Protocol, Publish Message
Header Flags: 0x30, Message Type: Publish Message, QoS Level: At most once delivery (Fire and Forget)
0011 .... = Message Type: Publish Message (3)
.... 0... = DUP Flag: Not set
.... .00. = QoS Level: At most once delivery (Fire and Forget) (0)
.... ...0 = Retain: Not set
Msg Len: 364
Topic Length: 30
Topic: tele/power_MainVera/HASS_STATE
Message [truncated--see above]: {"Version":"9.1.0(tasmota)","BuildDateTime":"2020-11-07T11:57:45","Module or Template":"Gosund-WP5","RestartReason":"Software/System restart","Uptime":"6T05:50:22","Hostname":"power_MainVera-0278","IPAddress":"10.17.2
@buxton In the above, I'm seeing an extra closing right hand bracket in the JSON string.
I've been waiting for something like this. Very cool. Thx for the post
@toggledbits @akbooer Sorry, I will try to be clearer.
" I don't know what "assigning the luup log function to a table" means"
In many of Patrick's plugins, he uses a global lua table to hold plugin data and functions. He assigns shorthand names that call common luup functions, then stores those truncated names in the table. Then the first class functions are called from the table. I believe it is this abstraction that is contributing to log entries that show nil values, as direct calls of "luup.log" do not show nil values. The technique should work in openluup, and most often it does, but sometimes it doesn't.
Here's an example from the log where it does not work:
2022-01-15 14:13:12.551 luup.variable_set:: 258.urn:micasaverde-com:serviceId:HaDevice1.CommFailure was: 0 now: 0 #hooks:0
2022-01-15 14:13:12.551 luup.variable_set:: 258.urn:micasaverde-com:serviceId:HaDevice1.CommFailureTime was: 0 now: 0 #hooks:0
2022-01-15 14:13:12.551 luup_log:149: Reactor: Starting nil (#nil)
2022-01-15 14:13:12.551 luup.variable_set:: 149.urn:toggledbits-com:serviceId:Reactor.Message was: Starting Unused1 now: Starting Basic Functions #hooks:0
2022-01-15 14:13:12.552 luup.variable_set:: 265.urn:toggledbits-com:serviceId:ReactorSensor.Invert was: nil now: #hooks:0
2022-01-15 14:13:12.552 luup.variable_set:: 265.urn:toggledbits-com:serviceId:ReactorSensor.Invert was: now: nil #hooks:0
In the log entry "luup_log:149: Reactor: Starting nil (#nil)" the text of the log entry is there "Reactor: Starting", but the variable following the text is nil. This is what I meant by "picking up on variables". The log entries are being displayed, but anything that is a variable is showing as nil. The variables themselves are not actually nil because I can see from program execution that they are doing the job that they're supposed to be doing. It is only in the log entries that they show as nil, at least insofar as what is visible to me.
As for using nil to delete a variable, that seems to be understood and is separate from the log problem.
I believe that this is a scope problem, thus the title of the post. But I don't believe this is a reactor scope problem in that the same issue does not occur on the Vera itself. So for whatever reason, in openLuup, the scope of the variable being displayed in the log is different from the scope of the log function--that the value of the variable is somehow hidden from the function.
This is a problem as it relates to the readability of the log, an annoyance more than anything, so I have no expectations to have it fixed. In my original screenshots, you can see multiple log entries that display as nil, so that's why I brought this to your attention as I felt that if there are scope issues at work with the logging function, then it could be happening elsewhere as well.
The only other thing that I would add is that in my startup lua, I call a module in the _G space so that I can access functions in the lua section of Reactor activities. My call is _G.myStartUpLua = require("myStartUpLua") I don't believe that this should have an effect on the log, but perhaps it does.
@therealdb Yes, that's where I'm headed too. Agreed that Hass is very stable. It's just that there are real structural changes being made all the time, and before I sink my time into learning the details of the software, I want to be sure that pretty much everything is final in the engine.
@toggledbits Yes, I think that's a large part of the problem as I'm seeing the same behavior with deleted groups in various sensors. The sensor groups flop between nil and empty in the attempt of trying to delete the variable.
There seems to be a separate issue of the openLuup log not picking up on variables for your various plugins log entries.
I'm guessing this has to do with assigning the luup log function to a table and then calling a truncated name ie L(...) when writing to the log. So there is some scope issue going on that is different on openLuup from that of a Vera, brought about by a level of abstraction.
@therealdb Well that's a shame. One more nail in the coffin. I'll probably move to HA as soon as the various versions of the software are consolidated. It's a great platform, but for my needs, it is still too subject to breaking structural changes.
@toggledbits OK. Does that mean that the log entries as shown above are expected ie. that the flopping (from nil to empty and back again) for reactor expression variables is routine?
@akbooer Yes, I tried browser refresh without any change. If you look at the log, you see the variables flopping from nil to empty and then back again to nil.
@therealdb are you seeing anything like this in your openLuup reactor installation? I'm only seeing this nil behavior with Reactor expression variables.
Hi Patrick/AK Booer
I am able to see Reactor expressions in the AltUI UI per the below and the expressions work as they should in my reactor sensors. When an expression changes, the reactor sensor responds accordingly.
However, I cannot see the expressions in luup state variables or the luup logs:
I tried reinstalling openLuup (latest development) and when that failed to change the noted behavior, I reinstalled lua5.1. There was also no change. Rebooting the machine also produced no change.
I suspect this is an openLuup issue as I also see nil values for some plugins:
And other plugins are fine:
2022-01-12 20:47:12.027 luup.variable_set:: 63.urn:upnp-micasaverde-com:serviceId:Weather1.CurrentDewPoint was: 32 now: 29.7 #hooks:0
2022-01-12 20:47:12.028 luup.variable_set:: 63.urn:upnp-micasaverde-com:serviceId:Weather1.WindSpeed was: 1.76 now: 2.8 #hooks:0
2022-01-12 20:47:12.028 luup.variable_set:: 63.urn:micasaverde-com:serviceId:HumiditySensor1.CurrentLevel was: 30 now: 27 #hooks:0
2022-01-12 20:47:12.028 luup.variable_set:: 65.urn:micasaverde-com:serviceId:HumiditySensor1.CurrentLevel was: 30 now: 27 #hooks:0
2022-01-12 20:47:12.028 luup.variable_set:: 63.urn:upnp-micasaverde-com:serviceId:Weather1.LastUpdate was: 1642047430 now: 1642049231 #hooks:0
Any ideas on how to troubleshoot this.....
@buxton Yeah, running lua within the Reactor plugin/MSR is an incredibly powerful feature that, combined with expressions, pretty much allows you to do whatever you want to do. A wonderful piece of software.
Now I need to figure out how to construct the closure that will surround the watch callback function. Tricky, because there are so many variables that go into deciding when the routine should branch, and when branching should be avoided.
@akbooer OK thanks, that's what I needed to know.
One final question if you could. How does scope affect a watch called from start-up lua? I'm asking because I imagine the scope for a watch is plugin specific, and therefore is confined to the plugin.
The watch will be created in the initialization code of a global module, that is in turn referenced in start-up lua ie. "_G.myStartUpLua = require("myStartUpLua") "
This module contains functions that are called from Reactor activities similar to this:
Will the global watch callback function be visible to the watch if both are created within "myStartUpLua".