doesliverpool / doorbot-setup Goto Github PK

The readme.md lists "Copy the startup script into /etc/init" in the "To be done" section.

The remote-setup.rb script includes the line:
ssh.exec!("sudo cp /home/pi/logcards/init/logcards /etc/init.d/") do |channel, stream, data|
which looks like it's copying the script across.

However, none of the doorbots up and running have the logcards script in /etc/init.d

It looks like that's been deprecated, and some script called startup-rfid.sh - which doesn't seem to be checked in anywhere? - is in use instead?

an automatically pull from doorbot-config and reload to have the latest version.

All the ssh commands in remote-setup.rb only output the stdout stream. They should also output, if not also stop, anything sent to stderr.

At present there's no way to know if any of the commands had failed to execute.

Should set the audio volume to max in setup.

We should add a reset button or power switch to the custom PCB to make it easier to power-cycle a non-responding doorbot (rather than having to pull the lead out of the PC power supply, as is the current option with doorbot1)

Given that DoESLiverpool/somebody-should#426 shows up problems with the SD card size, it'd be good to move to Raspbian-lite rather than the full-fat Raspbian (given that that's a thing now :-)

If we're doing that, and working out what's needed to get X on doorbot1 (or working out if we don't need it as KWeb3 can possibly run direct to framebuffer) I'm considering switching over to ansible for the development (as I've already got bits of that lying around, e.g. https://github.com/mcqn/etherpad-in-a-box and https://github.com/museuminabox/brain/blob/master/INSTALL.md)

Raising this issue so I can create a branch referring to it, to make a start on it...

The task "Install the browser" hung for ages once it stopped and I tried running the script again apt complained that I'd have to run sudo dpkg --configure -a manually, once I did that it asked me if I wanted to install youtube-dl. I want to change the browser anyway but wanted to note this issue here as it has tripped me up a times.

Trying out the RFID keyboard mentioned in #11 (comment) just now with @paulfurley's card, it ended up adding an extra 0 to the octet that was less than 0x10.

I'd have raised the issue on the keyboard's repo directly, but can't remember my login details for it.

We could add one of these I2S DAC boards with on-board amplifier to the doorbots in order to get better audio output (or remove the requirement for separate PC speakers)

See my museuminabox work for details of how to wire up the board (and check out the Ansible scripts elsewhere in that repo for details of how to configure the software side of the audio)

Would be useful to have a wiring diagram for how to connect the RFID reader, relay and door solenoid.

I wasn't paying enough attention to the hardware on the Pi that the PCB mounts onto and so designed it such that it fouls the higher components - the Ethernet jack and USB sockets on a Pi 2/3, and also the composite video connector on the Pi 1.

We should redesign it so that it doesn't foul, although as a workaround we could use Pi Zeros, or stackable headers. (That's likely a reasonable first step, given we've got about 15 blank PCBs to use up first :-)

I think we can stop using custom SSH ports now, it was only there for the port forwarding and now we have VPN access and are not doing port forwarding there's no need.

The canonical copy of the config.yaml lives in bitbucket. However, so far we tend to update it on doorbot1 and just copy it across.

The reload-all-config.sh script should perform a git pull rather than copying things across.

The dd command to copy the Raspbian image over onto the SD card needs the SD card to be unmounted first.

The script doesn't currently check/perform this, and it should do.

Need to install X and at least set the background to the DoES logo.

I just had to copy the open-door.sh scripts from doorbot1 to the other doorbots.

pi@doorbot1:~ $ scp open-door.sh pi@doorbot2:
open-door.sh                                                                          100%  133     0.1KB/s   00:00    
pi@doorbot1:~ $ scp open-door.sh pi@doorbot4:
open-door.sh                                                                          100%  133     0.1KB/s   00:00    
pi@doorbot1:~ $ scp open-door.sh pi@doorbot5:
open-door.sh                                                                          100%  133     0.1KB/s   00:00    

@johnmckerrell says Ansible should do this.

Need to decide how to deal with ringtones. They either need to be stored in the bitbucket repository with the rest of the config, or once the doorbot has been setup a script needs to be run to copy them from doorbot1 to the other machines. Former probably better so that they're stored and backed up somewhere properly.

The kitchen doorbot has had two PCBs fail now with the tracks overheating and burning out.

We should make the traces which carry significant current (particularly the 12V traces connected to the solenoid) thicker.

It's useful to be able to ssh from one doorbot to another with just "ssh doorbot2" for example.

The /etc/hosts should have the doorbots added to it during the setup process (or we should move to using doorbotX.local and mDNS).

Plus we should copy across SSH keys for the new doorbot so we don't have to enter the password each time.

I can't find any way to add my bitbucket user (amcewen) to the DoES repository, so can't clone the config repository.

If left to wobble around in its current cardboard box enclosure, Doorbot2 is prone to rebooting whenever there's a knock to the door, like when the door shuts :-)

We should find a proper mounting solution for the Pi and the little breakout board, so they can't move around.

Happened upon http://www.raspberrypi.org/web-browser-beta/ which talks of a Pi-optimized web browser. Might be worth a try as a replacement to Chrome, assuming it can do the same kiosk-mode sort of operation.

Doing a dry-run fit of the Molex power connector to the PCBs that were fabbed for #6 shows they don't quite fit through the holes. We should make the holes in the PCB a tiny bit larger so next time we do an order (which might be a while, as we've got 24 of the current PCB to use up first :-)

As a workaround we should be fine to file down the pins on the Molex connector a touch.

Maybe something like Kwalify could be used for local validation.