R: Re: [jemma-general] integration with freedomotic framework

30 views
Skip to first unread message

Mauro Cicolella

unread,
Dec 11, 2014, 3:36:00 PM12/11/14
to jemma-...@googlegroups.com
Hi Riccardo,
thanks for your clear explanation.

I need more info to figure out a possible integration. Let's work on a concrete example:
from API I get a list of all devices, for example
{
"dal.device.status": 2,
"dal.device.UID": "ZigBee:Washing Machine:ah.app.87645195726903800-1",
"service.bundleid": 3,
"dal.device.driver": "ZigBee",
"component.name": "WashingMachine",
"service.id": 79,
"service.scope": "bundle",
}

How can I determine (and then map) the object class? Of course, as you said this concept doesn't exist, but I must find it in anyway.
From dal.device.UID (using suffix Washing Machine)?

Thanks and sorry for my questions

Mauro

----Messaggio originale----
Da: tom...@ismb.it
Data: 09/12/2014 14.31
A: <jemma-...@googlegroups.com>
Ogg: Re: [jemma-general] integration with freedomotic framework

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]
On 09/12/2014 11:19, Mauro Cicolella wrote:
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!
--
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.

--
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/5486F997.3040506%40ismb.it.
For more options, visit https://groups.google.com/d/optout.


Danny Noferi

unread,
Dec 16, 2014, 9:59:42 AM12/16/14
to jemma-...@googlegroups.com, mcico...@libero.it
Hi All,
my name is Danny Noferi and I work at JOL S-Cube, a Telecom Italia lab in Milano. Lab activities are related to Smart Spaces and then smart home. The Lab is a permanent demo room and currently we rely on Freedomotic as home framework. As agreed with Fabio Bellifemine, we are now developing a plugin for Freedomotic in order to integrate the Energy@Home system (we have a gateway and some plug). 
I had a phone call with Mauro Cicolella and we decided to work together on this plugin. At the moment, the plugin takes the list of devices connected to the flexGW; for each devices, it takes the address and get the first function.UID of the device, in order to understand a kind of "object class" and create the relative object in Freedomotic. Is in your opinion the best way to gather this information?

@Mauro
Otherwise, an other way maybe could be to associate a cluster of base objects to each e@h device (one for each function.UID)...

Thanks
regards

Danny

Ivan Grimaldi

unread,
Dec 16, 2014, 10:45:52 AM12/16/14
to Danny Noferi, jemma-...@googlegroups.com, mcico...@libero.it
Dear all,
I think Danny's approach is right except for the fact that you need to check all Functions UIDs: the order used by APIs  to return the list of functions related to a device is not something you can rely on.

For instance, if your device has a function with the UID ending with ":WashingMachine" suffix, you can be sure that the device is a washing machine.

But as you can see using the simulated devices, a Washing Machine also has an EnergyMeter function: if the APIs return this as first function and you rely on this you'll miss the fact that it is a Washing Machine

To get the list of all possible functions and suffixes used for them you can visit this page:
https://github.com/ismb/jemma/wiki/JEMMA-DAL-APIs-functions

At the moment, the OSGi Device Abstraction Layer does not specify a dictionary of all possible device types. Instead, some common functions types have been defined in that standard and more function types have been created to extend it in order to fill the gaps and support more devices functions in JEMMA.

@Mauro: in DAL specification there is no specific Object Class for each device type, so you need to find in device functions which are its capabilities.

I have another strong suggestion: please rely only on DAL fields (dal.device.UID, dal.function.UID, dal.device.status,... dal.*): the other properties you see are generated inside the OSGi environment and can their value is not specified in the standard.
E.g.: the "component.name" property is available only for simulated devices (because the simulated environment uses OSGi components). The real JEMMA set-up will not expose this property because the services are not registered by OSGi components.


Best regards,
Ivan




Reply all
Reply to author
Forward
0 new messages