I’m trying to offload as much as I can from my Vera and I have moved my DataYours cache, graph, and dash over to openLuup. At the moment I left Watch running on my Vera, but I am wondering if it makes sense to move that to openLuup as well and then watch from there there via the verabridge. My concern is that the overhead of watching remotely would negate the benefit of not having Watch running directly on the Vera. Any opinions / experiences?
This is a really good question, and something I’ve given a fair amount of thought to myself.
For my own systems, I’ve kept DataWatcher on the Veras, since the overhead of sending to a remote cache is absolutely minimal. What you can do to reduce the memory impact on Vera even more, though, is to not run DataYours at all, and just run the DataWatcher daemon from Lua startup. In this configuration, no plugin device is visible, or even created, and the code runs in the startup/scene context so you save several Mbytes of plugin memory allocation.
This makes even more sense now that DataWatcher registers itself as an AltUI data storage provider, so you can, in fact, abandon the DataYours dashboard interface and use the inbuilt AltUI ones to define which variables to watch and to plot them.
There is zero additional overhead on Vera if you chose to watch remotely on openLuup (assuming the Vera was already bridged.). It’s just that there are rather more links in the chain which add delay and are (possibly) points of failure.
I like the idea of just running the daemon from the lua startup! Now for a probably stupid question … I know how to manually create a device and pass variables when in startup.lua, but how do I call just the daemon (without creating it as a device) and pass the config_dir and destinations variables?
These config variable can be defined in a virtual file with a call to the daemon server, prior to an init() call to DataWatcher. The variables to watch are permanently maintained in a physical file DataWatcher.conf.
I’m away from my development system just now, but can give detailed instructions tomorrow.
Many thanks! I dug through all the DataYours beta and rpi threads to see if it was already documented somewhere, but all I could find were references to doing it. I’ll muck about in the meantime in the event that I can figure it out myself.
The L_DataYours.lua file may give you some clues.
OK, here’s the instructions to run DataWatcher without having the DataYours device taking up system memory:
Make sure you change the necessary parameters (in particular, DESTINATION IP address and port) and then you can run the following code (once) in Lua Test to check things are working OK before moving it to the Lua Startup code. “relay” is used in specifying the configuration, since DataWatcher is an implementation of the Carbon Relay daemon.
-- startup for DataWatcher without creating a DataYours device, 2016.03.31 @akbooer
local d = require "L_DataDaemon"
local w = require "L_DataWatcher"
d.config_path = "conf/" -- set to location of DataWatcher.conf file (default is "/www/")
-- also of DataTranslation.conf file (for symbolic value translations)
d.set_config {
relay = {
DESTINATIONS = "0.0.0.0:5003", -- set to required DataCache IP and port
LIVE_ENERGY_USAGE = "1", -- set to "1" to log energy usage
MEMORY_STATS = "0", -- set to "1" to log system memory usage: MemAvail MemFree MemUsed
-- SYSLOG = "0.0.0.0:514", -- set to syslog IP and Port, if required
}}
w.init() -- start DataWatcher
--The code should run successfully, but with no apparent change to system devices. To check it is, in fact, running, you can make a request to its HTTP handler:
http://0.0.0.0:3480/data_request?id=lr_DataWatcher&show=configwhich should result in something similar to the following configuration listing, where you can check the alue of the setup parameters and also monitor the latest logged variables.
DataWatcher CONFIGURATION at Fri Apr 1 15:52:26 2016
DAEMON = {
VERSION = "2016.01.04",
client = "DataWatcher",
destinations = {"0.0.0.0:5003"},
errors = {count = 0},
http = {received = 1},
ip = "0.0.0.0",
start_time = "Fri Apr 1 15:51:59 2016",
udp = {
last_received = {},
last_sent = {["127.0.0.1:5003:inet"] = "Vera-88800127.20010.urn:micasaverde-com:serviceId:EnergyMetering1.EnergyUsage 0 1459522319"},
received = 0,
sent = 4
}
}
DATAWATCHER = {
VERSION = "2016.02.26",
live_energy_usage = {
["10041.urn:micasaverde-com:serviceId:EnergyMetering1.EnergyUsage"] = {"RGBW Master",0},
["20010.urn:micasaverde-com:serviceId:EnergyMetering1.EnergyUsage"] = {"Shed Humidity",0},
["20015.urn:micasaverde-com:serviceId:EnergyMetering1.EnergyUsage"] = {"Studio Table Lamp",0},
["20021.urn:micasaverde-com:serviceId:EnergyMetering1.EnergyUsage"] = {"Greenhouse Temp Humidity",0}
},
memory_stats = {},
relay_tally = {},
translations = {},
watch_tally = {}
}
[relay] = {
DESTINATIONS = "0.0.0.0:5003",
LIVE_ENERGY_USAGE = "1",
MEMORY_STATS = "0"
}Device variables may be watched, or un-watched, using the same request handler, using the syntax “devNo.serviceId.variable” to specify the item to watch. You may also use wildcard “*” device numbers, so that, for example to watch all the temperature variables you could make the request:
http://0.0.0.0:3480/data_request?id=lr_DataWatcher&watch=*.urn:upnp-org:serviceId:TemperatureSensor1.CurrentTemperatureand to ignore the temperature from device #42 you could then request:
http://0.0.0.0:3480/data_request?id=lr_DataWatcher&unwatch=042.urn:upnp-org:serviceId:TemperatureSensor1.CurrentTemperatureYou can check these settings in the DataWatcher.conf file which is located in the specific configuration path, here “conf/” which is relative to “/etc/cmh-ludl/”
I think this is enough to make you dangerous! Please let me know how it goes.
Many thanks … This works brilliantly!
I am able to simplify the watch/unwatch a bit by leveraging the dashboard still, as I have the config files stored to a NAS share with both my Vera/Watcher and openLuup/AltUI/DataYours pointed to the same location.
Great.
Yes, the remote dashboard will work too, but that is the underlying mechanism it uses itself.