If you go to the AltAppStore, you can choose the “stable” branch to install. See how that goes first.
Edit: correct from mobile
OK, installed the stable version (1.7 per the UI) and there are no error messages per the install, however, I’m still seeing the same error in the startup log. There’s also no change in behavior, however, I’m now seeing status updates in the openLuup log; these updates were not in the log while using version 1.6. Here’s a sample of the current log status:
2018-06-09 20:07:58.102 openLuup.http:: GET /luvd/D_SiteSensor1.xml HTTP/1.1 tcp{client}: 0x3dd553c8
2018-06-09 20:07:58.102 openLuup.http:: request completed (1671 bytes, 1 chunks, 0 ms) tcp{client}: 0x3dd553c8
I’m pretty sure the startup error message refers to this plugin as the time signatures are identical and the previous plugin loads and operates correctly. BTW, out of ten plugins loaded, this is the only one giving me trouble… Will see if AK can provide some debugging direction for “openLuup.chdev”.
It’s actually the loader module which needs DEBUG set to true. If it’s a new enough version it should create a file, DUMP_…, of the problem device. The latest testing branch should actually report those two startup log lines in correct order (swapped in earlier versions.) The error message itself comes from the Lua interpreter, so I can’t improve on that.
Let me know if you need more.
@buxton, I do most of my development under openLuup, and it’s working fine in my current environment, but I haven’t upgraded to AK’s latest and greatest. I’ve got other stuff on my agenda today but I’ll try to get time to upgrade my install and look at it. Are you able to run that status query now that you’re on 1.7?
@Buxton: version 1.7 works fine for me on the current testing branch of openLuup. I don’t get any startup errors, and following the recipe on my web site for the civil twilight configuration works as described.
OK. I’ll have to look closer at what’s going on here then as it looks like the problem must be on my end (and it usually is :D). The function that’s conveying the error is “local function assemble_device_from_files (devNo, device_type, upnp_file, upnp_impl, json_file)” in the loader.lua module.
AK makes some observations about device files at the head of the function…
I’m not sure how to set a breakpoint in ZBS for a variable watch (upnp_impl == I_SiteSensor1.xml) as that’s the only way I can imagine tracking this down.
As an aside, I typically see this interpreter error when I spaceout and use “=” instead of “==”, a habit from using other languages 
I just updated openLuup to the most recent testing version and now sitesensor works! Truly sorry for the trouble. I dislike wasting folk’s time on such things.
I did do an update prior to trying to track down this error, but apparently something must have corrupted as the testing version of openLuup has the same id# as before. Odd though that this was the only plugin effected. Anyway, all is good. Your code is beyond awesome BTW.
@buxton, that’s good news! Just a reminder, double-check your plugin config for the civil twilight and make sure you have a long request interval (the post recommends 28800), and use the “Re-evaluate” flag set to “Every minute.” This is an important point to not spam the server with queries for results that only change daily. Must be good netizens!
Yep, all is good. I would correct your blogpost though as the request interval is mistaken for request time out… I can see how someone would swap the values causing real havoc.
Hi all, I have been using SiteSensor for a few months and love it. I have been reading the JSON data for my homes battery however after an update from the manufacturer the location of the JSON file went from http to https with a self-signed certificate. SiteSensor then stopped working. I now have the following error below. I used python to make the same request and get a ‘<urlopen error [SSL: CERTIFICATE_VERIFY_FAILED] certificate verify failed: self signed certificate (_ssl.c:1045)>’.
This makes me think the Vera is not trusting the batteries site. How do I make the Vera trust it again?
Thanks all
Brain
08:34:06: SiteSensor: Requesting JSON data
08:34:06: SiteSensor: “GET” “https://192.168.0.15/api/system_status/soe”, headers={ }
08:34:06: SiteSensor: Response HTTP status nil, body=
08:34:06: SiteSensor: Eval #1: “response.percentage”=(“table”){ __type=“null” }
08:34:06: SiteSensor: Failed to execute `“”', { message=“Missing expected operand”, __source=“luaxp”, type=“evaluation” }
08:34:06: SiteSensor: Eval trip expression: “”=(“nil”)nil
08:34:06: SiteSensor: Next activity in 40 seconds
[quote=“ellisb, post:90, topic:197026”]Hi all, I have been using SiteSensor for a few months and love it. I have been reading the JSON data for my homes battery however after an update from the manufacturer the location of the JSON file went from http to https with a self-signed certificate. SiteSensor then stopped working. I now have the following error below. I used python to make the same request and get a ‘<urlopen error [SSL: CERTIFICATE_VERIFY_FAILED] certificate verify failed: self signed certificate (_ssl.c:1045)>’.
This makes me think the Vera is not trusting the batteries site. How do I make the Vera trust it again?[/quote]
They appear to be using an unsigned certificate on their interface. Not bad, not great, but also should not be a problem. The default configuration for the ssl.https module is to not verify the peer certificate, so you should not be getting this error. Sit tight a bit. I’m going to poke around in my test environment.
[quote=“rigpapa, post:91, topic:197026”][quote=“ellisb, post:90, topic:197026”]Hi all, I have been using SiteSensor for a few months and love it. I have been reading the JSON data for my homes battery however after an update from the manufacturer the location of the JSON file went from http to https with a self-signed certificate. SiteSensor then stopped working. I now have the following error below. I used python to make the same request and get a ‘<urlopen error [SSL: CERTIFICATE_VERIFY_FAILED] certificate verify failed: self signed certificate (_ssl.c:1045)>’.
This makes me think the Vera is not trusting the batteries site. How do I make the Vera trust it again?[/quote]
They appear to be using an unsigned certificate on their interface. Not bad, not great, but also should not be a problem. The default configuration for the ssl.https module is to not verify the peer certificate, so you should not be getting this error. Sit tight a bit. I’m going to poke around in my test environment.[/quote]
OK. On three different Veras of mine, all three running different firmware, the verified default option is don’t check the peer certificate (seen in /usr/lib/lua/ssl/https.lua), and that’s confirmed by testing on each against several sites. I can’t reproduce the error you’re getting. But, clearly there is something different going on for you, so I’d like to have you install the attached version of L_SiteSensor1.lua that explicitly sets the SSL options (doesn’t rely on defaults), and see if we can get the behavior to change.
Download this file, and then upload it to your Vera with the “Reload Luup after upload” box checked. Once the upload/reload finishes, go into the SiteSensor’s control panel, make sure log capture is on, and toggle the “armed” state of your SiteSensor to force it to do a request, and let me know what it says.
[quote=“rigpapa, post:92, topic:197026”][quote=“rigpapa, post:91, topic:197026”][quote=“ellisb, post:90, topic:197026”]Hi all, I have been using SiteSensor for a few months and love it. I have been reading the JSON data for my homes battery however after an update from the manufacturer the location of the JSON file went from http to https with a self-signed certificate. SiteSensor then stopped working. I now have the following error below. I used python to make the same request and get a ‘<urlopen error [SSL: CERTIFICATE_VERIFY_FAILED] certificate verify failed: self signed certificate (_ssl.c:1045)>’.
This makes me think the Vera is not trusting the batteries site. How do I make the Vera trust it again?[/quote]
They appear to be using an unsigned certificate on their interface. Not bad, not great, but also should not be a problem. The default configuration for the ssl.https module is to not verify the peer certificate, so you should not be getting this error. Sit tight a bit. I’m going to poke around in my test environment.[/quote]
OK. On three different Veras of mine, all three running different firmware, the verified default option is don’t check the peer certificate (seen in /usr/lib/lua/ssl/https.lua), and that’s confirmed by testing on each against several sites. I can’t reproduce the error you’re getting. But, clearly there is something different going on for you, so I’d like to have you install the attached version of L_SiteSensor1.lua that explicitly sets the SSL options (doesn’t rely on defaults), and see if we can get the behavior to change.
Download this file, and then upload it to your Vera with the “Reload Luup after upload” box checked. Once the upload/reload finishes, go into the SiteSensor’s control panel, make sure log capture is on, and toggle the “armed” state of your SiteSensor to force it to do a request, and let me know what it says.[/quote]
@ellisb, any luck?
[quote=“tunnus, post:42, topic:197026”]Was wondering if this plugin could be used to get electricity price data from a site (https://www.nordpoolgroup.com/Market-data1/Dayahead/Area-Prices/FI/Hourly/?dd=FI&view=table) and then use the data in PLEG?
Another option would be to use lua code, but not sure how it would be done. A draft below
[code]
local https = require(“ssl.https”)
local ltn12 = require(“ltn12”)
– 5 Second timeout
https.TIMEOUT = 5
local response_body = {}
local request_body = ‘’
local r, c, h = https.request{
url = ‘https://https://www.nordpoolgroup.com/Market-data1/Dayahead/Area-Prices/FI/Hourly/?dd=FI&view=table’,
method = “GET”,
headers = {
[“Content-Length”] = string.len(request_body),
[“Content-Type”] = “application/x-www-form-urlencoded”
},
source = ltn12.source.string(request_body),
sink = ltn12.sink.table(response_body)
}
[/code][/quote]
Hi tunnus
I am after excatly the same … get the hourly electricity prices and then use those in order to benefit the low price hours. Did you manage to get the you system working . This xml parsing is too mutch for my programing skills
rigpapa: One suggestion, Would it be possible for you to make the number of parsed data a user option? I am thinking about using SiteSensor as a bridge plugin to connect to hubitat through its RestAPI on openLuup and would like a single call to parse a much greater number of responses than 8.
Of course, that number is rather arbitrary and there’s little reason not to do more. I’ve got a number of irons in the fire at the moment, but I’ll see what I can do.
I have a web-enabled device which reports water temperature on its web page.
I need to grub that value and assign to virtual sensor.
Developers provided API to get that temperature in JSON file, so I need your app to get that file by using CURL, then parse it and give me the value.
cmd command looks like this:
curl -d “api_key=b05bad1826f1a1910935b777918eec702be395d5&command=get_water_temperature” -X POST http://192.168.1.104/Api
as an output I get this:
{“type”:“success”,“msg”:“36.59”}
So I need that value 36.59 as a variable for my sensor.
Developers also provided Python script, which works fine as well (outside of my Vera):
#!/opt/local/bin/python2.7
import requests
import json
url = ‘http://192.168.1.104/api’
api_key = “b05bad1826f1a1910935b777918eec702be395d5”
payload = {
‘api_key’: api_key,
‘command’: ‘get_water_temperature’
}
POST with form-encoded data
r = requests.post(url, data=payload)
Response, status etc
r.text
r.status_code
try:
data = json.loads(r.text)
print data[‘msg’]
except:
print “Error parsing data”
Could you please help me to get needed variable?
Thank you very much!!!
[quote=“questusa, post:97, topic:197026”]I have a web-enabled device which reports water temperature on its web page.
I need to grub that value and assign to virtual sensor.
Developers provided API to get that temperature in JSON file, so I need your app to get that file by using CURL, then parse it and give me the value.
cmd command looks like this:
curl -d “api_key=b05bad1826f1a1910935b777918eec702be395d5&command=get_water_temperature” -X POST http://192.168.1.104/Api
as an output I get this:
{“type”:“success”,“msg”:“36.59”}
So I need that value 36.59 as a variable for my sensor.
Could you please help me to get needed variable?
Thank you very much!!![/quote]
Unfortunately, SiteSensor does not currently do POST queries, and it’s not something I have the time at the moment to add.
The most straightforward alternate way to go would be to use your working curl command in Lua. You can use this to set a value on a virtual sensor:
local p = io.popen( 'curl -d "api_key=b05bad1826f1a1910935b777918eec702be395d5&command=get_water_temperature" -X POST http://192.168.1.104/Api' )
local responseText = p:read("*a")
p:close()
local json = require "dkjson"
local data = json.decode( responseText )
local currTemp = data.msg
luup.variable_set( "urn:upnp-org:serviceId:TemperatureSensor1", "CurrentTemperature", currTemp, virtualSensorDeviceNum )
Put in the device number of your virtual sensor in the variable_set call (last argument). You can run that code periodically, either as scene Lua (in a scene, put the code in just as shown) that you trigger on a schedule, or in startup Lua by launching/creating a repeating timer/delay process:
-- Put this in startup Lua
function updateWaterTemp()
-- Put all the code from above here...
-- then add the following:
luup.call_delay( 'updateWaterTemp', 60 ) -- 60 second repetition
end
updateWaterTemp() -- Call the function to get the ball rolling.
Warning: This is all pseudo-ish code, untested. The spirit is there. Unfortunately, I’m not able at the moment to set up a test jig and make sure it all works exactly as shown, but this should be close enough to let you take it the last mile.
Thanks!!! AWESOME!!! It works!!!
This is the working code:
local p = io.popen( “curl -d ‘api_key=b05bcd1826f1a1810935b677918eec702be395d5&command=get_water_temperature’ -X POST http://192.168.1.28/Api” )
local responseText = p:read(“*a”)
p:close()
local json = require “dkjson”
local data = json.decode(responseText)
local currTemp = data.msg
local Ftemp = currTemp * 9 / 5 + 32
luup.variable_set( “urn:upnp-org:serviceId:TemperatureSensor1”, “CurrentTemperature” ,Ftemp, 324)
return true
Hi Rigpapa,
I sent you a note on a Paypal contribution, but I’m not sure if you got to see that note, so I’ll repeat it here. In addition to more than 8 variables as some others have requested, I’d like to be able to call a SiteSensor refresh from luup. I tried issuing commands to disable and then re-enable the SiteSensor, but that didn’t cause an update to happen. When I disable/enable in the GUI it immediately updates, but not when I toggle that from code in a scene. I last tried this a few weeks ago, so if you’ve changed the behavior in a recent update let me know so I can try it again.
The reason this would be useful for me is that I use SiteSensor to get the status of my thermostat from the Lennox iComfort site every 2 minutes. (This thermostat can’t be queried locally… only via their web site’s API) I’ve had some cases where a command to change a thermostat setting fails to apply even though the curl command comes back with a successful response. As a result I always immediately pull the current status after issuing any command to verify the command was received. This requires me to have all the code to query the site and parse the JSON response inside each related scene. I have scenes to set the Away mode, cancel the Away mode, turn the temp down at night, turn the temp up in the morning, turn the temp down a degree, turn it up a degree, etc., so I have this code repeated a bunch of times.
It would be much cleaner if I could just ask Site Sensor to refresh and then look at the variable that Site Sensor has updated to verify the command worked. Also the way I’m doing it now there is no relationship between my update and the time of the next refresh by Site Sensor. If I could force the plugin to refresh I’m assuming that would reset the interval so that SiteSensor wouldn’t query the API again until the interval had passed which would reduce the number of calls to the API.
Thanks again for all the great plugins.