controller device ip configuration

markvdb commented 10 years ago

The simplest way:

user connects controller device to postprocessing workstation directly (ethernet crossover cable link)
dhcp server on controller device assigns user ip
controller device dhcp server assigns its own minimal dns server to user. See http://code.activestate.com/recipes/491264-mini-fake-dns-server/?in=lang-python for a candidate.
user opens browser and goes to whatever address
controller device dns server responds with its own ip to every dns request

Another scenario I could think of (only 90%+ guaranteed result):

user connects controller device to his network.
network assigns controller device ip via dhcp.
controller device stores last received dhcp client ip to sd card.
user powers down controller device.
user pulls out sd card and writes down dhcp client ip stored on sd card.
user immediately puts back sd card and reboots controller device.
controller device receives same dhcp lease (this should easily be 90%+ of cases).
user navigates browser to read out ip.

Fallback scenario (requires access to router and willingness to try and understand instructions beyond ordinary user level):

user connects controller device to his network
network assigns controller device ip via dhcp.
user reads controller device from router dhcp client table based upon controller device mac address
user connects to ip

Another option may be to make the controller device avahi discoverable https://en.wikipedia.org/wiki/Avahi_(software) and http://www.linuxplanet.com/linuxplanet/reports/6826/1 .

https://en.wikipedia.org/wiki/Zeroconf

Windows Vista, 7, 8 use LLMNR https://en.wikipedia.org/wiki/LLMNR . GPL ipV6 implementation at http://www.vx68k.org/xllmnrd .

(old?) windows only protocol may catch some more scenarios: nmbd http://www.samba.org/samba/docs/man/manpages-3/nmbd.8.html

markvdb commented 10 years ago

Pity http://dnssd.me/ is gone...

jbaiter commented 10 years ago

Another option would be to run the Pi as a dedicated WiFi hotspot that the user has to connect to. This could easily be accomplished with even the cheapest stick and is a lot easier than all the methods listed above. That is, offer this as an option to the less tech savy users, the others could probably deal with running a small Python application that uses zeroconf to discover the service and open a browser with the interface :-)

markvdb commented 10 years ago

I didn't include that option yet in this minimalist proposal because:

a stick would require (on the rpi) additional hardware; not only a stick, but also a usb hub. Dan would really love to stay with the pi as a hardware platform.
addditional hardware would need to be "blessed" and tested for the end users that might have a problem, meaning a dependency on one particular stick
wifi would require
wifi is always less reliable than wired. This would mean additional testing for things like bandwidth.

For end users not capable of finding out the device's ip address, nothing beats cross cable with dhcp server in terms of simplicity. And I'm fairly sure an additional layer of bonjour/avahi, netbios from samba and llvmr would be able to catch a very high percentage in any other scenario.

This is Mark-the-free-software-person acting against the interest of Mark-the-machine-salesman.

2014/1/14 Johannes Baiter notifications@github.com

Another option would be to run the Pi as a dedicated WiFi hotspot that the user has to connect to. This could easily be accomplished with even the cheapest stick and is a lot easier than all the methods listed above. That is, offer this as an option to the less tech savy users, the rest can just look up the IP on their router or maybe just run nmap. That being said, maybe I can also whip up a script that scans the network for open ports and sees on which one the api runs on...

— Reply to this email directly or view it on GitHubhttps://github.com/DIYBookScanner/spreads/issues/45#issuecomment-32245716 .

Mark Van den Borre Hogestraat 16 3000 Leuven, België +32 486 961726

jbaiter commented 10 years ago

I'm afraid the Pi alone wouldn't have sufficient USB ports in any case, since there should be a way to connect a triggering device like a foot-pedal, and the Pi only offers 2 ports :-/ Triggering via smartphone/computer could get tiresome very quickly. But you're absolutely right concerning stability/bandwidth, WiFi could indeed cause a lot of troubles.

I'm not quite sure about your reservations concerning zeroconf, it's in my opinion far less hassle than a crossover cable:

Zeroconf:

Download discovery executable (cross-platform should be no problem)
Run, Browser with interface will be opened
Bookmark address (can be automated), no need to run the discovery tool ever again

DHCP/Crossover-Cable

~~Dang, I don't have a crossover cable, run to store, buy cable~~ I assume you'll be shipping the cable ;-)
Plug in, wait for IP
Use webinterface
Dang, I need to look something up on the internet...
Unplug crossover cable, plug in old ethernet cable
Look stuff up
Unplug old ethernet cable, plug crossover, wait for new IP

A compromise could be to rely on zeroconf by default, but when an ethernet cable is present and we didn't find a DHCP server (which would indicate that we're on a crossover link), we spin up our own DHCP and DNS server and follow your scenario. This logic should be outside of the application and reside in some system script.

markvdb commented 10 years ago

2014/1/14 Johannes Baiter notifications@github.com

I'm afraid the Pi alone wouldn't have sufficient USB ports in any case, since there should be a way to connect a triggering device like a foot-pedal, and the Pi only offers 2 ports :-/

When using a pi, the foot pedal could be connected to the controlling pc. Otherwise, we'd better run with a different controller board anyway. I have a good candidate in my pocket.

Food for a separate issue (please feel free to split this off). With the foot pedal on the controller device itself, did you investigate detecting triggerings in python. Since the pedal has no controlling terminal, you'd have to use some other magic on the usb/kernel level to detect it being triggered... I did a rough hack monitoring proc for this.

I'm not quite sure about your reservations concerning zeroconf, it's in my opinion far less hassle than a crossover cable:

