Indeed, time series databases (aka. historians) are somewhat different from relational ones. But at least this sets you up to appreciate other options such as InfluxDB, if necessary.
Indeed - looking forward to using InfluxDB as well! Seems like the best of both worlds and gives you a lot of query options in Grafana. I saw some references in your Historian code, if you need help testing or something else, let me know.
Hi akbooer,
Took me some time to look at this so just installed the latest development version 2018.08.23, very nice indeed. As usual.
I have two Vera’s bridged and in the openLuup Console Historian view the variables of the first Vera (range 10000) there is a nice hyperlink to show the graph. The hyperlinks are missing for the second Vera though (range 20000).
If you need some debug info let me know.
Cheers Rene
Thanks for that!
Interesting. I have 3 linked Veras and I thought everything was working OK. Let me check again.
So you’re saying that links like these are missing?
Correct,
Could it be because my first Vera has device numbers going over 10000 and thus show with device IDs on the Verabrige from 10000 - 23500? the second bridged Vera has the 20000 range. I guess I need to up that? However, there goes my DataMine data and scenes ???
Cheers Rene
Guess what.
I enabled the historian directory in the startup lua and magic. All links now show!
Cheers Rene
I knew someone would manage this one day. It just had to be you!
I would have to think hard about the effects of that, but at the very least, I think that devices in the wrong-numbered block will show the wrong node name. What duplicate device numbers do, I hate to think…
…time to tidy up your Vera device numbering.
I knew someone would manage this one day. It just had to be you!
I would have to think hard about the effects of that, but at the very least, I think that devices in the wrong-numbered block will show the wrong node name. What duplicate device numbers do, I hate to think…
…time to tidy up your Vera device numbering.[/quote]
LOL.
I wish I could sort of reset the Vera device numbering. At one point to Worldweather plugin went haywire and kept recreating its child devices. I did once change all the device numbers over 10000, but when you add a device the Vera just keeps numbering up. I guess I need to bit the bullet on the openLuup side.
For the historian view, maybe you can test with and without the on disk archiving and see if all bridged variables show an hyperlink.
Cheers Rene
[quote=“reneboer, post:86, topic:199464”]Correct,
Could it be because my first Vera has device numbers going over 10000 and thus show with device IDs on the Verabrige from 10000 - 23500? the second bridged Vera has the 20000 range. I guess I need to up that? However, there goes my DataMine data and scenes ???
Cheers Rene[/quote]
Rene,
While wasting your time with my response, I’m also laughing at myself.
My devices are up to 93, but being an obsessive/compulsive type (read anal), I’m having heart palpitations because of the missing numbers in between.
I need to calm down now.
:-[
Chris
Karma for all you do here.
There’s a system attribute called Device_Num_Next. After backing up, you could try changing this in the user_data.json file, or even on the fly with luup.attr_set().
I don’t know what would happen if you ran into an existing device, though, but I imagine that you must have some fairly large gaps in the device numbering!
Edit: tried luup.attr_set() but didn’t work.
Thanks, I’ll give it a shot. All devices could fit in two digits indeed.
Cheers Rene
Hi akbooer,
It looks simpler (and less risky) if I can change the offset in VeraBridge. Looking at the current code this gets calculated again after each restart. Could it be made the initial offset gets calculated at first install and then taken from the off-set variable? This way you can also remove a VeraBridge without impacting the numbering of any remaining. I must admit I do not understand the role of the Primary Bridge (OFFSET == BLOCKSIZE).
Cheers Rene
That’s an interesting thought, and certainly would fix that particular problem. It may raise other issues - I’ll have to look closer at that.
I must admit I do not understand the role of the Primary Bridge (OFFSET == BLOCKSIZE).
Not sure I understand this? Are you asking why the first bridge has an offset at all? Clearly, native plugins and virtual devices start numbering in openLuup using low numbers, so any bridge variables have to be offset. The only concession made to the first bridge is that the Zwave controller gets mapped to device #1 so that somw exotic plugins, which directly use the Zwave controller, work.
Not sure I understand this? Are you asking why the first bridge has an offset at all? Clearly, native plugins and virtual devices start numbering in openLuup using low numbers, so any bridge variables have to be offset. The only concession made to the first bridge is that the Zwave controller gets mapped to device #1 so that some exotic plugins, which directly use the Zwave controller, work.[/quote]
No, I get why even the first needs an offset so it won’t clash with the openLuup native devices. It is that bit of special logic I did not get the reason for. But that Zwave device is why. Learning again 
Cheers Rene
An obvious way to skip a VeraBridge block of device numbers is to install another copy of the bridge. The blocks are currently assigned from lowest to highest VeraBridge plugin id, so you could, for example, use bridges 1 and 3, simply not mapping bridge 2 to a remote Vera at all.
Hi akbooer,
I fear it is a bit more tricky than that. Looking at the historian files I see that the devices from the first bridge with numbers over 10000 show up with just the first four digits with the second bridge vera number. I.e. device ID 13523 of vera xxxx1711 show on the History DB page as xxxx0073.3523.EnergyMetering1.Watts where xxxx0073 is the vera number of the second bridge. Maybe getting the device numbers on my Vera down is indeed the best option. Unless you want me to be your guinea pig for this scenario.
Also looking at the History DB page the page shows links like 20m:30d,3h:1y,1d:10y. However, clicking them only produces empty graphs. Also for the openLuup native devices. The same parameters do show a graph on the Historian page. Any idea? Or do I need to install a graphana system or so?
Cheers Rene
Yes, I knew that something like that would happen with Historian. What would be needed here is to identify children of bridge devices by their parent. I didn’t do that initially because it is harder - you have to search up the tree for grandparents, etc. (OK, not too hard.) However, these name space/number conversions actually take place in both directions between three different naming conventions. I haven’t yet worked out whether this is actually possible to do…
Also looking at the History DB page the page shows links like 20m:30d,3h:1y,1d:10y. However, clicking them only produces empty graphs. Also for the openLuup native devices. The same parameters do show a graph on the Historian page. Any idea? Or do I need to install a graphana system or so?
That’s much more concerning. Do none of them work? Do those links show number of points updated? There should be a counter.
That’s much more concerning. Do none of them work? Do those links show number of points updated? There should be a counter.[/quote]
Go figure, today there is data showing?!? It seemed to have needed an extra luup restart or so as it is recording from the time I updated ALTUI yesterday.
Cheers Rene
Well, that’s a relief!