FIWARE Orion:订阅的服务路径
FIWARE Orion: servicePath of a subscription
我正在尝试创建订阅以通知我一些传感器值的变化。
curl broker.waziup.io/v2/subscriptions -s -S --header 'Content-Type: application/json' --header 'Accept: application/json' --header 'Fiware-Service:watersense' --header 'Fiware-ServicePath:/#' -d @- <<EOF
{
"description": "Send XXX when YYY",
"subject": {
"entities": [
{
"id": "WS_UPPA_Sensor2",
"type": "SensingDevice"
}
],
"condition": {
"attrs": [
"SM1"
],
"expression": {
"q": "SM1>400"
}
}
},
"notification": {
"httpCustom": {
"url": "https://api.plivo.com/v1/Account/MAMDA5ZDJIMDM1NZVMZD/Message/",
"headers": {
"Content-type": "application/json",
"Authorization": "Basic XXX"
},
"method": "POST",
"payload": "{ %22src%22: %2200393806412092%22, %22dst%22: %2200393806412093%22, %22text%22: %22WaterSense: Field is too dry. ${id} humidity value is ${SM1} %22}"
},
"attrs": [
"SM1"
]
},
"expires": "2040-05-24T20:00:00.000Z",
"throttling": 1
}
EOF
第一个问题,ServicePath在订阅中有什么用?
它似乎在检索与该订阅相关的实体时使用。所以 /#
是有效的。它是否正确(我没有在文档中找到它)?
其次,假设您想根据多个实体属性的值创建订阅。如果这些实体属性具有相同的名称(通常是这种情况),您如何引用它们?你能做类似的事情吗:
"q": "Sensor1.SM1>100, Sensor2.SM1>100"
有效负载有类似的东西吗?
关于第一个问题,使用Fiware-Service: /#
意味着订阅涵盖任何服务路径中的实体。换句话说,任何实体(无论其在服务中的服务路径如何)都可能触发订阅(当然,只要其他条件,例如实体 id/type、属性、过滤器等匹配)。
关于第二个问题,考虑到给定的订阅是由 单个 实体的更新触发的。换句话说,Orion 收到给定实体的更新,如果它符合订阅条件,则触发订阅并发送包含该实体的通知。因此,q
过滤器始终指向正在更新的实体(并且在某些情况下,如果满足 q
过滤器和其他条件,则会收到通知)。
subject.entities
字段的作用是定义订阅所指的实体子集。例如,您可以使用 { "idPattern": ".*", "type": "TempMeter" }
来引用类型为 TempMeter
的所有实体。但是,如果 Orion 获得类型为 TempMeter
的实体 ID Meter1
的更新,则 q
过滤器仅引用该实体。
关于 "pack" 多个实体更新合而为一的操作(例如 POST /v2/update
),它们被分解为多个单个实体更新,上述规则适用。
异常: 在创建订阅时发送的初始通知将包括 subject.entities
涵盖的所有实体。然而,这是一个非常特殊的情况(更接近同步查询操作而不是常规订阅行为)所以它不是很有意义。在这种情况下,q
过滤器添加到 subjects.entities
涵盖的集合中,以便 select 哪些实体将包含在初始通知中。
我正在尝试创建订阅以通知我一些传感器值的变化。
curl broker.waziup.io/v2/subscriptions -s -S --header 'Content-Type: application/json' --header 'Accept: application/json' --header 'Fiware-Service:watersense' --header 'Fiware-ServicePath:/#' -d @- <<EOF
{
"description": "Send XXX when YYY",
"subject": {
"entities": [
{
"id": "WS_UPPA_Sensor2",
"type": "SensingDevice"
}
],
"condition": {
"attrs": [
"SM1"
],
"expression": {
"q": "SM1>400"
}
}
},
"notification": {
"httpCustom": {
"url": "https://api.plivo.com/v1/Account/MAMDA5ZDJIMDM1NZVMZD/Message/",
"headers": {
"Content-type": "application/json",
"Authorization": "Basic XXX"
},
"method": "POST",
"payload": "{ %22src%22: %2200393806412092%22, %22dst%22: %2200393806412093%22, %22text%22: %22WaterSense: Field is too dry. ${id} humidity value is ${SM1} %22}"
},
"attrs": [
"SM1"
]
},
"expires": "2040-05-24T20:00:00.000Z",
"throttling": 1
}
EOF
第一个问题,ServicePath在订阅中有什么用?
它似乎在检索与该订阅相关的实体时使用。所以 /#
是有效的。它是否正确(我没有在文档中找到它)?
其次,假设您想根据多个实体属性的值创建订阅。如果这些实体属性具有相同的名称(通常是这种情况),您如何引用它们?你能做类似的事情吗:
"q": "Sensor1.SM1>100, Sensor2.SM1>100"
有效负载有类似的东西吗?
关于第一个问题,使用Fiware-Service: /#
意味着订阅涵盖任何服务路径中的实体。换句话说,任何实体(无论其在服务中的服务路径如何)都可能触发订阅(当然,只要其他条件,例如实体 id/type、属性、过滤器等匹配)。
关于第二个问题,考虑到给定的订阅是由 单个 实体的更新触发的。换句话说,Orion 收到给定实体的更新,如果它符合订阅条件,则触发订阅并发送包含该实体的通知。因此,q
过滤器始终指向正在更新的实体(并且在某些情况下,如果满足 q
过滤器和其他条件,则会收到通知)。
subject.entities
字段的作用是定义订阅所指的实体子集。例如,您可以使用 { "idPattern": ".*", "type": "TempMeter" }
来引用类型为 TempMeter
的所有实体。但是,如果 Orion 获得类型为 TempMeter
的实体 ID Meter1
的更新,则 q
过滤器仅引用该实体。
关于 "pack" 多个实体更新合而为一的操作(例如 POST /v2/update
),它们被分解为多个单个实体更新,上述规则适用。
异常: 在创建订阅时发送的初始通知将包括 subject.entities
涵盖的所有实体。然而,这是一个非常特殊的情况(更接近同步查询操作而不是常规订阅行为)所以它不是很有意义。在这种情况下,q
过滤器添加到 subjects.entities
涵盖的集合中,以便 select 哪些实体将包含在初始通知中。