Hackathon

There is a hackathon coming up, and we are talking about building container for it. But better this time.

Issues with v2:

1. Small cubbies
2. Janky setup process
3. stupid db system
4. uses google for speech to text ( privacy nightmare )
5. Janky interaction between devices
6. slow
7. only tui, cli and voice, no webui.

Now, the hackathon only lasts 8 hours, so we can only address but so many of these problems.

I think the most important thing to do is setup a more high quality base to work with. We have to pick some more specific problems for that though:

1. make a setup script
   1. in order to do this we need to either be better at wled setup 1D style ( automate the json api stuff for creating the segments ), or switch to a wled 2D matrix.
2. use a real database instead of a series of text files which we do ast.literaleval on
3. ditch the laptop and run it all off a phone alone.
4. not using text files and therefore not needing to do the monitoring associated with that, and instead switching to a live monitoring type thing with python will likely hugely help speeds.

We are going to have to just cope with google, small cubbies, and likely wont even have a tui. We are not going to develop a webui im happy with in 8 hours along with everything else. Nor are we going to setup a selfhosted voice recognition system which can stream out output live to our phone.

We are going to try to rewrite the whole system in those 8 hours though, which might be a bit of a task. This is why i am fleshing out the idea beforehand.

Here are the things we need to setup for this to work and be useful:

1. wled on an esp32 connected to an led strip
   1. 2d matrix setup in here
   2. needs a box of some kind so its not open wires and prone to disconnecting.
      1. im thinking cardboard.
2. library containing following wled interacting functions:
   1. turn off all lights
   2. light up given coordinate with given color
   3. optional: cool animations
3. container library, interfaces with database and with wled library.
   1. add item to containers
      1. light up coordinate of location added to green
      2. put similar items together ( up to interpretation for what is considered similar ), if no similar items, put item in emptiest slot. Emptiest slot is just the one with the least items, we have no way of knowing how big an item is, or how full the slot really is.
      3. optional parameter position to add to
      4. optional “new” argument disables attempts to put similar items together, so if one drawer gets full of similar items you can addnew and it wont just try to overflow that drawer.
   2. remove item from containers
      1. light up coordinate of location removed from red
      2. optional parameter coordinate to remove from
   3. get list of items at coordinate
   4. get all items from container
   5. search for item given name segment
      1. light up drawers for found items green for exact matches
      2. light up drawers for partial matches for the search yellow
   6. optional: undo last command
      1. if added item, grab position and remove that item from that position
      2. if removed item, grab position and re add that item
      3. if searched, turn off lights
   7. items should be objects with the following attributes:
      1. coordinate
      2. name
      3. time / date added
      4. container system id
      5. wled ip for that container system
   8. argparse should be setup to allow testing of each function
4. database system
   1. look into sqlite + sqlalchemy, which would store everything in a .db file no server needed, and looks really easy for interaction in python
   2. needs to be relatively low overhead, as it is in theory gonna run on a phone
   3. needs to be relatively easy to interface with, if i learn sqlite + sqlalchemy is not easy, then we need to find another tool
   4. SHOULD NOT BE TEXT FILES THIS TIME
   5. should be able to manage multiple drawer systems, giving each one an ID
   6. optional: some way to undo should probably be built, though that really could just be make a copy of the database on each change, as it should be a tiny tiny tiny file at the scale we are doing. This would likely break after repeated undos, or divering undo trees, or whatever.
5. Voice control system
   1. android phone running termux using google or futo’s STT works for this. not enough time to do something else.
   2. should not be done over ssh this time though, should be done in python directly, capture input while also showing output from whatever is happening, directly in the script. should speed things up some.
6. Main file
   1. Accepts input live from keyboard ( which speech to text would be using ), if no input for more than three seconds parses input
      1. fixes known issue words like “esp 32” or “hd my cable”. detects them then replaces them with their accurate counterpart. All items will use in the demo will be tested to make sure their names work right.
   2. deals with structure of voice command and uses the appropriate function
      1. container add x
         1. calls add with x as argument
      2. container search x
         1. calls search with x as argument
      3. you get the picture
      4. some oddnesses though to be clear:
         1. container clear or container off
            1. turns off the lights, atleast in my current version. no parameter on this one because why would it need a parameter? script needs to be able to handle that.
         2. container manual
            1. prompts user to supply coordinates, then asks them what they want to do on those coordinates ( add, remove? ), then asks them what they want to add / remove
7. setup script
   1. ask user for the following
      1. how many leds before the first drawer in your strip?
      2. how many rows?
      3. how many columns per row?
      4. how many leds per column?
      5. how many leds to skip in zig zag sections at end of each row ?
      6. what is the ip of your wled instance
8. test suite ( if we have time ! )
   1. tests for libcontainer
      1. preferably a test for each function, 100% code coverage should be totally possible. In a perfect world we would do TDD
   2. tests for wled
      1. just do sending of updates to wled, then grab state and make sure updates propagated how expected, and do waits so a person can visually watch and make sure the right things are updated.
   3. tests for main script along with testing undo for each thing if undo is implemented