Whats ACNode? WAS: 3 in 1 - keyless chuck and state of machine?

[Ciarán Mooney]

Hi

On 15 January 2013 08:54, chrisbob12 <chris...@yahoo.com> wrote:
> What's ACNode?

ACNode is a access controll system being designed in house. It will
use an RFID card to control access to those who have had training to
certain pieces of equipment.

http://wiki.london.hackspace.org.uk/view/Project:ACNode

Ciarán

[chrisbob12]

Thanks, that makes sense.

[Mark Steward]

Gah, I knew as soon as I put up code, someone else would.  Here's my python version, currently lacking the DB part.

  https://github.com/londonhackspace/ACNode

Incidentally, I've also heard of someone working on a PHP version and another Python one, but nobody else has actually put their code anywhere.

Mark

On Tue, Jan 15, 2013 at 9:23 AM, <asoko...@gmail.com> wrote:

By the way, I have started hacking on the server side of the network protocol for this.  I'll update the wiki page with this.

https://github.com/asokoloski/tacserv

It uses a Sqlite3 database to store the permissions.  I don't know how our global member info is stored, but I assume it doesn't matter whether someone is a member or not when giving them access to a tool.

If I'm on completely the wrong track, can someone let me know?  All I've done so far is "Get card permissions", "Add card", and "Check db sync".

Aaron

--
 
 

[asoko...@gmail.com]

On Wednesday, January 16, 2013 10:04:44 AM UTC, Mark Steward wrote:

Gah, I knew as soon as I put up code, someone else would.  Here's my python version, currently lacking the DB part.

  https://github.com/londonhackspace/ACNode

Incidentally, I've also heard of someone working on a PHP version and another Python one, but nobody else has actually put their code anywhere.

Well, I was first :P

But we can use your code, as it seems more complete -- unless you feel like learning Go.  The only thing I would recommend is using Sqlite -- I think it'll be much easier than trying to manually manage a json database file.  Or is there another reason to use json?

Aaron

[Mark Steward]

On Wed, Jan 16, 2013 at 10:16 AM, <asoko...@gmail.com> wrote:

On Wednesday, January 16, 2013 10:04:44 AM UTC, Mark Steward wrote:

Gah, I knew as soon as I put up code, someone else would.  Here's my python version, currently lacking the DB part.

  https://github.com/londonhackspace/ACNode

Incidentally, I've also heard of someone working on a PHP version and another Python one, but nobody else has actually put their code anywhere.

Well, I was first :P

That's what I was afraid someone would say, which is why I haven't got involved previously.  It would have saved me some effort if you'd sent your email 10 days ago.

But we can use your code, as it seems more complete -- unless you feel like learning Go.  The only thing I would recommend is using Sqlite -- I think it'll be much easier than trying to manually manage a json database file.  Or is there another reason to use json?

I don't mind what language it's in, as long as you're not the only person who speaks it.  The database is transferred as json because it's transparent and easily parsed in any modern language.  You can store it locally in any format you like (I was planning to use sqlite, too).

Mark

[Graham Rounce]

... and would also allow identification of machine-wreckers? Of
course, nobody's considering that aspect ;)

On Jan 15, 9:05 am, Ciarán Mooney <general.moo...@gmail.com> wrote:
> Hi
>

[Mark Steward]

That's definitely part of it.  The plan (at least, last I heard) is to have a "this is broken" button that will take the machine out of service, allowing us to see who the last user was.

Mark

--

[Graham Rounce]

'to have a "this is broken" button that will take the machine out of
service'

Well, there's broken and broken... damaged, superficially damaged,
unusable, dangerous... One doesn't want to find a machine locked out
because of a scratch, or some aspect of it is u/s that one's not
trying to use, or that one might be able to fix.

On Jan 16, 10:35 am, Mark Steward <markstew...@gmail.com> wrote:
> That's definitely part of it.  The plan (at least, last I heard) is to have
> a "this is broken" button that will take the machine out of service,
> allowing us to see who the last user was.
>
> Mark
>

