As a lorawan user in the context of the new energy domain, I'd like to integrate the data coming from Milesight sensors in the Open Data Hub

[luhodaan]

Develop a new data collector and a transformer to integrate data from the lorawan on the new infrastructure

[luhodaan]

Deployment in testing environment done.
Ready for production!

[sseppi]

Hi @luhodaan ,

I tested the tool and, before going into production, I would suggest to do the following changes:

• change the stationtype from "internal-sensor" to "indoor-sensor" or maybe better "IndoorStation"
• publish the collected data s Open Data
• changhe the url where we get the data from the old http link to the new https one that Eurac shared with us per email.

[luhodaan]

Hi @sseppi,
all the changes have been made. Now you can also query the data as follows and see the latest measurement directly as a result from the api: https://mobility.api.opendatahub.testingmachine.eu/v2/flat%2Cnode/internal-sensors/*/latest?limit=200&offset=0&shownull=false&distinct=true&timezone=UTC

[sseppi]

Hi @luhodaan ,

I tested the calla and I have seen that it seems that the import is blockes from yesterday morning.

As example the call below answers with the data of the NOI-A1-Floor1-CO2 sensor with the data of yesterday at 9:34 am.

https://mobility.api.opendatahub.testingmachine.eu/v2/flat%2Cnode/IndoorStation/*/latest?limit=1&&offset=0&where=sname.eq.NOI:NOI-A1-Floor1-CO2&shownull=false&distinct=true&timezone=UTC

Can you please chack if the sync with the LoRa portal is working fine?

Moreover is there a way to get all measurement of the sensor with one single latestcall or do I need to do a separated call for each data type?

[luhodaan]

Hi @sseppi, I've checked and the sinc with the LoRa is fine, since the data is correctly imported in the Mongo. So it is not a data collector problem but probably a transformer issue.
I've also noticed that the data is not correctly being imported in the mobility api from the mongo, so I'll investigate how to fix it, I think it is probably the same reason for the second question your asking, since it is due to the same importing problem, otherwise it should retrieve all data types for each sensor.

[sseppi]

@luhodaan super! Many thanks for checking.

I will wait for you to fix the bug, before finalizing the integration in the testing energy tool.

[luhodaan]

@sseppi now the data is being correctly imported, you can check the endpoints.
Regarding this question Moreover is there a way to get all measurement of the sensor with one single latest call or do I need to do a separated call for each data type? , with latest we get the last data type written to the API.
At the moment if you want to get all the latest data types for each station you would need to set the limit parameter to the exact number of data types we have, which for example should be 4 for IndoorStations with CO2 in the name at the moment.

https://mobility.api.opendatahub.testingmachine.eu/v2/flat%2Cnode/IndoorStation/*/latest?limit=4&&offset=0&where=sname.eq.NOI:NOI-A1-Floor1-CO2&shownull=false&distinct=true&timezone=UTC

This is due on the current implementation of transformers, which involves pushing each new data type as a single record, followed by all the other data types for each station.

Let me know if you need further clarification or if you think we should adjust things further.

[sseppi]

@luhodaan super, now everything seems to work fine! I integrated it in the Energy Tool:

https://energy-tools.opendatahub.testingmachine.eu/

To solve the problem of getting the right values, I added the filter on the "tname" value. Did I got the right value?

I hat a problem with the time that was 1 hour back. To solve the problem, I put the parameter timezone=+1 instead of the default timezone=UTC. Is it the right way to go?

I share here below an example of call I did, so you can easily check if I made the right call:

https://mobility.api.opendatahub.testingmachine.eu/v2/flat%2Cnode/IndoorStation/*/latest?limit=1&&offset=0&where=and(sname.eq.NOI:NOI-A1-Floor1-CO2,tname.eq.air-temperature)&shownull=false&distinct=true&timezone=+1

[luhodaan]

@sseppi Great Job!
A couple of hints though, I would write the API call this other way, which is equivalent but it filters not with the sql AND condition (which is a bit slower in the end since it has to be evaluated), but directly filtering on the data type parameter space. There was also a typo where && is present, which is like passing a null parameter to the call. It is not directly a problem but it is not a good practice either.
Timezone was perfect instead, well done.
https://mobility.api.opendatahub.testingmachine.eu/v2/flat%2Cnode/IndoorStation/air-temperature/latest?limit=1&offset=0&where=sname.eq.NOI:NOI-A1-Floor1-CO2&shownull=false&distinct=true&timezone=+1