2017-03-28 1 views
0

J'essaie d'envoyer une commande de mise à jour du micrologiciel DM à partir d'un flux NodeRed.Comment envoyer une demande de gestion de périphérique à l'aide de NodeRed ou de n'importe quel client REST

noeud Fonction:

msg.payload = {"MgmtInitiationRequest": { 
"action":"firmware/update", 
"devices": [{ 
"typeId": "myType", 
"deviceId": "myDevice" 
}] 

}} 
msg.headers={"Content-Type":"application/json"} 
return msg; 

je l'envoie à un noeud de requête HTTP POST avec un à

https://orgid.internetofthings.ibmcloud.com/api/v0002/mgmt/requests 

l'authentification de base avec les touches api. Je l'a basé des Initiate a device management request

Je reviens un que les documents ont comme:

Un ou plusieurs des dispositifs ne prend pas en charge l'action demandée

Tout le monde voir ce que je Je suis manquant? Il fonctionne très bien depuis l'interface utilisateur de la plateforme IoT vers le même type de périphérique/périphérique.

EDIT: Même 403 si j'utilise un client de repos comme Postman.

+0

AFAIK votre flux NR devra être connecté comme une application pour envoyer une commande dm - Est-ce le cas? – barny

+0

@barny Oui, il utilise les touches api et devrait donc se connecter en tant qu'application. – amadain

+0

Les docs affichent le paramètre appelé deviceManagementInitiationRequest plutôt que MgmtInitiationRequest - une raison pour ne pas utiliser le nom affiché par les docs? Est-ce qu'une action "device/reboot" fonctionne? – barny

Répondre

1

La documentation de l'API swagger est un peu trompeuse en ce sens que le paramètre 'body' reçoit un nom. Mais, comme les autres API POST, ce nom n'est inclus nulle part dans la charge utile.

La charge utile devrait juste ressembler à ceci:

{ 
    "action": "firmware/update", 
    "devices": [ 
     { 
      "typeId": "string", 
      "deviceId": "string" 
     } 
    ] 
} 

Cette page dans la documentation fournit plus de détails: https://console.ng.bluemix.net/docs/services/IoT/devices/device_mgmt/requests.html#firmware-actions-update

+0

Je l'avais essayé aussi, essayé à nouveau. Mais je reçois toujours 403. Généré de nouvelles clés api, juste au cas où ... Savez-vous si l'application standard est ok pour eux ou ai-je besoin d'autre chose? – amadain

+0

Avez-vous déjà une demande de mise à jour du micrologiciel en cours pour le périphérique spécifié? Une seule mise à jour du micrologiciel en cours est autorisée à la fois pour un périphérique particulier. En outre, pouvez-vous vérifier avec cette demande que votre appareil revendique la prise en charge des actions du microprogramme? GET/api/v0002/périphérique/types/monType/devices/myDevice/mgmt –

+0

Non, ils sont terminés. Je reçois ce retour pour l'EEG: { "supports": { "deviceActions": true, "firmwareActions": true }, "dormants": false, "firmware": { "version": " », "name": "", "vérificateur" : "", "état": "0", "updateStatus": "0" }} – amadain

1

Votre appareil a-t-il publié l'ensemble des commandes prises en charge qu'il prend en charge lorsqu'il s'est annoncé en tant que périphérique géré?

Un appareil se connecte à la plate-forme Watson IdO et utilise l'opération de périphériques gérés par pour devenir un périphérique géré.

Ce qui ressemble à ceci

Sujet: iotdevice-1/mgmt/gérer

{... "supports": { "deviceActions": true, "firmwareActions" : Boolean }, ... }, ...}

https://console.ng.bluemix.net/docs/services/IoT/devices/device_mgmt/index.html

+0

Je crois que oui, et que je l'ai fait correctement parce que si je vais dans la plate-forme IoT et Initiate Action, les actions de téléchargement/mise à jour du firmware fonctionnent. Je soupçonne que je ne comprends pas correctement ce doc de swagger pour le faire comme un appel de REST. Je continue à le modifier mais pas encore de joie. Moins de poils sur la tête. – amadain