> On Wed, Jan 16, 2013 at 10:33 AM, Graham Rounce <grahamrou...@googlemail.com

[Aaron Sokoloski]

On Wed, Jan 16, 2013 at 10:30 AM, Mark Steward <marks...@gmail.com> wrote:

That's what I was afraid someone would say, which is why I haven't got involved previously.  It would have saved me some effort if you'd sent your email 10 days ago.

 
My apologies for that.  I had intended to get a more complete implementation before sending something out, but finally decided to just go for it.  At least now nobody else will start another implementation.

I don't mind what language it's in, as long as you're not the only person who speaks it.  The database is transferred as json because it's transparent and easily parsed in any modern language.  You can store it locally in any format you like (I was planning to use sqlite, too).

I don't know how well known Go is amongst london hackspacers, so I'm inclined to just join you in your python implementation.

So when you say the DB is "transferred to json", and that can be stored locally, what do you mean?  Why two copies?  Forgive me if I'm ignorant of any existing hackspace software system conventions -- I've only been a member for about 2 weeks now.

[Mark Steward]

The membership database is stored on turing.hackspace.org.uk, which is the VM we use for the website and has restricted access.  The current plan is for the ACNode server to run in the space, allowing it to be fully functional even if the website's down.  The "API" for getting access to membership data is currently to download the list of members, cards and permissions as a JSON object over HTTPS.  We could in theory make a cut-down sqlite database available instead, but that moves the work to the server and makes it awkward if we want to use a different back-end on either side.

Mark

On Wed, Jan 16, 2013 at 10:58 AM, Aaron Sokoloski <asoko...@gmail.com> wrote:

On Wed, Jan 16, 2013 at 10:30 AM, Mark Steward <marks...@gmail.com> wrote:

That's what I was afraid someone would say, which is why I haven't got involved previously.  It would have saved me some effort if you'd sent your email 10 days ago.

 
My apologies for that.  I had intended to get a more complete implementation before sending something out, but finally decided to just go for it.  At least now nobody else will start another implementation.

No probs, I only started work because I'd heard lots of rumours of code and nothing visible.  Solexious says he's waiting for the server side (apparently the prototype is no good), so whatever gets us to working code is all that matters.

I don't mind what language it's in, as long as you're not the only person who speaks it.  The database is transferred as json because it's transparent and easily parsed in any modern language.  You can store it locally in any format you like (I was planning to use sqlite, too).

I don't know how well known Go is amongst london hackspacers, so I'm inclined to just join you in your python implementation.

So when you say the DB is "transferred to json", and that can be stored locally, what do you mean?  Why two copies?  Forgive me if I'm ignorant of any existing hackspace software system conventions -- I've only been a member for about 2 weeks now.

