Lighting Automation/Control Software

nh-lighting

nh-lighting is the backend control software that runs the lighting in the space.

It's written in Swift and running in docker on queen.
It provides a web socket based protocol to interact with the lights in the space.
This helps by handling the conversion of request for a light in a room to actually output channel on a controller.
It allows us to define the light and also light patterns in the database and map these to input and output channels

The websocket is available on ws://queen:8181/lighting (subprotocol 'lighting')
Details of the JSON used over the websocket can be found https://github.com/NottingHack/instrumentation-lighting/blob/main/JSON%20Examples.md

http://queen:8181
Is a quick test and web socket example page

http://queen:8181/pattern.html
Is another test page but also can be use to generate the sql needed to build new patterns

Old Plans

Below is out of date and left for history only

Command structure

This is based around posible commands we want to issue.
There is a total of 11 rooms and 17 zones.
The Workshop, Stuido, and Comfy Area have multiple zones.
There will be times when we want to change all zones in these rooms, also time when we might want to act on multiple rooms.
An 'All Off' button for the workshop should include the electronics bench, an 'All off' for the Stuido should include the Comfy Area?
Master all off from the last man switch should be all but the hall

Switch panels should not care about current state and should just send 'toggle' state commands per zone, except for posible all off/on buttons
Special function scripts form holly may want to set certain states, these will not matter about current state but would be setiing a defined on/off.
Control box firmware will be responsible for sending out retained STATE messages after it has switched any zone, 0 (all) zones may/may-not have state,
The two big switch panels are using state to change LED's and any script on Holly can you state's as needed
By using retained state MQTT messages any new client or reconnecting client subscribing to nh/li/sate/# will be feed the state of all current zone's

Internally the control box firmware will have to track state of each zone it's in charge of.

MQTT Commands

Based around the following MQTT topic structure

Topic	Description	Notes
nh/li/set/ROOM/ZONE	Lighting Command	ROOM(lowercase) is one of the pre defined rooms ZONE within a ROOM and payload is COMMAND(uppercase)
nh/li/state/ROOM/ZONE	Lighting State	Retained Topic! ROOM(lowercase) is one of the pre defined rooms ZONE within a ROOM and payload is Curent STATE(uppercase)

Set commands

• ON
• OFF
• TOGGLE

State Repplies

• ON
• OFF

Rooms And zones
if no zone listed use 1

• all/0
  • both controllers will respond to this, however hall/1 doesn't not as that will be based on the door contacts

Controller 1

• Workshop
  • 0 (all)
  • 1 (wood working)
  • 2 (Cnc's)
  • 3 (metal working
  • 4 (bike)
• Electronics
• Textiles
• Toilets

Controller 2

• Kitchen
• Blue
• Storage
• Box
• Hall
• Studio
  • 0 (all)
  • 1 (walk way)
  • 2 (middle)
  • 3 (far side)
• Comfy
  • 0 (all)
  • 1 (walk way)
  • 2 (seating)

LLAP Protocol

MattrixMQTT automatically converts all LLAP messages in the Hackspace to MQTT
To keep thing simple we use the LLAP Button firmware as detailed Here
As we are just looking for basic push button we can use TYP0 mode, this sends ayyBUTTONA-- or ayyBUTTONB-- on a debounced button press
MatrixMQTT needs updating to ACK messages so we don't get 5 at once, or adjust LLAP retires to 0.

Each XRF can be given its own two char DEVID, here is a map table of DEVID/button to zone's

DEVID	Button	Room/zone
L1	A	Textiles/1
L1	B	Not used
L2	A	Toilet/1
L2	B	Kitchen/1
L3	A	Blue/1
L3	B	Not Used
L4	A	Storage/1
L4	B	Box/1

Controller Firmware

Base on the above information the controller firmware for both the studio and workshop was built, this can not be found on here on GitHub

Base around the MQTT Template code used for hackspace instrumentation this firmware subscribes to the set topic (nh/li/set/#) and incoming LLAP topic (nh/xrf/rx/#)
Both topic are wildcard subscription and so on receiving a message the firmware check if it is for a zone under its control, then check the payload to see which command was issued, this is then used to update the shift registers and the new state of the zone is published back to MQTT.