Can weather data be overlaid by SecuritySpy?

rdforbes

Wondering if data from a weather station, say, a WeatherFlow Tempest, can be overlaid onto the video image being processed by SecuritySpy?

Ben

The WeatherFlow Tempest does have an API, via which you can get data from the device. So, in theory, it would be possible to write a script to obtain data from the weather station, and then pass it to SecuritySpy as a text overlay, either by HTTP or AppleScript. If you check our SecuritySpy Web Server Specification document, the "Camera Settings" item shows how to set a text overlay using an HTTP POST request.

QFive

I'd love to see a couple of good weather overlays; one for an individual camera and maybe one for multiplex.

I think data could be fed from WeatherUnderground. That would allow users to select local weather or their own PWS.

For a camera maybe a four or six quadrant element that allows users to select 4 or 6 bits of data from WU and a separate wind rose element (direction & speed). Each of these could be placed and sized as desired with user selectable color and background opaqueness.

For multiplex maybe a lower 8th bar with 4 data elements? Actually I can think of a lot of things that'd be nice to feed to a lower 8th :-)

photonclock

I had the same thought a while back, but the SecSpy text overlays are pretty limited. They seem to only show about 8-10 chars, constrained to corners. The web API for enabling/disabling the overlays works (I tested it recently), but it seems like you configure it to position a multi-line text overlay, like a "lower-third" broadcast/closed caption overlay that is at bottom third/center justified.

Ben

You can fit quite a lot in SecuritySpy's text overlays: up to 255 characters, multi-line aware (using \n markers for new lines), positioned in any corner. The character limit and lack of a centre-justified option are limitations here.

photonclock

Oh, now I understand what happened. A while back I had played with the overlays, and I was experimenting with how I could center-justify text, operating under the assumption that I could figure out (maxCharsPerLine-charsUsed)/2 = number of spaces to insert at the head to center justify a string, so...I inserted a bunch of spaces before a string. Give it a try, enter, "[space][space][space][space][space][space][space]TEST 1234 5678" and the text gets cut off to the right after "TEST 1", so I concluded the overlay must be limited to just a small number of chars per line and I gave up.

Maybe that's a bug that leading spaces cause that cut-off issue?

Ben

You're right - leading/trailing whitespace is cut off. This isn't a limit in the length of the overlay, rather it's because leading/trailing whitespace is ignored in the calculation that determines the total size of the overlay. Sorry but I don't think that we'll be changing this - the current calculation is the most accurate for determining the extent of the visible text (the drawn glyphs) - if we were to switch to a different method that takes into account whitespace, it would be less accurate, and other spacing would be negatively affected.

A simple hack to achieve what you want would be to include a small non-whitespace character at the start, before the series of spaces, like a period:

.[spaces][text]

photonclock

Feature request: "Center" 😁