Hey all,
The Omni Door card-swipe system seems to be working at the moment. However,
be aware there might be an issue that resurfaces.
I came upon the front door system and it was not working. This was strange
because Marc was granting access to a gaggle of folks maybe an hour before.
The laptop was off, the switch was off, and all the cords were a tangled
mess. I re-built a new little shelf for the laptop/server, power strips,
switch, etc that are in the southeast corner of the front room of the
building. Everything is neatly organized, let's keep it that way!
The magnetic stripe card reader was giving me such guff! It really didn't
want to work, and I tested every single component to try to figure it out.
I swapped to a new USB hub with a power supply several times, but on my
last try it miraculously went from non-working to working. I have no idea
why.
I did, however, build a theory for the color code of the magnetic stripe
card reader:
- Red LED - power is on, problem with connection
- Yellow LED - power is on, no connection
- Green LED - power is on, connected
- UNLESS the green LED turns off after just one swipe, in which case:
- No light from LED - no power, possibly low power, or something else is
happening I can't explain.
// Matt
Hi Niki! I meant to respond when you sent a message like this awhile ago,
regarding someone who refused to properly close the door after opening it.
Before I talk about the technical situation, which I believe applies to
this problem, I want to try to answer your specific question.
The procedure for granting door access, when I do it, is by demonstrating
how the unlocking and re-locking procedure works, and making sure people
understand that they must re-lock the door after opening it.
But of course sometimes people will forget, or worse, actively shirk their
duty to re-lock the door. In the latter case, if a person refuses your
request to re-lock the door they unlocked, I will electronically revoke
their access until they explain themselves at the appropriate meeting.
This would also be appropriate for people who repeatedly forget to re-lock
the door after themselves.
We have been working on the door technology a lot this last week,
improving reliability. But we have been holding back on adding features
because I understand that we are very close to replacing the front door.
The new front door will not "unlock" and "re-lock" but will be the usual
type of door which you "buzz" open, and when it closes it locks again.
One of the features we can add in the meantime is a record of incidents
when people use their card to unlock the door, and it does not get
re-locked within 5 minutes. If the people are not members of La Commune,
we will know to contact them for re-education.
It's my understanding that we have received a permit to replace the front
door, and that someone bottomlining that project has taken measurements.
I do not know how long it will take or who is doing it, but this is why I
have not changed the front door system to activate the doorknob instead of
unlocking the pins. If it activated the doorknob instead, it would
automatically lock when the door closed again. But it's a lot of work to
do considering the door will be replaced very soon.
Once again, if any person with electronic access is being irresponsible
with unlocking the door, I am willing to de-activate their card until they
come to the appropriate meeting to resolve the problem.
And I will be more pro-active in reminding people to lock the door they
open, and I will look into the access logging feature.
thank you,
-jake
On Friday, Niki wrote:
Hey friends,
Can someone point me to where the procedure for granting new Sudo member
access to the space is (if there is one?)
The front door was left open by a Sudo member (no personal hard feelings!)
and I just want to make sure that it's being communicated to members that
the door should be closed and locked if no one is watching the front.
I am working on an orientation pamphlet for folks who are new to the space
(it's taking longer than anticipated!) so hopefully by the time we re-key,
we'll have something more tangible to provide people.
<3
N
Hi Otis and Fluor,
We are always improving the door system, and adding new features. At this
moment the system only works on the corner door at 48th and Shattuck, and
only works with magnetic stripe cards.
Any member of your group who wants a keycard can contact me or the access
mailinglist to set up your card. You can use any magnetic-stripe card
like a creditcard, debit card, gift card, even if it's totally expired and
you found it on the sidewalk. The door system will not write to the card,
only read it. Unfortunately BART cards and hotel key cards don't work.
We have a few cards you can use if you don't have one, but we're always
looking for more to give out, so check your junk drawers for old cards.
Soon we will be adding RFID to the card system, so you will be able to get
in with a weird rubber watch thing, by holding it near the reader, and we
have tons of those. But it's not ready yet.
We will also be adding this type of system to other doors on the building,
including the doors on 48th street, and to many inner doors of the
building one by one (for example Sudoroom and CCL).
the point is, people who want access should contact me or the access list
to get an access card.
thank you,
-jake
On Tue, 9 Jun 2015, Otis Pig wrote:
> Timeless, Infinite Light members who need key access:
> Emji Spero
> Joel Gregory
> Zoe Tuck
> Paolo Yumol
>
> I believe that's everyone!
>
> On Mon, Jun 8, 2015 at 7:01 PM, Fluor Lara <fluorescentpeacock(a)hotmail.com> wrote:
> Hi, Here's the list of collective member names for MPM. Sorry, I thought I had sent this before. Some of the members are pending, but solid enough that
> by the time we get keys made they will be fully through our process.
>
> Still confused about the key card thing, if the plan is for it to be building-wide? Lara
>
> Lara Durback
> Ian Dolton-Thornton
> Emji Spero
> Kate Robinson
> Ava Rosen
> Ali Meyers-Ohki
> MG Roberts
> Robin Babb
> Simona Otyrba
> John Schmidt
> Hillary Savage
> Willow Germs
> Niki Shelley
> Chloe Minervini
>
>
> _______________________________________________
> consensus mailing list
> consensus(a)lists.omnicommons.org
> https://omnicommons.org/lists/listinfo/consensus
>
>
>
>
on omnidoor, see
/etc/init.d/doorhealth
/etc/rc5.d/S18doorhealth -> ../init.d/doorhealth
unfortunately,
root@omnidoor:/etc/init.d# service doorhealth start
Starting /root/sudobot/health.js
/usr/local/bin/psy start --logfile /var/log/sudobot.log --name doorhealth -- node /root/sudobot/health.js
path.js:360
throw new TypeError('Arguments to path.join must be strings');
^
TypeError: Arguments to path.join must be strings
at path.js:360:15
at Array.filter (native)
at Object.exports.join (path.js:358:36)
at Object.<anonymous> (/usr/local/lib/node_modules/psy/cmd.js:38:40)
at Module._compile (module.js:456:26)
at Object.Module._extensions..js (module.js:474:10)
at Module.load (module.js:356:32)
at Function.Module._load (module.js:312:12)
at Function.Module.runMain (module.js:497:10)
at startup (node.js:119:16)
however, running the same command at the commandline seems to work:
root@omnidoor:/etc/init.d# /usr/local/bin/psy start --logfile /var/log/sudobot.log --name doorhealth -- node /root/sudobot/health.js
no idea why this is. also, i renamed /root/doorjam-health to
/root/sudobot in a vain attempt to reduce confusion. probably health.js
should be called doorhealth.js since the command psy log doorhealth only
works if the process --name is doorhealth...
substack, did you have anything trying to auto-start health.js on
omnidoor? because Marc and I made this to do that, since sudobot just
complains continuously until it can get ahold of "doorhealth"
Last night substack and myself hacked on door access. The door computer was
down and it looks like some minor filesystem corruption. substack fixed the
problem with help from yar.
It may not have been anything serious. A breaker had tripped and maybe the
filesystem was just in the middle of a write when the computer lost
battery. smartctl reports no major problems with the harddrive.
I worked on getting a beagle bone black set up with doorjam to replace the
laptop. I had some troubles so I didn't quite finish, but it's pretty
close. It is running a modified debian
I put it inside of the vending machine with the poster on it, toward the
bottom. The box actually says "vending machine beagle bone" which is false.
Feel free to continue working on it, but read /root/INSTRUCTIONS before use.
If you have access to omnidoor.local you have access to this beagle bone.
The easiest way to talk to the bbb during development is to hook it up
using a mini-usb cable. It will power on and you will see that you suddenly
have a new network interface with the IP 192.168.7.1 and you can now ssh
into the bbb at 192.168.7.2 (you will also get a storage device attached
when you plug it in, but just ignore that).
It is set up with Debian 7 (we can move to the new version when the beagle
bone developers move to it) with the /boot and / partitions residing on the
internal flash memory. It is configured to run with read-only /boot and /
partitions. The micro-sd card should be where all writable permanent data
resides. That means the access control list (and maybe the logs?)
The micro-sd card is mounted at /mnt/sd_card by the /etc/init.d/doorjam
script
I have gotten to the point where everything is installed but doorjam has
not been configured to store its data on /mnt/sd_card
Other ToDo items:
* Make script for hardware watchdog
** Maybe interface watchdog script with irc bot?
* Mount it in nice box near door
* Give it battery backup
--
marc/juul
