DataYours on Raspberry Pi

Yes, no need at all to have any component of DataYours running if you don’t need it. You could even, for example, configure DataWatcher on the Vera entirely remotely with HTTP calls from either a browser, or Luup code on the RPi, and also plot graphs locally without using DataDash at all.

Having had a day out to think a bit about this, I now see where you were coming from with using VeraBridge: it is indeed perfectly possible to bridge to the remote Vera and simply use DataYours to record the bridged variables locally on the RPi. I read with interest your comprehensive test of various configurations and concur with the findings, all of these are valid, if sometimes bizarre, combinations. The fact remains, however, that VeraBridge will place a much higher demand in terms of cpu and I/O on the system than simply using DataWatcher, and if you were just using this to access the data (rather than remotely control Vera) then it would be a bit of overkill.

So really it just depends on what you want to do - DataYours is, as you have found out, very modular and very configurable. VeraBridge adds another set of options. You should perhaps note that whilst DataYours has logged many millions of variable changes and has been very extensively tested for well over a year, openLuup and VeraBridge are new and definitely Beta releases.

@d55m14

Does this update fix your problem with UDP_RECEIVER_PORT not being set?

[quote=“akbooer, post:62, topic:186265”]@d55m14

Does this update fix your problem with UDP_RECEIVER_PORT not being set?[/quote]

tnks akbooer,

I’ve multiple VeraEdge/DYonRpi installed on different site and a DYonRpi in a central site. I’d like to have different port number between local copy of Wispher database and the central copy .

tnks again

donato

Does that mean you’re running two DataCache daemons on the same IP but with different port numbers?

No. One Datacache on Rpi is local to Veraedge and the other is remote (public IP) always on Rpi.

OK, fair enough. I don’t see that you need to change the UDP port at all, then, but it’s your call.

Did that fix work, by the way?

[quote=“akbooer, post:66, topic:186265”]OK, fair enough. I don’t see that you need to change the UDP port at all, then, but it’s your call.

Did that fix work, by the way?[/quote]

Yes the fix works. great !! tnks

Hi akbooer,

I’ve active a configuration with a central Rpi (IP address public) with Openluup e Datayours. The active daemons of DY on Rpi are cache, graph and dash. The cache daemon receives data from multiple remote VeraEdge with Datayours (Watcher) installed.

On the central Rpi I’ve active a web server too to access the graph of watched variables.

My question : is it possible from a web page (html) on the Rpi to access the realtime value of a watched variable as it is captured from the cache daemon ?

Excuse me if not clear .

tnks

donato

It is possible to write simple piece of Luup/Lua code which would serve up values or graphs for web pages which are refreshed automatically. I have an intranet server at home which does this. Examples attached.

Hi akbooer,

have you some simple piece of Luup/Lua code I can re-use. Only if you have already . I don’t want to waste your time.

tnks

donato

The luup.register_handler call can service HTTP requests and deliver any information you want to a web page: a whole page or just a data update responding to an AJAX call.

For a simple solution you could simply have a page which refreshed itself every five minutes, or whatever.

[quote=“akbooer, post:71, topic:186265”]The luup.register_handler call can service HTTP requests and deliver any information you want to a web page: a whole page or just a data update responding to an AJAX call.

For a simple solution you could simply have a page which refreshed itself every five minutes, or whatever.[/quote]

Hi akbooer,

excuse for my ignorance but can I use the luup.register_handler also in my case where the Rpi with Datayours (Cache Graph Dash) and Openluup is remote to Veraedge ? From Rpi I can access Veraedge only via Mios Server.

Can you give me a bit more information ?

tnks

donato

You original question was this:

I've active a configuration with a central Rpi (IP address public) with Openluup e Datayours. The active daemons of DY on Rpi are cache, graph and dash. The cache daemon receives data from multiple remote VeraEdge with Datayours (Watcher) installed.

On the central Rpi I’ve active a web server too to access the graph of watched variables.

My question : is it possible from a web page (html) on the Rpi to access the realtime value of a watched variable as it is captured from the cache daemon ?

From reading that, I understand that all data ends up on the RPi, ergo the RPi has access to all data changes from the remote machines without resorting to the MiOS servers. A luup.register_handler callback on the RPi can serve the latest information in response to an HTTP request. It’s what DataDash, running on the RPi, already does.

I don’t see the problem?

Hi akbooer

is there a HTTP call, with specific parameters, I can do to DataDash to obtain the most recent value of a watched variable ?

tnks

donato

It’s DataGraph, actually:

