This page last changed on Sep 30, 2012 by cavadino.

Hi all,

first, I like your stuff. There are a few things that can be optimized.

Why donĀ“t you use an issue tracker? Especially when user base grows, you will need this. As a user it gives me the chance to see if an issue was already reported.

I see points in optimizing the sensor stuff.
I would expect to have the following objects

  • Command -> execute something
  • Sensor Writer -> executes one Reader Command to retrieve one string. Might split this string into multiple key value pairs to fill the state cache. It should contain properties that are currently part of some commands like (PollingInterval, Regexp, RegexpGroups). It should maintain its values in the state cache. This would also allow lazy polling (only poll when state cache is read), dynamic polling frequency and a common value treatment for all commands.
  • Sensor Reader -> should connect a GUI element to the state cache.

I would like to hear your feedback.

Kind regards,

Sebastian

http://jira.openremote.org

I'm not understanding your ideas wrt sensors, please expand.

Posted by juha at Oct 01, 2012 11:10

Hi Juha,

thanks for the link to Jira.

When a user creates a command, it is either used as a "read command" (sensor) or "write command" (button, action). Nevertheless, it is the same entity type and therefore share the same implementation. From the user point of view, many parameters are only needed for "read commands", e.g. PollingInterval, Regexp, RegexpGroups. I would expect to configure this on sensor level, not on command level.

When this is solved via interfaces, it might clean up some code and make protocol implementation easier.
e.g.

MyProtocolCommand: IRegexpParseAnswer, IPollingCommand.
For the implementation, you could use Dependency injection, so additional code for protocols can be minimized.

I just start playing and see a lot of improvement possibilities like:

  • add parameters to devices that can be dynamically reused in corresponding commands similar to the $
    Unknown macro: {param}
    feature
  • add the possibility to store multiple values with one command call. (Weather API returning temp, humidity, forecast per call)
  • not only export, but also import your files to the designer.
  • retrieve sensor values via REST call
    ....

Maybe I can provide an example implementation for the Sensor/command thing. I am not that java specialist.
Currently, I can compile the controller using ant in eclipse, but do not know right now how to debug it. Would be nice if somebody could provide some hints how to set up the IDE.

What is the right medium to discuss this ideas? Is there a developer mailing list or should I use this forum, or direct to jira?

Kind regards,

Sebastian

Posted by cavadino at Oct 01, 2012 20:15

When a user creates a command, it is either used as a "read command" (sensor) or "write command" (button, action). Nevertheless, it is the same entity type and therefore share the same implementation. From the user point of view, many parameters are only needed for "read commands", e.g. PollingInterval, Regexp, RegexpGroups. I would expect to configure this on sensor level, not on command level.

Correct. The reason we haven't made the change yet is because it requires updates to object model and XML schemas. So next time we break the compatibility, these will change. But given it is an incompatible change, it needs to be accompanied with migration tools so that requires some extra effort on top of the actual change.

There may be other ways to address this to improve the user experience while maintaining compatibility, but haven't finished an implementation to experiment with this yet.

add parameters to devices that can be dynamically reused in corresponding commands similar to the ${param}

Makes sense. The current schema does include device attributes and these are currently unused so this addition is plausible without schema compatibility issues.

add the possibility to store multiple values with one command call.

This may already be doable with rules (which process the return values) although I haven't written a test case for it yet. I probably should, when I get around to it.

not only export, but also import your files to the designer.

Yes, MODELER-390

retrieve sensor values via REST call

I do believe many users are already doing this with existing tools...

Posted by juha at Oct 08, 2012 00:58
Document generated by Confluence on Jun 05, 2016 09:30