Space Probe Update?

1

Hi all,

I’ve noticed a few times recently that the only updates on the MHV twitter from the space probe have been that the space is closed (Opened x days ago), so while people are remembering to turn it to zero upon leaving, when the space opens up either they’re not resetting it, or it’s not resetting properly.

I’m not the sort to show up to a space like this and start ripping out all of your tried and true infrastructure, nor would I be willing to modify what’s already there, however I do intend to build a drop-in replacement that, if everyone’s happy with, may someday be able to replace or supplement the current implementation.

I thought I’d look through the forum first, and post this as something of a “Notice of intent” and RFC before I get too bogged down in it, to hear your opinions and also to see if anyone’s got the details of the current probe (The last I can find is from 2015).
I’d be more than happy to do the whole thing from scratch, but I’d like to do it from an educated perspective nonetheless.

I also understand that I am a rather new member to MHV, and may be overstepping my bounds somewhat. If so I’d be more than receptive to someone tapping my shoulder/sending me a private message (Or just publicly ridiculing me, whatever floats your boat) and telling me to get in line.

As for the probe itself, I think (in addition to what’s already there) something as simple as a movement sensor in the main entrance, and sensors in the workshop/clean room that check if any lights are on or not, would be sufficient at resolving the current issues.
If all three are dark and without movement for a few hours, announce the space as closed. If movement is detected in the main lobby when the space is marked as closed, have an audio cue request that if the visitor intends on staying for any significant length of time, to specify so with the space probe, otherwise (If someone’s just grabbing something and leaving) to dismiss the probe.
Additionally, an audible announcement when the last specified time is about to run out, to ask if any key holder plans on staying much longer, and if so to enter this into the space probe so an update can be issued. If no update is made, and movement isn’t being detected, issue an automatic “Space closed” notification regardless of anyone actually remembering to turn it off.

This last one might be a bit cheeky, but if there’s movement in the space, lights on, and the person inside hasn’t manually dismissed the space probe, issue a tweet something along the lines of “I think there’s someone in the space but they haven’t marked it as open. Check the calendar/forum for announcements”

(A twitter-based security system is probably the least professional thing I’ve ever in all seriousness suggested implementing personally, however it wouldn’t be the strangest thing I’ve ever seen others implement)

2

These are all good ideas.

I don’t think anyone is going to tell you off for maintaining / improving things, as long as long as project doesn’t stall and just get abandoned or left for someone else to clean up. If you have the motivation and energy then by all means.

The space probe is about as old as mhv and part of the culture. It has been revised a couple time, but functionally and aesthetically remained pretty much the same. I’m not saying don’t play with it, just don’t make it go away, or change it beyond recognition.

The controller for the outside light up signs are a proxy indicator of when the space is open. When the door is opened the lights turn on, and remain on while the door is opened, or for an hour after the last door activity. It has always been in the back of my mind this should feed to the space probe / space opening messages some how.

I also thought about having the space probe play the radio while it was on, hopefully helping people remember to turn it off as they leave.

3

I have looked at the space probe as is, and confirmed that it isn’t really an issue of people forgetting to turn it on/off, but that the probe itself isn’t sending updates for some reason.
Apparently this behaviour has been intermittent for some time, since the probe was updated to perform over-the-air software updates from GitHub or an equivalent.
If this is the case, then hopefully a simple rollback would resolve all issues.
I won’t investigate the probe further for the time being, as hopefully whoever has previously maintained it will be able to resolve the bug.

4

I think we should change the pot out for a rotary encoder
This way we may have less false triggers.
And with a change in the code, which wont be too hard to do