DEVICE_GROUP_NOT_FOUND when I provision service group #320
Comments
|
Appart from the [MONGO-ALARM] message you get in the logs, is the IOTA working as expected? Or something else is not working? |
|
Well, yes, I think that implies a problem with the next steps from the tutorial. After steps described above, I make publish to Mosquito: I receive this logs: Then, I make a query to Context Broker to obtain entity with actualizated context from IoT Agent:
Despite what is said in the tutorial, I don't get actualizated count value. Recieved JSON: Logs: |
|
Unfortunatelly it is not evident to me the cause of the problem looking to your report... sorry. I'm CCinig @dcalvoalonso (another IOTA developer) and @jason-fox (author of the tutorial you cite) in the hope they can provide more useful feedback. |
|
I have checked the problem and I think that there are several issues with https://github.com/Fiware/tutorials.IoT-over-MQTT:
If you try to do the configuration provisioning with: curl -iX POST 'http://localhost:4041/iot/services' -H 'Content-Type: application/json' -H 'fiware-service: openiot' -H 'fiware-servicepath: /' -d '{
"services": [
{
"apikey": "4jggokgpepnvsb2uv4s40d59ov",
"cbroker": "http://orion:1026",
"entity_type": "Thing",
"resource": "/iot/d"
}
]
}'And the device provisioning with: curl -iX POST \
'http://localhost:4041/iot/devices' \
-H 'Content-Type: application/json' \
-H 'fiware-service: openiot' \
-H 'fiware-servicepath: /' \
-d '{
"devices": [
{
"device_id": "motion001",
"entity_name": "urn:ngsi-ld:Motion:001",
"entity_type": "Thing",
"protocol": "PDI-IoTA-UltraLight",
"transport": "MQTT",
"timezone": "Europe/Berlin",
"attributes": [
{ "object_id": "c", "name": "count", "type": "Integer" }
],
"static_attributes": [
{ "name":"refStore", "type": "Relationship", "value": "urn:ngsi-ld:Store:001"}
]
}
]
}
'It should work. Please note also that in order to call to the CB you should do: curl -X GET 'http://localhost:1026/v2/entities/urn:ngsi-ld:Motion:001?type=Thing' -H 'fiware-service: openiot' -H 'fiware-servicepath: /'Please confirm that it works properly and we can open a PR to https://github.com/Fiware/tutorials.IoT-over-MQTT. |
|
@dcalvoalonso I agree with your analysis that altering the request to include: should work as a simple workaround. However I'm not sure if the proper fix to this is a change to the tutorial or to the source code of Ultralight. in the previous release 1.7 if an MQTT measure arrived , when the flow of the code looked for a service group resource was ignored. Therefore the tutorial (setting the resource to blank) was fine when run against 1.7. The behaviour of the iot agent has changed for current release .1.8 and I can't see where the change has been documented, so maybe this is unexpected behaviour. Either way it is fair to say that the current tutorial doesn't work with the current IoT Agent and one of them (or both) needs to be fixed. I thought that setting the resource attribute only makes sense for HTTP requests, where resource is part of the URL, for an MQTT . request the topic won't contain a resource, so it would make sense to provision a device without a If you do a search for defaultResource you'll find that it generally relates to Does the current setting in the Regarding anonymous |
I agree with this analysis @jason-fox. @fgalan @AlvaroVega what do you think?? |
|
@fgalan Have you had the chance to take a look at this issue? |
|
It's in my TODO list :) I hope to being able of providing a comment soon... |
|
Great, no problem at all! ;) |
|
OK, I confirm that this workaround of @dcalvoalonso works fine from perspective of this tutorial issue :). Actually, I have a plan to use FIWARE with IoT Agent in the near future, so that would be a great help to have right documentation (and preferably the tutorial) compatible with current version. I am looking forward to that :). |
|
In theory, resource works as follows, with two usages:
The tutorial scenario doesn't uses IOTAManager, so usage 1 doesn't apply in this case. However, regarding usage 2, probably you need to specify the resource (although, as I mention above, current implementation doesn't has the flexbility to use it properly as endpoint). I may be wrong. If somebody has additional fact to support/ammend my argument, please tell. |
|
Regarding the change of behaviour between IOTA-UL 1.7 and 1.8 (both in agent an in the library) I have a look but I has been unable to find any change related to this. Thus, I'm unable to explain why the tutorial was working with before with "" and now it needs "/iot/d". These are the links, if somebody wants to have a try: |
|
Tracking down the MQTT issue, the problem lies within the if (apiKey === config.getConfig().defaultKey) {
/// etc
} else {
async.waterfall(
[
apply(iotAgentLib.getConfiguration, config.getConfig().iota.defaultResource, apiKey),
apply(findOrCreate, deviceId, transport),
mergeDeviceWithConfiguration
],
callback
);
}The defaultKey in the Config is When an appropriate MQTT topic is posted, the https://github.com/telefonicaid/iotagent-ul/blob/master/lib/iotaUtils.js#L189 A fix to previous functionality would be to only set This also explains why the proposed "fix/workaround" on the library works - blank I can also "fix/workaround" the tutorial by using the default key as found in the Ultralight default config: config.defaultKey = 'TEF';However So this can be fixed in several ways:
Of these:
How would you like me to proceed with this? |
…1.7.0 Only set default resource if using the HTTP Transport. Use blank otherwise.
|
I was reviewing old issues and I found this one opened :)
As far as I understand, telefonicaid/iotagent-node-lib#773 (merged in October) implemented solution 1. Thus, can this issue be closed? Or is something pending? @jason-fox what do you think? |
|
@fgalan - That is also my understanding. The relevant MQTT tutorial has already been updated to reflect this. |
|
Thanks for the feedback! Closing If somebody has another opinion and think there is something pending, please tell so (the issue can be reopened if needed or creating a new fresh one with the pending parts) |
What can be the reason that I receive DEVICE_GROUP_NOT_FOUND when I provision a service group?
I am going through the tutorial and my setup is the same as in https://github.com/Fiware/tutorials.IoT-over-MQTT (I cloned repository and then
./services create./services start).When I look at IoT Agent logs (
docker logs <iot_agent> --follow):http://localhost:4041/iot/servicesthis service is found as below:Logs:
The text was updated successfully, but these errors were encountered: