fiware-orion

Fiware - IDAS: TimeInstant attribute

微笑、不失礼 提交于 2019-12-10 22:38:01
问题 I’m using the MQTT Ultralight agent. I have seen that when the agent registers into the context broker an entity related to a device, the agent adds to that entity the “TimeInstant” attribute. This attribute seems to be on UTC+0. I would like to work with UTC +1. I tried modifying the device’s “TimeZone” when registering it, but seems that this doesn’t work, because the time continues to be on UTC+0. Here an example: curl -X POST 172.21.0.23:8090/iot/devices \ -i \ -H "Content-Type:

Context Broker FI: Fatal Error (error starting REST interface)

主宰稳场 提交于 2019-12-10 21:06:09
问题 I have stopped a virtual machine with CentOS running an instance of Context Broker. Upon relaunching the system with the enabler, the latter gives a Fatal Error. See the below log: # contextBroker INFO@13:18:32 contextBroker.cpp[1348]: Orion Context Broker is running INFO@13:18:32 mongoGlobal.cpp[164]: Successful connection to database INFO@13:18:32 contextBroker.cpp[1157]: Connected to mongo at localhost:orion INFO@13:18:32 mongoGlobal.cpp[483]: Database Operation Successful ({ conditions

Connectivity problems between FILAB VMs and Cosmos global instance

眉间皱痕 提交于 2019-12-10 19:39:10
问题 I have the same kind of connectivity problem discussed in the question "Cygnus can not persist data on Cosmos global instance". However, I have found no solution after read it. Nowadays, I have recently deployed two virtual machines in FILAB (both VMs contain Orion ContextBroker 0.26.1 and Cygnus 0.11.0). When I try to persist data on Cosmos via Cygnus, I get the following error message (the same in both VMs) : 2015-12-17 19:03:00,221 (SinkRunner-PollingRunner-DefaultSinkProcessor) [ERROR -

Setting up PEP Proxy

余生长醉 提交于 2019-12-10 18:28:53
问题 I've been working on regards the PEP-Proxy-Steelskin so I can provide some security layer to my Orion Context, however, there are some issues that have been blocking my progress. I will like to use the IDM and Keystone Global Instances. I've successfully install the pepProxy by following respective directions (https://github.com/telefonicaid/fiware-pep-steelskin), however, the result is always the same: { "name": "KEYSTONE_AUTHENTICATION_ERROR", "message": "There was a connection error while

Subscription status change after post

最后都变了- 提交于 2019-12-10 18:16:04
问题 After successfully installed Cygnus connector and testing the creation of subscriptions. With bellow files: agent_1.conf cygnus-ngsi.sources = http-source cygnus-ngsi.sinks = hdfs-sink cygnus-ngsi.channels = hdfs-channel cygnus-ngsi.sources.http-source.type = org.apache.flume.source.http.HTTPSource cygnus-ngsi.sources.http-source.channels = hdfs-channel cygnus-ngsi.sources.http-source.port = 5050 cygnus-ngsi.sources.http-source.handler = com.telefonica.iot.cygnus.handlers.NGSIRestHandler

HTTPS notification doesn't reach cygnus

本秂侑毒 提交于 2019-12-08 05:10:01
问题 Orion version is 2.1.0 Orion is started in HTTPS using the -https option We use the "HTTPS" protocol schema in URL in our subscriptions --> reference" : "https://cygnus.domain.com/notify" When we insert an Entity matching the subscription, the Entity is created in Orion, but not in STH. However Orion Logs return: Notification Successfully Sent to https://cygnus.domain.com:443/notify If we use the "HTTP" protocol schema in URL in our subscriptions it works If we use curl to notify dirctly

How to configure the Fiware PEP WILMA proxy to use a Keyrock and Orion instance on my own servers

∥☆過路亽.° 提交于 2019-12-07 11:45:35
问题 I've spent most of the day trying to configure the Fiware PEP proxy Wilma to secure an Orion Context Broker i have running on a development server. The documentation here: http://forge.fiware.org/plugins/mediawiki/wiki/fiware/index.php/PEP_Proxy_-Wilma-_Installation_and_Administration_Guide is not clear. Here is my setup: A Fiware Keyrock instance running on server1, port 3000 A PEP Proxy running on server 1 An Orion Context Broker running on server2, port 1026 The manual states to edit the

HTTPS notification doesn't reach cygnus

為{幸葍}努か 提交于 2019-12-07 09:33:42
Orion version is 2.1.0 Orion is started in HTTPS using the -https option We use the "HTTPS" protocol schema in URL in our subscriptions --> reference" : " https://cygnus.domain.com/notify " When we insert an Entity matching the subscription, the Entity is created in Orion, but not in STH. However Orion Logs return: Notification Successfully Sent to https://cygnus.domain.com:443/notify If we use the "HTTP" protocol schema in URL in our subscriptions it works If we use curl to notify dirctly Cygnus in HTTP or HTTPS it works Orion Logs bellow: time=Friday 22 Feb 11:24:28 2019.158Z | lvl=INFO |

ContextBroker subscriptions Error

别来无恙 提交于 2019-12-06 12:00:48
问题 I've updated cygnus from version 0.13 to 1.7.0 by installing NGSI following this tutorial: https://github.com/telefonicaid/fiware-cygnus/tree/master/cygnus-ngsi Error the subscription [ { "id": "59d38a92dbaa1e477aef9c00", "description": "A subscription to get info about pruebas", "status": "failed", "subject": { "entities": [ { "id": "pruebas", "type": "pruebas" } ], "condition": { "attrs": [ "pressure" ] } }, "notification": { "timesSent": 2, "lastNotification": "2017-10-03T13:03:43.00Z",

What would be the behavior of subscriptions and notifications in an Orion Load-Balancing scenario?

我只是一个虾纸丫 提交于 2019-12-06 08:20:11
Based on this answer about how to scale Orion Context Broker with load balancing https://stackoverflow.com/a/33068119/3706998 what should be the behavior of subscriptions and also notifications? Witch server should it come from? What is the workflow? Could it cause some disturbe or cloned subscriptions ? Let's consider different cases, depending on subscription cache usage. Let's consider two Orion nodes (A and B) without loss of generality, both sharing the same MongoDB instance. Using subscription cache (i.e. -noCache is not set) The subscription creation request is dispatched to some of the