Excessive script time relaunch
ard jonker
ard.jonker at xs4all.nl
Sat Apr 25 09:52:15 EDT 2020
On 24 Apr 2020, at 14:52, James Sentman <james at sentman.com> wrote:
> How active is your json server?
It is very active. I receive all temperature sensors, security spy communicates about a handful of cameras, my heating valves run over the json interface. Roughly one message a second, since my last report, there were already 55K messages passed to and from this interface.
> What functions are you using with it?
Outgoing to the rpi's I switch a relay with curl like curl "http://192.168.0.245/index.php?Relay=15;value=off"
Incoming, two rpi's, valveberry and tankberry deliver their data through this bit of code (snippet) in a php script that loops over the DS sensors found.
The php script is triggered by a cron job, firing once every minute or two minutes:
$request="?formAddresss=DS$entry&temperatureReading=$temp";
$url="http://xtension.local:21111/thispartissecret/TANKBERRY/$request";
$ch = curl_init($url);
curl_setopt($ch, CURLOPT_CUSTOMREQUEST, "POST");
curl_setopt($ch, CURLOPT_RETURNTRANSFER, true);
$result = curl_exec($ch);
curl_close($ch);
which is handled by this applescript in the tankberry and valveberry ON script:
on JSONRequest(formData, JSONData)
set WorkingUnit to formAddresss of formData
set workingTemperature to temperatureReading of formData
set myList to all of group "Onewires DS"
if "DS" is equal to ((characters 1 thru 2 of WorkingUnit) as string) then
set value of WorkingUnit to workingTemperature
else
write log "there is no ds"
end if
send reply "OK" return code 200
return
end JSONRequest --
> In my case I mostly have it receive pings from other systems to keep units on in XTension to let me know if they drop off line but it receives a few other values from various devices around the house and out in the world. Are you mostly having things control units via the built in stuff.
The cameras fire fifteen, twenty times a day. The DS temp sensors just continue to deliver their values 24/7
> Are you using it with a geofencing program?
Not that I'm aware of. Well, the cameras are sort of geofencing 8-)
> I use it for that as well but that only gets a few hits a day as we come and go, and few now days as we don’t come and go nearly as often. Are you using the feature that lets you pass json data to the ON script of a unit in XTension for processing something more complicated in a script?
See the script above. I'm not sure if this indeed is "the feature... more complicated ...".
> And are you using the feature that lets you send data back down that pipe from the script? I don’t use that on a regular basis so it’s possible that is where the issue is.
Also not sure. The jsonrequest above is the only script in that unit.
> I’d love to know if just disabling and re-enabling the json interface solves the problem when it happens again or if the two things are unrelated.
I'll try that on the next occasion. But they are few and come far apart.
> It’s unlikely as that is a really ludicrous amount of memory, I do think this is most likely the problem.
I entered this line in the jsonrequest handler of the ON script of the valve berry. Obviously, as there is no sensor on the valve berry, I do not expect data coming in.
write log "processing valve
berry formData <" & formData & "> json
data <" & JSONData & ">"
After a minute however, this is in the log file
25/04/2020 15:16:45 Script Error from "valveberry (ON Script)" message: -1700: Can’t make {|host|:"xtension.local:21111", Accept:"*/*", ||:"", |url|:"/thispartisalsosecret/VALVEBERRY/", formAddresss:"DS10-00080200d10b", temperatureReading:"24.687"} into type Unicode text.
followed by numerous lines of this content:
25/04/2020 15:20:00 json: JSON timeout, connection from: 192.168.0.216 has not closed.
25/04/2020 15:20:00 json: unit with address: VALVEBERRY did not reply before timeout.
It looks like the valveberry sends sensor data and this is not processed. Weirdly, turning off and back on the json interface doesn't stop these messages. Eventually, I turned off the cron job and they stop.
> If I can’t figure out how to duplicate it here I can send a build with some functions to track it’s own allocations and various buffers and caches and make sure they are getting released as expected, or at least to report to the XTension log one way or the other so I can see from that. But it’s much easier to catch something if I have some idea which part of the program is actually causing it.
I guess we have to wait for the next occurrence unless you see causes in the above scripts?
Thanks,
Ard
ard
More information about the XTensionList
mailing list