MQTT support in AS-P - Questions

[PaulBates]

Please can we have your thoughts on the following questions related to MQTT

1. Can you rank the importance of the following

1. Standard MQTT
2. Google Cloud IoT Core
3. Azure IoT Hub
4. AWS IoT Core

1. The object model we have created is based on

IoTInterface - MQTT Agent – DataGroup

The IoTInterface is just an entry point like the BACnet interface

In the Interface you can then create one of the four agents above

The Agent in turn can contain one or more data groups where the data group holds the points to be published.

My question is about how to best define MQTT topic names and I can see 4 different alternatives

1. According to point object in EBO e.g. 'MyHouse/MyRoom/Temp/Value'
2. According to name of data group e.g. 'DataGroup/Temp/Value'
3. According to unique user defined topic for the data group e.g. 'MyTopic/Temp/Value'
4. According to a unique user defined topic for each published point

Do you see a need for all of them? Do you see other alternatives?

For b) and c) there is risk that the topic names will not be unique for example if you publish two room temperatures from different room. I guess we then have to mangle the topic names to make them unique.

[Erwin-vd-Zwart]

Hi Paul,

1) My preferred rank would be 3,1,4,2 (up to now IoT HUB is most requested)

2) I think B) Datagroup is most flexible, and yes there is a risk in the unique names, but the flexibility is a must if you ask me.

As i see this now it seems we are only doing publishing, are we also adding subscriptions to a broker?

BR,

Erwin 

[MarkJ]

Paul,

My order of preference would be 3, 4 ,1, 2.

If we are to publish from both the ES and AS-P's, having the datagroup default to something with a unique element (i.e. datagroupname_57362) would prevent duplication between servers out of the box.

If using the object name then I expect EBO will prevent duplication at that level.

datagroupname_xxxxx/objectname/value

It would be nice to see each object have a property where the topic could be freely constructed and override the default scheme, ideally we would be able to mass edit in spreadsheet view too.

[AndreasMeier]

Hi Paul,

We just recently came across two opportunities. First to require option 2 and the second to require option 1 so currently the priority from my point of view would be 2,1, x, x.

In regards to the topic I was thinking of:

DataGoup/EBO-Folder-Struxure/Value

where the DataGroup Name could be the Name of the DataGoup in EBO added with the controller BACnet Device ID, or if no BACnet Interface is available, the controller serial number to avoid duplicates.

I agree with MarkJ that subcriptions would be highly welcome as this is a requirement in both projects opportunities here as well.

And finally to be honest, I have just started reading myself into the MQTT as other topics had a higher prio so far, so please if I might have mixed some.

/BR,

Andreas

[Lloyd18]

Hi Paul,

Based on the requirements of the region so far I would rate the importance as 3, 2, 1, 4.

With regards to topic naming, I would say that it could be according to the EBO object name as a default. But with the option of modifying it if required.

[Evren]

Q1: Rank the importance of the following

1. Standard MQTT (Comrequirements for the specifications)
2. Azure IoT Hub 
3. AWS & Google Cloud

Q2: The object model we have created is based on

The information shall be able to provide (as an alternative to the proposed)

• Site
• System
• Equipment
• ZoneID (Location)
• Point

The system could be Mechanical, Lighting, Vertical Transport, Power, Fire, etc…

Equipment could be AHU, VAV, LIFT, MTR etc….

Zone Id: Rm465, Zn465, etc…

Site_System_Equipment_Level_ZoneID_Point

i.e. AU_ME_AHU01_L04_Rm465_Temp_Sensor

Site_Equipment_ZoneID_Point

 i.e AU_AHU01_Rm465_SatTmp_Temp_Setpoint

There is an advantage of having the same “point” name and this will be differentiated by the location and equipment hierarchy.

The below is a typical query that can be run to identify out of range room temp so there is a use-case for keeping the point names the same.

Zones = GetAllZones()
For each zoneid in Zones:
CalculateRogueZone(zoneid)
CalculateRogueZone(zoneid):
Temp_Sensor = getZoneSensor(zoneid, “zone temp sensor”)
Temp_Setpoint = getZoneSetpoint(zoneid, “zone temp setpoint”)
if Temp_Sensort - Temp_Setpoint > threshold for all timesteps:
return True