[quote=“User Guide, p.19”]DataGraph is the Graphite Web App look-alike, see:
http://graphite.readthedocs.org/en/latest/render_api.html
It reads data from the Whisper database and plots or prints it out in a variety of formats.

[tt]http://:3480/data_request?id=lr_render2&target=Vera-12345678.321.urn:upnp- org:serviceId:TemperatureSensor1.CurrentTemperature[/tt]

This is currently only a partial implementation, so following along with the Graphite render API documentation link, the exceptions are here below:
…[/quote]

I’d recommend JSON format and a time window longer than the update period of your measurements. You’ll get back multiple values (depending on the archive structure), but just pick the newest.

With a request like

http://172.16.42.151:3480/data_request?id=lr_render&target=Vera-35104571.208.urn:micasaverde-com:serviceId:EnergyMetering1.KWH&from=-1h&format=json

I get back this

[{ "target": "Vera-35104571.208.urn:micasaverde-com:serviceId:EnergyMetering1.KWH" , "datapoints": [ [4416.164, 1440690000], [4416.326, 1440691200], [4416.498, 1440692400] ] }]

It’s the last line of data you need.

Thank you very much for your support…

donato

Hi akooer,

I’m trying to use the JSON output of Graph to get the most recent value of a variable but I’m getting a cross domain origin error . The web page e DY are on the same Rpi.

The message is :

http://192.168.55.104:3480/data_request?id=lr_render&target=Vera-45103954.0?rn:micasaverde-com:serviceId:EnergyMetering1.Watts&from=-10min&format=json. No ‘Access-Control-Allow-Origin’ header is present on the requested resource. Origin ‘http://192.168.55.104’ is therefore not allowed access.

Do you know how to enable cross domain origin on the web server that respond to port 3480 ? On the Rpi is installed Apache. Is there another web server for DY ?

tnks

donato

We seem to have drifted far away from the original topic of this thread and, at the same time, away from any expertise I might have - I really know very little about Web programming. ( I am, by the way still grateful to you for having asked whether DataYours could run on a RPi in the first place and set me off on the path to what has become openLuup.)

Anyway, observing simply that ‘it works for me’, won’t help, and maybe we’re not doing the same thing. My previously posted pages were from a locally served webpage with embedded HTTP calls to the remote machine port 3480. I am assuming that the URL you gave actually does work when posted into your browser. There are, perhaps, a number of things to try:

[ul][li]serve the web page locally, as in my example[/li]
[li]use the port 3480 to serve the whole web page (so that DataYours references are to the same port)[/li]
[li]loosen up on your security settings (?)[/li]
[li]add an ‘Access-Control-Allow-Origin’ header to the DataGraph pages[/li]
[li]ask someone who really knows their stuff about the web[/li][/ul]

Don’t know if this helps. (BTW, I’m intrigued by the system you are building - what/who is it actually for?)

Hi akbooer,

tnks for your suggestions and I’ll try to remain inside the original topic.

I’m trying to setup a configuration as simple as possible to monitor some photovoltaic installation on different geographic sites.

The solution should collect data in a central site and should be indipendent of hw present (panels, inverter, etc) . At single remote installation there is a zwave controller (VeraEdge) with power meter (Aeon HEM G2). The zwave Controller with your fantastic DataYours-Watcher captures data and archive them locally and send them to the central system (a Rpi with DY Cache, Graph, Dash) too.

On the Central System (Rpi) I have the data of all PV installations and I’d like to activate a web page that a user can access to display the real time production power and some graphs of his PV system.

About your suggestions :

  1. the page is served locally on the Rpi where is DY;
  2. I’ve tried to activate the 3480 port on Apache web server but I get an error msg saying that the port 3480 is already active and used.
    3)my security settings are the default settings of a rpi installation plus your sw (DY and Openluup);
    4)can you tell me how to add the Access-Control-Allow-Origin to the Graph pages ? I haven’t found where to define it.

For any more info or explanation I’m at your disposal.

tnks

donato

I meant locally to the browser - maybe this is the same thing for you.

2) I've tried to activate the 3480 port on Apache web server but I get an error msg saying that the port 3480 is already active and used.
No, you won't be able to do that - openLuup has taken it already. Simply use the openLuup server itself - its file system root is [tt]/etc/cmh-ludl[/tt]
3)my security settings are the default settings of a rpi installation plus your sw (DY and Openluup);
I never fiddle with this - way beyond my expertise!
4)can you tell me how to add the Access-Control-Allow-Origin to the Graph pages ? I haven't found where to define it.
Let me read up more about this - I know where I define the reply headers, anyway - but I think using the 3480 server itself will fix the problem.