I think zeroconf and friends based configuration would be a really nice goal. I would definitely aim for that in the near future.

Zeroconf:

Download discovery executable

Run, Browser with interface will be opened

Bookmark address (can be automated), no need to run the discovery tool ever again

DHCP/Crossover-Cable

Dang, I don't have a crossover cable

This is not an issue anymore. Any recent pc does autosensing.

Run to store, buy cable

Plug in, wait for IP

Use webinterface

Dang, I need to look something up on the internet...

Unplug crossover cable, plug in old ethernet cable

Look stuff up

Unplug old ethernet cable, plug crossover, wait for new IP

Agreed, this would be a bit messy. But then again:

the user would have a guaranteed working solution

it would be really simple to implement

it could be trivial to switch to zeroconf based setup through the web interface in a later iteration

jbaiter commented 10 years ago

Concerning triggering, check out the triggerplug branch in my fork, it does just that :wink:.

As for discovery, would you be okay with the approach outlined above (zeroconf by default, dhcp/DNS if crossover cable is present) ¿

markvdb commented 10 years ago

I think I have found the most elegant solution:

zeroconf only
in case windows based zeroconf doesn't work, show the user an android app (there apparently are gpl zeroconf apps for android, but not for windows)
emergency rescue scenario: have the scanner dump its ip config to an sd card on the camera on every boot. Every user is acquainted with pulling an sd card from a camera...

That could keep the setup simple and still zeroconf based, with all the advantages that brings.

http://jmdns.sourceforge.net http://cafbit.com/entry/testing_multicast_support_on_android

jbaiter commented 10 years ago

Android App is kind of a hacky solution (not everybody has an Android device), but better than the SD-Card move :-)

There might be a problem with that one, too: RPi system partitions are formatted as ext3, which cannot be mounted on windows without third party drivers. We could of course add a vfat partition to the card, but that would be a big hassle just for that one use case...

Good news, though: zeroconf on windows should be possible, I intend to use the zeroconf python module, which on Linux wraps the avahi tools, and on Windows/OSX uses the dns-sd executable bundled with Apple's Bonjour, which is bundled with iTunes on Windows. I managed to extract it from the package, though, but I'm not sure if we would be allowed to package it with the discovery executable...

markvdb commented 10 years ago

Johannes, I meant the sd card in a camera. We can upload a file with the scanner ip to an attached camera. So there's no issue with pulling that out. That scenario would play only:

if the user is does not have a linux, mac or android machine available for detecting the scanner
if the user doesn't wish to install the freeware win zeroconf explorer (some limitations seem to apply there)
and if the user is not network savvy enough or doesn't have enough rights to find the scanner's ip in his router

Mark

2014/1/14 Johannes Baiter notifications@github.com

Android App is kind of a hacky solution (not everybody has an Android device), but better than the SD-Card move :-)

There might be a problem with that one, too: RPi system partitions are formatted as ext3, which cannot be mounted on windows without external hardware. We could of course add a vfat partition to the card, but that would be a big hassle just for that one use case...

Good news, though: zeroconf on windows should be possible, I intend to use the zeroconf https://github.com/boisgera/zeroconf python module, which on Linux wraps the avahi tools, and on Windows/OSX uses the dns-sdexecutable bundled with Apple's Bonjour, which is bundled with iTunes on Windows. I managed to extract it from the package, though, but I'm not sure if we would be allowed to package it with the discovery executable...

— Reply to this email directly or view it on GitHubhttps://github.com/DIYBookScanner/spreads/issues/45#issuecomment-32260987 .

Mark Van den Borre Hogestraat 16 3000 Leuven, België +32 486 961726

jbaiter commented 10 years ago

I think I have an even better idea:

Run a Lua script that displays the IP on the camera displays when the server starts and keep it there for as long as the web server is running.

The CHDK Lua API supports this via the draw_string function.

markvdb commented 10 years ago

Yes, Johannes, yes! Brilliant!

2014/1/14 Johannes Baiter notifications@github.com

I think I have an even better idea:

Run a Lua script that displays the IP on the camera displays.

The CHDK Lua API supports this via the [draw_string[( http://chdk.wikia.com/wiki/Lua/Lua_Reference#Commands_available_are:) function.

— Reply to this email directly or view it on GitHubhttps://github.com/DIYBookScanner/spreads/issues/45#issuecomment-32262098 .

Mark Van den Borre Hogestraat 16 3000 Leuven, België +32 486 961726

matti-kariluoma commented 10 years ago

+1 writing IP to chdk's display. As was mentioned in IRC, the display on the cameras can be mostly taken over for this (and similar) purposes, esp. if we put live-preview in the web interface (it is quite difficult to look at the back of the camera while scanning).

[USB] Let me channel Daniel for a moment: It is accepable to use a (powered) USB hub, the RPi's 2x USB do not deliver enough power and are known to cause problems. Also, there are plans to support camera trigger from a USB keyboard.

[Trigger] Foot pedals: the RPi has many gpio. If all you want to do is close a switch, there's no need to involve USB.

jbaiter commented 10 years ago

[Trigger] Foot pedals: the RPi has many gpio. If all you want to do is close a switch, there's no need to involve USB.

Indeed, but I think custom electronics are not ideal from a usability perspective. Users should be able to use an off the shelf footpedal from eBay or Amazon.

jbaiter commented 10 years ago

This has been implemented (https://github.com/DIYBookScanner/spreads/commit/c6b1060aca62d236236eae8e3cf25e5772e36da2)

DIYBookScanner / spreads

controller device ip configuration #45