About add Actuator model

[zebrainncu]

How to do if I want to add a model actuator like things?

Thanks

[hylkevds]

The current version of the SensorThings API (OGC SensorThings API Part 1: Sensing) does not deal with actuators yet. That will be in the second Part. As a result, our SensorThingsServer also does not have specific actuator functionality yet.

One option is to define a "setpoint sensor" and datastream, have the actuator keep track of the last value in that datastream, and act accordingly.

[zebrainncu]

I appreciate for your instant reply. Can I do something in pathParser.jjt and queryParser.jjt to generate function for actuator ?

[mjacoby]

The SensorThingsAPI has a static data model. Therefore, custom extensions (e.g. classes) like you want to add are not foreseen in this implementation. Nevertheless, it is possible to add support for additional classes like an Actuator class but this will require multiple changes through different modules of the code. Extending the parser files (like you suggested) is just one of multiple steps you have to take.

As these changes are to complex to give you a simple tutorial, I would suggest you to have a look at the model classes (e.g. Sensor) and check where they are used to find out all the things you need to extend to make this work.

[zebrainncu]

Thanks a lot. I got it.

[hylkevds]

If you want to add actuator support, and you have a data model, you would need to look at the following places:

• pathParser.jjt: This file determines which paths are valid in the url. Here you need to add several things:
  • the names of the collections (C), entities (E), entity properties (EP_)
  • for each of these new elements, you have to add how they are used.
• queryParser.jjt: Here you have to add any new functions you define. You probably don't need to change anything here
• de.fraunhofer.iosb.ilt.sta.model.*: Here you have to add your new entities, and modify any existing entities that reference your new entities.
• EntityParser.java / EntityFormatter.java: Here you have to add serialisation and deserialisation support for your new entities.
• tables.xml: Here you have to add the definitions for the database tables to store any new entities.
• de.fraunhofer.iosb.ilt.sta.persistence.postgres: Support for storing the entities into the database and querying entities.

I probably forgot some things, but like mjacoby wrote, have a look at where for instance Sensor.java and QSensors.java are used and it should give you an idea.

[zebrainncu]

It is a big help for me. Thanks!

[zebrainncu]

I treated the Actuator as a Sensor. I try to add the Actuator module which will connect to Thing module. Now I see QThings something in PostgresPersistenceManager.java How to do to get the QActuators.java?

[hylkevds]

The Q* classes are generated by QueryDSL from the build-database. The build-database is generated by Liquibase. The Liquibase change definitions are in tables.xml

It's a bit of a round-abound way, but on one hand it allows for clean database updating, and on the other it gives us database-abstractions that should allow for the easy implementation of other database backends.

By the way, what actuator model are you implementing?

[zebrainncu]

Thanks a lot. It's Smart air conditioner.

[hylkevds]

Ok, but I mean, how does your data model look? Are you using one of the proposed data models for the second part of the SensorThings API?

[hylkevds]

That's really cool! I'll mention it at the OGC Meeting in Delft next week.

[zebrainncu]

I already add createTable for QActuators in tables.xml and add Actuators as well as actuator in pom.xml of SensorThingsServer.SQL and then build the project,but I can't see Q*classes. What else need to do?

Thanks!

[hylkevds]

You might need to do a clean & build, to ensure the build system re-creates the database: mvn clean install That should cause it to remove the build database, re-create the build database and generate the Q* classes from that.

[zebrainncu]

Yes. I saw it. Thanks a lot.