The membership database is stored on turing.hackspace.org.uk, which is the VM we use for the website and has restricted access.  The current plan is for the ACNode server to run in the space, allowing it to be fully functional even if the internet connection is down.  The "API" for getting access to membership data is currently to download the list of members, cards and permissions as a JSON object over HTTPS (I'll also add a means to update permissions).  We could in theory make a cut-down sqlite database available instead, but that moves the work to the server and makes it awkward if we want to use a different back-end on either side.

Hope that makes sense - suggestions welcome.

Mark

[Mark Steward]

Disregard the top part of this email - I decided to reply in-line half-way through!

[Aaron Sokoloski]

On Wed, Jan 16, 2013 at 11:20 AM, Mark Steward <marks...@gmail.com> wrote:

The membership database is stored on turing.hackspace.org.uk, which is the VM we use for the website and has restricted access.  The current plan is for the ACNode server to run in the space, allowing it to be fully functional even if the website's down.  The "API" for getting access to membership data is currently to download the list of members, cards and permissions as a JSON object over HTTPS.  We could in theory make a cut-down sqlite database available instead, but that moves the work to the server and makes it awkward if we want to use a different back-end on either side.

Ah, ok.  That's the bit I was missing.  So I'm going to explain the system as I understand it, and you tell me whether I'm right or not.

We have three separate types of databases.  There is the main, canonical member database, which runs on turing.  There is the ACNode server, which has a local database (sqlite), and periodically syncs with the main database on turing (using json).  Then, each node has its own local database, which is really no more than a cache.

And I'm guessing the reason for not running ACNode on turing is just security?  Although, if you say that the permissions are stored on turing as well, then it makes sense for the interface for updating those permissions to be on turing too.  How do all the interfaces work?

Cheers,
Aaron

[Mark Steward]

On Wed, Jan 16, 2013 at 11:37 AM, Aaron Sokoloski <asoko...@gmail.com> wrote:

On Wed, Jan 16, 2013 at 11:20 AM, Mark Steward <marks...@gmail.com> wrote:

The membership database is stored on turing.hackspace.org.uk, which is the VM we use for the website and has restricted access.  The current plan is for the ACNode server to run in the space, allowing it to be fully functional even if the website's down.  The "API" for getting access to membership data is currently to download the list of members, cards and permissions as a JSON object over HTTPS.  We could in theory make a cut-down sqlite database available instead, but that moves the work to the server and makes it awkward if we want to use a different back-end on either side.

Ah, ok.  That's the bit I was missing.  So I'm going to explain the system as I understand it, and you tell me whether I'm right or not.

We have three separate types of databases.  There is the main, canonical member database, which runs on turing.  There is the ACNode server, which has a local database (sqlite), and periodically syncs with the main database on turing (using json).  Then, each node has its own local database, which is really no more than a cache.

Yup, that's my understanding.

And I'm guessing the reason for not running ACNode on turing is just security?  Although, if you say that the permissions are stored on turing as well, then it makes sense for the interface for updating those permissions to be on turing too.  How do all the interfaces work?

Mostly because we don't want everything to stop working if the internet connection or server are down.  The interfaces for updating permissions and checking an individual card haven't been written yet, but they're pretty noddy - I was planning to knock them out this evening or tomorrow.  Code for the website is currently here:

  https://github.com/londonhackspace/hackspace-foundation-sites

Mark

[Dirk-Willem van Gulik]

So in a perfect world perhaps this should be a bit more distributed - more like a web of trust. Collectively maintained and patterned on the fabric of our social relations.

So rather than a central database each rfid tag leads to a simple lookup of a CNAME <base64ofWhatWasRead>.globalhackspaces.org. This CNAME points to a (personal) site where one can fetch a file (containing a persons name, email and rfid number) which is signed by various people or entities. The lathe simply checks if any of the signatures is made by a an entity whose chain it trusts (e.g. another person or a person whose was signed on by a hack space trusted). It then unlocks. Potentially recording the details inside the package. Approving someone for a machine then becomes a personal thing - where one signs another person, vouches for him or her. And trust of a machine is then trust in a (chain) of such human relations. Obviously to be scalable one would swiftly end up introducing the concept of a board/trustee members who delegate - and inter hackspace trust for certain things. And in order to keep the globalhackspace.org scalable one would put the CNAME under SIG control with a simple additional rule that anyone who creates a not yet used pub/priv pair and not yet used rfid tag can add it the first time without ado. 

 

One can only dream :)

 

Apologies - have had a bad morning going through spreadsheets with VAT accounting - so had to vent a wee little :)

Dw.

[930913]

If we have a pi terminal in each room anyway, for camera/speakers/mic and thin clients, does that then make the bulk of the ACNode system? A card reader can be added to each terminal, and a whole GUI can be designed to allow members to unlock the tools they want and haver permission to access. Logging, in a fashion similar to the laser cutter now, can occur on these terminals, and rather than just a hardware "borked" button, the member can state what the problem is, and whether it just needs to be maintained (calibration off), or taken out of action (live wire touching handle.)

