dhess / mellon

Control physical access device (e.g., an electric strike) from Haskell

Mellon

"Speak, friend, and enter."

Mellon is a set of Haskell packages for controlling physical access devices, such as electric strikes and other electronic locks. The set of packages includes:

• mellon-core, which provides the core functionality upon which the other packages depend.

• mellon-gpio, for controlling physical access devices via GPIO.

• mellon-web, a web interface (with client and server bindings) for interacting with Mellon controllers.

mellon's Issues

Get rid of "as X" module exports

Not very useful for generated docs.

Port to Protolude

Release v0.9.0.0

Fix sort order in mellon-web API.hs doctests.

### Failure in src/Mellon/Web/Server/API.hs:129: expression `toJSON $ Unlocked sampleDate'
expected: Object (fromList [("state",String "Unlocked"),("until",String "2015-10-06T00:00:00Z")])
 but got: Object (fromList [("until",String "2015-10-06T00:00:00Z"),("state",String "Unlocked")])
Examples: 18  Tried: 16  Errors: 0  Failures: 1

Release v0.8.0.6.

Need MVar exception safety in controller

In the current implementation, if a thread holding the lock throws an exception, nobody will ever "put" the MVar back, so all subsequent uses of the controller will block. It might not be safe to use the controller after an exception, anyway, but there's no mechanism to enforce this.

Probably what we need is a way to specify, when creating the controller, what state to put it in when the exception occurs, and then use 'withMVar' and friends in the controller implementation to ensure that value is put back into the MVar before re-throwing the exception.

(Might also need to consider adding a "dead" state to the state machine so that the user could specify that the controller can't be used anymore after an exception occurs. I'm not completely sure this is necessary as it might just as easy just kill the application in that case, or to re-create the controller.)

Add authentication support to mellon-web server API

Fix mellon-web ServerSpec.hs test

On slow hosts, it can fail. Either fix it, or disable it by default.

      test/Mellon/Web/ServerSpec.hs:116: 
      1) Mellon.Web.Server.Unlocking expires at the specified date
           expected: Just Locked
            but got: Just (Unlocked 2018-02-04 08:38:07.567438 UTC)

Update to latest version of gpio

Release v0.8.0.7

Fix mellon-server examples

Release v0.8.0.5.

An unlock time in the past should probably be ignored

I thought it would be clever to treat a time in the past as an alias for "unlock indefinitely," but it leads to the potential problem of an unlock request with short unlock period -- say, 1 or 2 seconds -- being delayed during delivery -- say, due to a network hiccup -- and then keeping a door open indefinitely rather than just for a short time as the sender intended.

One solution to the problem would be to change the protocol to use relative times rather than absolute dates ("unlock the door for 7 seconds after the arrival of this message"), but that leads to all kinds of other issues and corner cases. (Figuring out that unlock durations should be specified as an absolute date was key to simplifying the mellon protocol to its current state.)

The better solution is to take advantage of Haskell's type system and wrap unlock times in another type, akin to a Maybe, where one value means "indefinitely" and the other means "until the specified date," and then have the controller simply ignore dates that are in the past. It doesn't eliminate the problem of delayed command delivery, of course, but in most cases it's probably better to ignore a late request than to mistake it for an indefinite unlock request.

Better exports

Provide a top-level file for each module.

gpio-mellon-server should handle exceptions cleanly

Give the user an option to ignore/die/restart on an exception.

Also consider "library-izing" the service so that someone could wrap it up in a logging or notification system.

Clean up .travis.yml

Use a proper test framework.

Move the test that's in the "mellon" executable into a test executable.

Support async 2.2

Remove references to no-longer-provided API.md file

It's been replaced by the Swagger support.

Investigate dejafu

I was this close to implementing something like this in mellon just for testing it; now I don't have to!

https://hackage.haskell.org/package/dejafu-0.1.0.0

Add armv7l support to jobsets.