🇳🇱 · MakerSpaceLeiden · LucasV
Nieuwe pagina aangemaakt met ' Category:Tools Category:Kitchen Tools Category:Cleaning Tools <!-- Add any additional category labels --> {{SafetyCat6}} <!-- Determine the safety category and update label above --> {{NoiseCat3}} <!-- Determine the noise category and update label above --> '''Instructions for using this template:''' Adding a new machine page is done easiest by copying the text from a similar machine and adapting it. Be sure to include a picture and cover all section…' Nieuwe pagina [[Category:Tools]][[Category:Kitchen Tools]][[Category:Cleaning Tools]] <!-- Add any additional category labels --> {{SafetyCat6}} <!-- Determine the safety category and update label above --> {{NoiseCat3}} <!-- Determine the noise category and update label above --> '''Instructions for using this template:''' Adding a new machine page is done easiest by copying the text from a similar machine and adapting it. Be sure to include a picture and cover all sections below, especially what the machine is '''not designed to do''' and material restrictions. =What is it?= ==Identification== What is it called? What is its primary use? What is it '''not designed to do'''? Where is it located? Whose property is it? What sort of material can it best handle - and what '''sort of material may damage it'''? ''Add a picture of the machine here'' De vaatwasser bevind zich in de keuken, is eigendom van MakerSpace Leiden, en is bedoeld voor het wassen van vaat. Gebruik voor het schoonmaken van allerhande ander spul de [[ultrasoonreiniger]] of een doekje. ==Status== Is it fully operational or are there any issues with it? ==Accessories== Which accessories does it have? ==Manuals== Which manuals does it have? Link to the manual if available. ==Safety documentation== Which safety documentation does it have? =Which safety precautions should I take?= ==Risk Inventory & Evaluation== Which Risk Inventory & Evaluation actions have been taken or are still pending? ==Safety Sheet== Include reference to [[Safety Sheet]] and key safety points below. ==Mandatory Instruction== Which instructions are mandatory? ==Mandatory Personal Protective Equipment== Which personal protective equipment is mandatory? ==Key Safety Points== Repeat the key risks and how to mitigate them How to avoid common hazards Practical safety checks to perform =How should I use it?= ==Preparation== What should I do before I start my job? ==Usage== How should I use it to perform my job? ==Known Issues & Surprises== What are the known issues, quirks, or surprises users should be aware of? ==Cleaning up== What should I do after I finished my job? ==Power Off Instructions== How should the machine be properly powered down? =Out of Order Procedures= What should be done when the machine needs to be taken out of service? How should it be marked as out of order? =How should I maintain it= ==Regular Maintenance== What maintenance should be done on a regular basis? ==Installation & Technical Details== Document any non-trivial installation details, wiring, setup configurations, etc. =Supply Management= ==Consumable Supplies== Which supplies need regular replacement? Where can these supplies be obtained? Who is responsible for ordering/replacing them? =What should I do when...?= ==When I find it in use== ==When I find it dirty== ==When something is broken== ==When parts are missing== ==When supplies have run out== ==When it is time for regular maintenance== =Who is involved in...= ==Ownership== ==Maintenance== ==Materials== ==Instructions== ==Maintaining this Wiki page== =Maintenance Log= ''Note: Consider keeping a separate 'setup' or 'build' page during machine installation to document the project of getting the machine up and running. Parts of this documentation can later be used as the basis for the maintenance section.''
🇳🇱 · MakerSpaceLeiden · MarkKlaauw
← Oudere versie Versie van 4 jul 2026 20:49 (13 tussenliggende versies door dezelfde gebruiker niet weergegeven) Regel 1: Regel 1: [[Category:Servers network & websites]] == MQTT Unified Namespace == At the Makerspace, MQTT is used to exchange data between the different systems in the space, ESP32 nodes on machines, Node-RED, Home Assistant, and the intranet/CRM. Any of these can publish to it, and any of them can subscribe. This page describes one particular topic structure used on that broker: the Unified Namespace. Topics here all start with <code>msl/olga/</code>. Other topic structures may exist on the broker alongside this one. For more on MQTT in general, and how to connect to the broker, see the [[MQTT|MQTT page]]. The Unified Namespace approach comes from industrial automation, where large factories faced the same underlying problem: many MQTT topics, no shared structure, and no easy way to find anything. This was addressed in the ISA-95 guidelines, which describe a hierarchy with six levels: Enterprise → Site → Area → Line → Cell → Equipment In a factory, this might look like: ''acme-corp → factory-haarlem → assembly-hall → line-3 → station-7 → welding-robot''. From the topic name alone, you can tell exactly where a piece of data comes from. For the makerspace, this maps onto: msl/olga/... <code>msl</code> stands for Makerspace Leiden, and <code>olga</code> for the Olga business complex, the building we're in. Below that, the hierarchy follows the physical layout of the space: first the area, then a category (machines, doors, lights, environment), then the specific thing. Most topics fit this model well. Some don't, the IT monitoring topics, for example, aren't tied to any physical area, so they're placed under a functional domain instead (<code>msl/olga/it/</code>). For the makerspace that maps onto: msl/olga/... <code>msl</code> for makerspace Leiden, <code>olga</code> for the Olga building. Below that, the hierarchy follows the physical layout of the space: area, then a category (machines, doors, lights, environment), then the specific machine or object. Most topics fit this model well. Some don't, the IT monitoring topics, for example, don't really belong to any physical area, so they live under a functional domain (<code>msl/olga/it/</code>) instead. == Guidelines for publishing == To keep the namespace easy to use, if you publish new topics to the unified namespace, you can follow the following guidelines. Some of these guidelines come from general MQTT practice, others from the Unified Namespace conventions. ; Payloads : Use JSON for payloads, even for simple values — for instance <code>{"value": "on"}</code> instead of just <code>on</code>. This makes it easier to add fields later without breaking anything, and easier for applications to parse. ; Topic naming : For MQTT topic names, use lowercase letters, no capitals, with no spaces, underscores, or other special characters. To seperate words you can use dashes. ; Clearing old topics : If a topic moves or gets renamed, the broker will keep showing the old message if it was published with <code>retain=true</code>. To remove such an old remaining topic, publish a message to the topic, with an empty payload, again with <code>retain=true</code>. This clears the stale retained message from the broker. ; Retained messages : For almost all messages, we want new subscribers receive the message when subscribing to the broker, instead of having to wait for the next update. So, publish with <code>retain=true</code> in almost all cases. The exception is short-lived events, like a check-in event: these are a moment in time rather than a persistent state, so use <code>retain=false</code> for them. ; Topic structure : Create new topics under the relevant area where possible. Under the area, use a category — like <code>machines</code> or <code>doors</code> — to specify further. This makes topics easy to find, and easy to subscribe to in bulk later: for example, using the single-level wildcard <code>+</code> to get the status of every machine in every area at once, <code>msl/olga/+/machines/+/status</code>. ; MQTT publisher : Since multiple applications publish into the Unified Namespace, it helps to include an <code>mqtt_publisher</code> field in the payload, naming the system the message came from. Handy when you need to troubleshoot later, and you're trying to trace where the meassage originated from: : <code>{"value": "on", "mqtt_publisher": "intranet-crm"}</code> ; Timestamp : Adding a <code>timestamp</code> field, set to the time the message was published, makes it easy to see how recent a message is — useful for telling a fresh retained value apart from a stale one. For timestamps, use local time whenever possible, to avoid confusing people who have less experience with universal time and aren't used to converting it to local time. : <code>{"value": "on", "mqtt_publisher": "intranet-crm", "timestamp": "2026-06-23T20:36:08"}</code> == Topic hierarchy example: circular table saw == Below is an example of a topic tree for one machine. Think of the topic hierarchy like a folder structure: each line is a place where a message gets published. So <code>status</code> is where you'd look to find out if the machine is on or off. msl/olga/wood-workshop/machines/circular-table-saw/ ├── info ├── status ├── user-is-logged-in ├── out-of-order ├── telemetry/ │ ├── runtime-total-seconds │ ├── runtime-today-seconds │ ├── last-start-time │ ├── last-stop-time │ ├── last-activated-time │ └── last-activated-by ├── maintenance/ │ └── servicelog └── nodes/ └── tablesaw/ ├── mac-address ├── ip-address ├── hostname ├── poe ├── last-seen ├── connected-to-mqtt ├── last-reboot ├── status ├── telemetry └── raw-mqtt