Forgive my electrical ignorance, but connections to any tool in the room, is simply a matter of running a pair of wires (heck, even just one and use the building's ground) down to a mains relay. That's <£5 for every additional tool.

[Aaron Sokoloski]

On Wed, Jan 16, 2013 at 11:50 AM, 930913 <proxify....@googlemail.com> wrote:

If we have a pi terminal in each room anyway, for camera/speakers/mic and thin clients, does that then make the bulk of the ACNode system? A card reader can be added to each terminal, and a whole GUI can be designed to allow members to unlock the tools they want and haver permission to access. Logging, in a fashion similar to the laser cutter now, can occur on these terminals, and rather than just a hardware "borked" button, the member can state what the problem is, and whether it just needs to be maintained (calibration off), or taken out of action (live wire touching handle.)

Forgive my electrical ignorance, but connections to any tool in the room, is simply a matter of running a pair of wires (heck, even just one and use the building's ground) down to a mains relay. That's <£5 for every additional tool.

I'm not too keen on the idea of coupling the tool access control with the camera/speakers/mic/thin client project.  It's nice if the systems can be maintained/upgraded separately, and, say, a problem with the thin client stuff doesn't disable all the tools in the room.  Having separate systems does mean a bit of duplication of hardware, but it decreases the overall complexity.  Sorry for my cynicism -- it's a nice idea if everything could be maintained perfectly, but I think that coupling systems together makes bugs and failures much more likely.

[Aaron Sokoloski]

On Wed, Jan 16, 2013 at 11:47 AM, Mark Steward <marks...@gmail.com> wrote:

And I'm guessing the reason for not running ACNode on turing is just security?  Although, if you say that the permissions are stored on turing as well, then it makes sense for the interface for updating those permissions to be on turing too.  How do all the interfaces work?

Mostly because we don't want everything to stop working if the internet connection or server are down.  The interfaces for updating permissions and checking an individual card haven't been written yet, but they're pretty noddy - I was planning to knock them out this evening or tomorrow.  Code for the website is currently here:

  https://github.com/londonhackspace/hackspace-foundation-sites

 

I see. The bit I was missing was that Turing isn't actually in the hackspace.  Thanks.

[tim_n]

Or someone who starts to use the machine, breaks it, presses the button essentially blaming the person before.

 

Blame rarely works for fiscal reasons as no-one will admit it and you won't be able to prove it with this device but if it's limited to expected training before you use it again, it's fair.

[Ciarán Mooney]

Hi,

> 'to have a "this is broken" button that will take the machine out of
> service'

I hope that this particular feature will be more used to track down
the last user, so the cause of the fault can be found rather than just
out right blaming and shaming. But that is a social problem that we
should probably not solve with technology.

> Well, there's broken and broken... damaged, superficially damaged,
> unusable, dangerous... One doesn't want to find a machine locked out
> because of a scratch, or some aspect of it is u/s that one's not
> trying to use, or that one might be able to fix.

That does certainly look like a bug rather than a feature. I'd like to
make a suggestion (I hope Sol reads this and agrees) that a user
pushing the "report fault" button does not take it out of service.
With the an additional function that is "take machine out of service"
which restricted to the maintainers only. I assume that these things
can be done remotely once the server-side is working.

Ciarán

[Tim Reynolds]

ACNode has just picked up steam again. Design criticisms entirely aside, let's not drag it back down by attaching it to the nebulous thin client proposal. 

On 16 Jan 2013, at 11:50, 930913 <proxify....@googlemail.com> wrote:

If we have a pi terminal in each room anyway, for camera/speakers/mic and thin clients, does that then make the bulk of the ACNode system? A card reader can be added to each terminal, and a whole GUI can be designed to allow members to unlock the tools they want and haver permission to access. Logging, in a fashion similar to the laser cutter now, can occur on these terminals, and rather than just a hardware "borked" button, the member can state what the problem is, and whether it just needs to be maintained (calibration off), or taken out of action (live wire touching handle.)

Forgive my electrical ignorance, but connections to any tool in the room, is simply a matter of running a pair of wires (heck, even just one and use the building's ground) down to a mains relay. That's <£5 for every additional tool.

--
 
 

[Mark Steward]

Before we get more bikeshedding:

 - All the code will be available on github once it's written.  You'll be free to make pull requests or discuss any aspect of it.

 - Nobody's going to assume that the person who used a tool immediately before a reported problem is the culprit and immediately string them up. The history of usage just gives us somewhere to start when tracking down the *cause*.

 - To address over-eager problem reporting, the out-of-service button will either be undoable (perhaps only by a maintainer if a maintainer took it out of service), or will differentiate "degraded" from "broken".  You can always unplug a tool at the wall and stick a note on it.

 - None of this stops people being reporting problems on the mailing list, IRC or in person.

Please wait until there's some code to look at before bringing up theoretical problems.

Mark

Ciarán

--

[Mark Steward]

That said, if anyone wants to help see whether it will run reliably on a dedicated Pi, I've got a box of USB RFID readers, a couple of spare Pis and a USB-powered relay to copy.

Mark

--
 
 

[930913]

Mark, I should be in the space from around 1700 onwards. It would be great to have a try if you're around too.

[Charles Yarnold]

As we have spoken in person many times now this is not a workable solution, its getting very tedious explaining this to you.

On 16 January 2013 11:50, 930913 <proxify....@googlemail.com> wrote:

If we have a pi terminal in each room anyway, for camera/speakers/mic and thin clients, does that then make the bulk of the ACNode system? A card reader can be added to each terminal, and a whole GUI can be designed to allow members to unlock the tools they want and haver permission to access. Logging, in a fashion similar to the laser cutter now, can occur on these terminals, and rather than just a hardware "borked" button, the member can state what the problem is, and whether it just needs to be maintained (calibration off), or taken out of action (live wire touching handle.)

Forgive my electrical ignorance, but connections to any tool in the room, is simply a matter of running a pair of wires (heck, even just one and use the building's ground) down to a mains relay. That's <£5 for every additional tool.

--
 
 

[Billy]

I'm not going to knock this proposal, but we've had problems in the
past where projects were proposed and in the initial rush of
enthusiasm they started well. When the initial rush of enthusiasm wore
off, the project got bogged down, and didn't progress. I'm as guilty
as everybody else at this pattern of behaviour.

Like i suggested in a previous post, build a demo.

Then when you've got something finished to display, show us that and
it will convince us.

Use one of the spare servers, and build one terminal, then when we can
see the value of your idea, we could roll out the rest.

If you need the skills or knowledge, ask the people who've got them
for help.

Less talk, more do.

[Eugene Nadyrshin]

I think the duplication of effort is stemming out of insufficient communication/documentation on what's been done/needs to be done on the server-side.
Looking on the page for the project there is a summary of requirements here.
The client side is very well documented though Sol's proposal that's linked of the main page, and the physical acnode prototype is ready AFAIK
There is absolutely nothing about what's being done on the "server" side and I think this is leading to the confusion.

Eager to get the ACnode project going I've offered to help out, but I and1 started writing the backend (CodeIgniter PHP) as per Sol's spec I was informed that Ms7821 has already wrote a substantial part.
(On my user-page) revision as of 01:11, 30 November 2012:

• 
  Access Control Server codename: ACServer the Tool Access Control project. Status: On hold pending Ms7821's solution that he has already started working on

Ms7821 can you please document what you have done, what needs to be done, and what people interested can help with. Not everyone knows Python and documentation should really be code agnostic to explain how the units in the proposed system interact!

Cheers
Mentar

[Eugene Nadyrshin]

Mark,
Can you please make sure that what you have done is documented:
Going to the Tool Access Control page, there is a good write up on the spec requirements.
Sol has liked his acnode proposal page and has detailed client-side documentation.
There is no mention of ANY work being done on the server or documentation on it, not even a link to the github project you started working on.
Like Aaron I came I assumed that nothing is being done and started writing my own implementation to complement Sol's documented api. Which after having a chat with you I decided to put on hold as since you've got some work done on it already and I don't want to distract myself with Python.
Hence on my wiki page, revision as of 01:11, 30 November 2012:

• 
  Access Control Server codename: ACServer the Tool Access Control project. Status: On hold pending Ms7821's solution that he has already started working on

So can you please document:

• What needs to be done as far as the server side is concerned
• What you have done already
• What other people can help with.
  

Cheers,
Mentar

--
 
 

[Nick Johnson]

tl;dr: LHS is a do-ocracy.

--

[Mark Steward]

On Wed, Jan 16, 2013 at 5:06 PM, Eugene Nadyrshin <ment...@gmail.com> wrote:

I think the duplication of effort is stemming out of insufficient communication/documentation on what's been done/needs to be done on the server-side.

Agreed.

 

Looking on the page for the project there is a summary of requirements here.
The client side is very well documented though Sol's proposal that's linked of the main page, and the physical acnode prototype is ready AFAIK
There is absolutely nothing about what's being done on the "server" side and I think this is leading to the confusion.

Eager to get the ACnode project going I've offered to help out, but I and1 started writing the backend (CodeIgniter PHP) as per Sol's spec I was informed that Ms7821 has already wrote a substantial part.
(On my user-page) revision as of 01:11, 30 November 2012:

• 
  Access Control Server codename: ACServer the Tool Access Control project. Status: On hold pending Ms7821's solution that he has already started working on

This edit is simply not true.  I helped Sol with the protocol spec and wrote a prototype after pestering back in March so he could test the physical prototype.  I made it clear (though apparently not clear enough) that I had no interest in writing the final version.  Jonty spent from July babysitting the prototype, hoping to write the server side, but no code appeared.  Dmi expressed an interest in working on it in October, and jontyw brought the prototype back so anyone who wanted could have a go with it.

Solexious mentioned in November that you were working on the server-side, and when I later asked whether the firmware was complete said he hadn't finished all the code and wanted to grab it back and do some polishing.  He mentioned adding a screen and power-over-ethernet, and enabling the watchdog timer.  I decided it was better to wait and see what happened with your code, rather than waste time on something I didn't really want to do.

On Monday, it became apparent that the polishing was not needed (I was told today that the physical prototype is now the final version), and Sol said he was poking you about your code.  As it was clear that the project was stalling on the software, I started work on the Python version that night, and told Solexious at the time.  I'm not precious about sunk costs, and have no attachment to this code - if you've got a version that's maintainable and you're willing to finish, then please continue.

 

Ms7821 can you please document what you have done, what needs to be done, and what people interested can help with. Not everyone knows Python and documentation should really be code agnostic to explain how the units in the proposed system interact!

Code is here:

  https://github.com/londonhackspace/ACNode

Remaining tasks are here:

  https://github.com/londonhackspace/ACNode/issues

All I've done is port the prototype to Flask.  The blocker at the moment the DB backend, which I'm planning to do tomorrow evening.  Happy to be beaten to it, though.

Cheers,

Mark

[Eugene Nadyrshin]

Hi Aaron,

It was great to see you last tuesday and dig out the robot arm!
Now that you have been acquainted with LHS politics (more like people
overcommitting themselves then blame-shiting) I was wondering if you
want to do the ACnode backend project together?

Solexious has an AC node prototype that's fully working with the api he
proposed. He is flexible with those requirements and said he'll welcome
improvements and changes.

Please let me know,

Cheers
Eugene/Mentar

[Jonty Wareing]

Earlier today on IRC sol/mark agreed to deploy the acnode stuff this
weekend, so I'd hold off on duplicating effort to see how that goes.

--jonty

> --

[Mark Steward]

I don't think it's a good idea to discourage people because there's a risk of duplicated effort.  This is how we're 12 months down the line on a project that should have taken a couple of weeks at most.  We shouldn't have to wait for the stars to align and the right people to meet to get something done.

I'm reminded of the last part of this:

  We reject: kings, presidents and voting.

  We believe in: rough consensus and running code.

-- David Clark, http://groups.csail.mit.edu/ana/People/DDC/future_ietf_92.pdf, p19

Mark

--

[Aaron Sokoloski]

Ok, sure.  I've been talking on IRC just now to Mark.  I'm going to see what I can do about making a db backend for his code.  He says to check here for other stuff to do: https://github.com/londonhackspace/ACNode/issues

I'm realizing how important communication is with a decentralized group of people like this!

Unfortunately, I can't get into the hackspace this week or weekend probably.  But I'll stay on IRC when I'm working on it, and I think that this thread is a good place to coordinate things.

Aaron / asoko

[Aaron Sokoloski]

Ok, I've submitted a pull request for part of the db backend.

I'm a bit worried about how it will all work with the permissions coming in from two sources (local database and json import).  It's fine if we only ever add permissions, but if we ever need to revoke them for whatever reason (even just because they were added by mistake) it becomes complicated to tell the difference between a permission that was added in just one source, and a permission that was deleted in the other source.

I suggest just ignoring the whole idea of importing anything from Turing's database for now, and just getting it working on the tool access control server in the hackspace, perhaps with a web interface for the local network only.  If we decide that maintainers on the internet at large will need to access it, I think it would be better to see if we can't give the TAC server a secure API for Turing to access, so we still only have one canonical source of data.

Cheers,

Aaron

[Russ Garrett]

On 16 January 2013 21:49, Aaron Sokoloski <asoko...@gmail.com> wrote:
> I'm a bit worried about how it will all work with the permissions coming in
> from two sources (local database and json import).

The easy way to fix this is to have the server only accept permission
grants if turing is accessible. Then the canonical source for changes
is always turing.

--
Russ Garrett
ru...@garrett.co.uk

[Peter "Sci" Turpin]

When we're dealing with embedded hardware that'll be on 24/7 and
switching a couple of kilowatts, I'd rather wait for something that's
been fully bug-tested.

> --
>
>

[Mark Steward]

I agree we need some evidence of testing before we can claim it's finished, but why is the load relevant? Surely the worst that can happen is it triggers the relay repeatedly (as might happen with a loose connection), at which point the power should be turned off.

Should there be some kind of debounce or protection on the relay?

Mark

--

[Russ Garrett]

It's also worth noting that on the 3-in-1 it will not be switching a
significant load as it's going on the interlock loop, which only
handles the coil current for the contactor.

> --
>
>



--
Russ Garrett
ru...@garrett.co.uk

[Peter "Sci" Turpin]

No the worst case is an unattended rule-zero violation.

Higher loads, more relay wear, higher chances of overheating and
catastrophic shorts.

Maybe I'm disproportionally concerned, but it is my major fear when
doing any mains power work.

On 17/01/2013 09:43, Mark Steward wrote:
> I agree we need some evidence of testing before we can claim it's
> finished, but why is the load relevant? Surely the worst that can happen
> is it triggers the relay repeatedly (as might happen with a loose
> connection), at which point the power should be turned off.
>
> Should there be some kind of debounce or protection on the relay?
>
> Mark
>
> On 16 Jan 2013 23:40, "Peter "Sci" Turpin" <s...@sci-fi-fox.com

> <mailto:s...@sci-fi-fox.com>> wrote:
>
> When we're dealing with embedded hardware that'll be on 24/7 and
> switching a couple of kilowatts, I'd rather wait for something
> that's been fully bug-tested.
>
> On 16/01/2013 18:55, Mark Steward wrote:
>
> I don't think it's a good idea to discourage people because
> there's a
> risk of duplicated effort. This is how we're 12 months down the
> line on
> a project that should have taken a couple of weeks at most. We
> shouldn't have to wait for the stars to align and the right
> people to
> meet to get something done.
>
>
> I'm reminded of the last part of this:
>
> We reject: kings, presidents and voting.
> We believe in: rough consensus and running code.
>
> -- David Clark,

> http://groups.csail.mit.edu/__ana/People/DDC/future_ietf_92.__pdf <http://groups.csail.mit.edu/ana/People/DDC/future_ietf_92.pdf>,

> p19
>
>
> Mark
>
>
> On Wed, Jan 16, 2013 at 6:45 PM, Jonty Wareing
> <jo...@jonty.co.uk <mailto:jo...@jonty.co.uk>

> --
>
>

[Ben Barwise]

Could be solved by a Solid state relay ?

--