@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!

@archers

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.

toggledbits/sockproxyd

A socket proxy for Vera/openLuup systems. Contribute to toggledbits/sockproxyd development by creating an account on GitHub.

toggledbits/LuWS

A WebSocket client implementation for Luup (Vera and openLuup) systems, with optional async receive (responsive) - toggledbits/LuWS

@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

@catmanv2 Yes, UTC does work well in England....

Timestamps do not match the UI time or the system time:

[latest-21286]2021-10-16T03:10:43.922Z <Engine:INFO> Engine#1 master timer tick, local time "10/15/2021, 8:10:43 PM" (TZ offset -420 mins from UTC)

I tried adding TZ to the docker container with "docker exec reactor apk add tzdata" but there was no change in log timestamps. I have the TZ in the compose file as:

  environment:
   REACTOR_DATA_PREFIX: /var/reactor
   TZ: America/Los_Angeles

This does set the UI time correctly. The Reactor config is also set correctly:

  location:
    city: "Los Angeles"

I'd like to invoke in Reactor a Home Assistant service through the HA API. I use the following code in a vera plugin I wrote to send an HTTP request to Home Assistant to trigger an announcement on Alexa--using a Home Assistant Alexa integration that you can install through HACS.

myEchoDevice = "alexa_media_".. myEchoDevice
myEchoMessage = table.concat(myEchoMessage)
	
local request_body = json.encode {message = myEchoMessage, data = {["type"] = "announce",method = "all"}}

local response_body = {}
	
local theURL = 'http://'..HomeAssistantIP..':'..HomeAssistantPort..'/api/services/notify/'..myEchoDevice  
	
r, c, h = http.request {
   url = theURL,
   method = "POST",
   headers = {
   ["Content-Type"]   = "application/json",
   ["Authorization"] = "Bearer ".. HomeAssistantToken,
   ["Content-Length"] = request_body:len()
   },
source = ltn12.source.string(request_body),
sink   = ltn12.sink.table(response_body)
}

I don't see the "notify" service in the HA attributes revealed by reactor. Is there a way to access the Home Assistant API through reactor, or do I need to use HTTP requests to initiate services.

@toggledbits said in How to? Rule for Vera "Can't Detect Device" errors and reset:

The attributes is strictly tied to its existence on the Vera device

Yes, I was asking more in general terms about what happens when a plugin gets initialized. And whether CommFailure is a specific attribute of Vera's HaDevice1 type.

@wmarcolin Yes, thanks. I have the data point "x_vera_device.failed" covered with the following expression:

join( 
  each id in matchEntities( { controller: 'vera', capability: 'x_vera_device' } ): do
    e=getEntity( id ), 
    e.attributes.x_vera_device.failed ? e.name  :  null
  done, ", " )

I was using CommFailure to detect devices that have not been configured properly, and sure enough, I found three on my network.

@toggledbits Is it the case that CommFailure is only an attribute of the HaDevice1 type. Per the below, I pre-filtered on "x_vera_svc_micasaverde_com_HaDevice1". I had some interesting results from the expression, though I'm still trying to get my head around expression syntax, so the below may be wrong:

join( 
  each id in matchEntities( { controller: 'vera', capability: 'x_vera_svc_micasaverde_com_HaDevice1' } ): do
    e=getEntity( id ), 
    e.attributes.x_vera_svc_micasaverde_com_HaDevice1.CommFailure !=0 ? e.name : null
  done, ", " )

Three of my zwave devices did not have a CommFailure attribute and I suspect, they were incorrectly migrated to my UI7 veraplus from a ui5 veralite. A reconfigure command established the CommFailure attribute for all three.

There is one plugin on my vera (it's the only plugin on the vera) that does not have the CommFailure attribute. Does the attribute get added automatically when one installs a plugin? I'm asking in the sense that a re-install might correct the problem but I don't want to mess with anything that isn't obviously broken.

@rafale77 does a deep dive into failed vera zwave devices in this thread: https://smarthome.community/topic/392/vera-device-extended-attributes

@wmarcolin Here's a do loop that uses the device.failed attribute:

join( 
  each id in matchEntities( { controller: 'vera', capability: 'x_vera_device' } ): do
    e=getEntity( id ), 
    e.attributes.x_vera_device.failed ? e.name :  null
  done, ", " )

I have one device offline that shows up in the array and the device is offline as I physically removed it a couple of days ago. As well, I'm seeing one plugin that has this attribute set to true, although it is working. Perhaps something in the plugin code needs to reset the device from true to false if the plugin regains communication....

Edit: the plugin that was showing failure used "luup.set_failure false" instead of 0 or 1. This is probably an openLuup bug as using false in this case is a holdover from UI5. I changed false to 0, and the plugin no longer shows as failed. http://wiki.micasaverde.com/index.php/Luup_Lua_extensions#function:_set_failure

@wmarcolin I'll get a device offline notice approximately 24 hours after a device is disconnected. Perhaps vera is using a combination of the two metrics to trigger an offline email ie once 24 hours passes without a poll response, the CommFailure for the device goes true and an Email is sent.

@toggledbits One of the last things keeping me from localizing my vera is that the cloud will notify me when a zwave device goes offline. It's important for me to know as some of my devices are connected to security functions.

Do you know if the offline notice is tied to "x_vera_svc_micasaverde_com_ZWaveNetwork1.ConsecutivePollFails" and if so, the count/number of fails that vera uses to send a device offline notice? My distant zwave devices tend to rack up a lot of fails, but I never get an offline notice sent to me.

I'd much rather prefer to handle that error condition locally, and if it can be done, I can then run your Vera Decouple script.