integration with freedomotic framework

[Mauro Cicolella]

Hi all,

I'm Mauro Cicolella. First of all congrats for your project and sorry in advance for my English. Hope to be clear.

I'm a member of Freedomotic developers team. Freedomotic is an open source IoT framework written in Java.

I'd like to create an integration (a plugin) between your system and FD.

I contacted Riccardo and he suggested to join this mailing and share with you my questions/ideas.

I'm studying Jemma documentation but I would ask one thing: there is no concept of "object" but only one of the functions associated with, or am I wrong?

For example is there the function "Oven" but not an object "oven"?

I ask this because in our framework we have objects with behaviors  (for example, a light has the properties = powered on / off and dimmer =% value) and to interact with your system we need to map your devices with our objects.

Now I'm using your "simulated devices" (web API) so I need to understand what class of object is related to a specific device when I retrieve the list by API. Also is there a unique ID for it?

I think it's all for now. We can discuss about this.

Thanks for your attention and if you need more info about Freedomotic please visit www.freedomotic.com

Regards

Mauro Cicolella

PD: we need contributors for many tasks not only developers so if anyone wants to contribute in anyway he/she is welcome!

[Riccardo Tomasi]

Hi Mauro and all,

Thanks for sharing this discussion with the overall ML.

Just a quick note to share with all the conclusion of our off-line discussion.

Overall, the JEMMA DAL philosophy is to standardize functionality in terms of interfaces/services (e.g. the) rather than objects.
This choice has been made to have more flexibility and support the heterogenity that we can have in the home automation domain, even for similar devices.

An  example: most smart plugs implement a On/Off control (i.e. BooleanControl ) and some Metering cluster (i.e. Meter ), but with the current JEMMA approach we can support also devices which have additional other interfaces e.g. MultiLevelControl, without hindering compatibility which support only the most basic interfaces (this actually already happens with some other commercial devices).

In other words: with the current situations in home automation standard we didn't feel feasible to define a single "Oven" class which is good for all brands/devices - so we focused on a more fine-grained specification.

Beyond that: anyway what you want to do is feasible: you can still attach functions and properties to concrete devices, but they must belong to one (or more) standard interfaces.

PS. I know from 1:1 discussions via e-mail or in person that there are a number of other project out there which are using JEMMA e.g. with dedicated GUIs or as a part of larger systems, often in conjunction with other open source or proprietary frameworks. If you feel so, don't be shy and feel free to speak up on this mailing list - this is extremely helpful to help steering future directions and maybe solving someone else's doubts ;-).

BR,

Riccardo

---
Riccardo Tomasi
Head of Research Unit: Internet of Things Service Management (IoT-SM)
Pervasive Technologies (PerT) Area
Istituto Superiore Mario Boella (ISMB)
tel. (+39) 011.2276.438
skype: riccardo1981 [My calendar] [Linkedin] [Disclaimer]

--
JEMMA - Java Energy ManageMent Application framework - http://jemma.energy-home.org
---
You received this message because you are subscribed to the Google Groups "JEMMA General Mailing List" group.
To unsubscribe from this group and stop receiving emails from it, send an email to jemma-genera...@googlegroups.com.
To post to this group, send email to jemma-...@googlegroups.com.
Visit this group at http://groups.google.com/group/jemma-general.
To view this discussion on the web visit https://groups.google.com/d/msgid/jemma-general/231154417.2158961418120345835.JavaMail.httpd%40webmail-60.iol.local.
For more options, visit https://groups.google.com/d/optout.