@powerhouse-solutions/node-red-contrib-twinhub 1.6.2

The official Node-RED package from Powerhouse Solutions GmbH

npm install @powerhouse-solutions/node-red-contrib-twinhub

node-red-contrib-twinhub

TwinHub Node-RED Package – The official Node-RED package from Powerhouse Solutions GmbH.

Installation

Install via npm:

1. open cmd
2. go to your Node-Red dictionary ( cd C:\Users\Username\.node-red )
3. npm install @powerhouse-solutions/node-red-contrib-twinhub

Or install directly in Node-RED:

1. Open Node-RED
2. Go to Manage Palette
3. Search for twinhub
4. Click Install

Nodes in this package

This package includes several nodes:

• db-functions → Provides CRUD operations for managing RuleBox table.
• get-bearer-token → Retrieves and caches a Bearer token for authentication.
• store-io-data → Receives IO-Box signals and writes them to the local RuleBox database.
• post-progress → Sends data and enriches IO-Box data with additional metadata from an API.
• get-new-data → Fetches unsent data, either unsent to the Cloud or to MES.
• mes-upload-data → Uploads unsent data, gathered from "get-new-data" to the MES.
• cloud-upload-data → Uploads unsent data, gathered from "get-new-data" to the Cloud.
• read-twhinhub-box → Retrieves data from old IO-boxes, does not work with W&T-boxes.
• post-energy-realtime → Sends the current power-consumtion to the cloud.
• post-progresses → Sends data taken from the global-array and updates the diff if successfull.
• get-and-fill-iodata → Recieves the current list of all workplace-stations or enriches the diff of the right workplace-station.
• get-bearer-token-config → Config-Node wich allows to create and save a configuration for the "get-bearer-token" node.

more detailed explanation of each node and its functionality can be found in German in the help section of Node-RED.

Usage

Once installed, the nodes will appear in the TwinHub category in Node-RED. Drag and drop them into your flow and configure their settings.

Powerhouse Solutions GmbH

For more information, visit Powerhouse Solutions GmbH

Confirmations V2

Ein gemeinsamer Beispielflow zeigt Einrichtung, optionale Maschinensimulation, Erfassung, Speicherung, Cloud-Upload und das Live-Dashboard mit FlowFuse Dashboard 2. Die nummerierten Kommentar-Nodes erklaeren die Einrichtung (Kommentar doppelklicken). Benoetigt: node-red-node-mysql und @flowfuse/node-red-dashboard. Dashboard 1 wird nicht benoetigt. Dashboard-Adresse: /twinhub-live/maschinen. Timer fuer Upload, Tagescheck und Cleanup erst nach der Einrichtung aktivieren.

Startzustand und Offline

Ohne aktiven Zustand behaelt SQL den Typ einer vorhandenen offenen Confirmation. Nur ohne Vorbestand beginnt sie mit Ruesten. Der SQL-unabhaengige Live-Zaehler startet ebenfalls bei Ruesten; er kennt keinen DB-Vorbestand. Nach dem Update bei gestoppter Erfassung create-MDEV2 erneut ausfuehren, damit die gespeicherte Procedure aktualisiert wird.

W&T payload = null setzt Offline, alte Eingangswerte werden verworfen und Mengen nicht gezaehlt. Nach Wiederverbindung alle konfigurierten Digital-IN-Eingaenge neu abfragen: msg.status an jeden W&T-Node schicken. Auch unveraenderte false-Werte werden gebraucht. Alle Werte muessen frisch bekannt sein und zusammen einen aktiven Zeittyp ergeben. Counter-Nachrichten alleine heben Offline nicht auf. Ohne Eingangssignale findet kein automatischer Zustandswechsel statt. Ein dem Typ Offline zugeordnetes Ausschaltsignal wird wie bisher ausgewertet.

Digital IN bekommt msg.input zur Zuordnung; sein Boolean-diff wird als 0 Huebe behandelt. Counter-Nachrichten bekommen msg.counter statt msg.input; ihr numerisches diff liefert Huebe. Nach Wiederverbindung nur die neue Differenz senden, keine erneut aufaddierten Offline-Mengen. Die Eingangs-/Verbindungsmerker nutzen den Node-Context (standardmaessig fluechtig). SQL kennt nach Neustart weiterhin die gespeicherte offene Confirmation.

Echte WuT-Eingaenge im Beispiel

Unter Kommentar 7 ist die Hardware-Alternative fuer Arbeitsplatz-1 vorbereitet. Benoetigt die Palette @wiesemann-theis/node-red-contrib-wut. Die WuT-Nodes und der Status-Inject sind zuerst deaktiviert: Web-IO auswaehlen, Klemmen/Regeln anpassen, Simulation abtrennen und dann aktivieren.

• Digital IN -> Change (msg.input, msg.diff = 0) -> confirmation-store.
• Counter -> Change (msg.counter) -> derselbe confirmation-store. WuT liefert msg.diff direkt.
• Ein Status-Inject liest alle konfigurierten Digital-IN-Werte alle 10 Sekunden ein, auch unveraenderte Werte nach Wiederverbindung.

Der Counter verwendet im Beispiel resetDiff: Der erste Wert nach Start oder Verbindungsverlust liefert keine Differenz. payload = null wird als Offline weitergegeben.

Gemeinsame Zusatzdaten und Mengenarten

confirmation-store ordnet msg.counter anhand der Counter-Regeln Good, Scrap oder Rework zu. Beispiel: 5 = Good, 8 = Scrap, 9 = Rework. Digital IN verwendet weiterhin msg.input. Jede Mengenart wird mit InputPerStroke multipliziert. Das Dashboard zeigt drei getrennte Summen sowie die Gesamtmenge seit Zaehlerstart.

Zusatzdaten: Inject -> get-bearer-token -> get-confirmation-data -> optional Function zum Umbenennen fremder Felder -> confirmation-context. Ohne eigene URL verwendet der Abruf msg.baseUrl plus /TwinHub.Module.IoTMDE/api/v2/Get_ConfirmationData (noch ein Platzhalter). Eine fremde API kann eine eigene absolute URL erhalten.

Die normalisierte Antwort ist eine Liste, z.B. [ { "WorkplaceName": "AP1", "OrderNumber": "AUF-123", "BatchNumber": "CH-1", "InputPerStroke": 2 } ]. Der Context-Node prueft die komplette Liste und ersetzt global.twinhubConfirmationData. Fehlende Arbeitsplaetze oder Felder werden entfernt, [] leert den Stand. Fehler behalten den letzten gueltigen Stand. Vor dem ersten erfolgreichen Abruf bleiben bestehende SQL-Zusatzdaten erhalten. Der Standard-Context liegt nur im Arbeitsspeicher.

Der Store liest die Daten bei seiner naechsten Eingangsnachricht; msg.confirmation wird nicht mehr verwendet. Geaenderter oder entfernter Auftrag/Charge startet auch bei gleichem Zeittyp eine neue Confirmation. Der Context-Node selbst schreibt nichts in SQL. Pro Datenbestand einen Context-Schreiber verwenden.

Umstieg: Erfassung stoppen und create-MDEV2 erneut ausfuehren: MDEV2_SaveConfirmation erwartet jetzt sieben Parameter. Bestehende Daten bleiben erhalten. Counter-Regeln und Change-Nodes konfigurieren, neue Zusatzdaten-Strecke verbinden und danach Erfassung wieder starten. Node-RED nach Installation der neuen Nodes neu starten. Der Cloud-Upload-Pfad ist nun fest; endpointV2 entfaellt.