ismb / jemma Goto Github PK

Define a good strategy to handle dependencies towards legacy code (GAL/JGAL) and external project e.g. zigbee4osgi

Initial overall description of the framework (what it is used for, what does it include, bundle list, etc.)

Incl. consistent style

related to #38

in order to evolve the platform further, we might need a clean-up and refactoring of all bundles. A first step for this would be to better document available bundles (high-level documentation on the wiki) + good javadocs for the main classes/interfaces/services/components

JEMMA release 0.0.1 has more than 2049 Warnings. We should solve them in order to have a more "manageable" set of checks.

e.g. WiFi washing machine, etc.

Initial overall description and bundle list on the wiki should be on the wiki

Integrate JEMMA with a rule engine such as IFTTT or FreeDomotic

The tutorial should show how a sw developer can interact with smart appliances from inside Jemma or also from external clients.

maybe 1 simple wiki page can be enough e.g. how we manage branches, how we track issues, etc.

Flow to be discussed:

• gitflow
• feature branch
• forking
• ... or some combination of them

they should include:

• high-level "marketing-style" description of the project
• links to subscribe/access mailing lists #1
• links to the wiki #2 #3
• links to code repositories and distribution channels

The core of Jemma is composed of a very limited set of bundles (5-6 in total) which provide the only functionality of discovery and communication with Energy@home devices including parsing/unparsing ZigBee clusters. All the other bundles deal with the application layers and the communication with the server.
I propose that developers shall have a simple way to download and use the JEMMA-core where the application bundles shall be considered an optional add-on

The current version of JEMMA does some internal check when an incoming message is received: it is not clear yet, but somewhere there is a check to verify that the ProfileId match the declared one by the node itself (or the supported one from the GAL).
However this check should be avoided, giving the responsability to the application to receive and handle this message (at the moment the message could be dropped and the application is not even aware that a message has arrived).

This issue tracks standards which could be considered for integration in JEMMA at various levels, but which have not been discussed yet with developers.

• http://en.wikipedia.org/wiki/TR-069
• ISO/IEC/IEEE P21451-1-4 XMPP for the Smart Grid - http://www.ktc.se/wp-content/uploads/2013/05/AEC2013-NYC-NY-Rev.-12-R3.pdf

(Comment below if you have other standards to propose)

Some marketing material is needed there,

First blog post with the release announcement

Complete purchase of the official domain and sub-domain for this project

At the moment, the library used to manage json RPCs between the osgi application and the web ui, Jabsorb, tries to compress every json response that needs to be sent to the web ui.

Jabsorb has a GZip threshold that represents the minimum number of bytes gained from compression that makes acceptable to send a compressed json to the client. When the result of the compression falls below that threshold, the compressed message is discarded by the library and the original uncompressed message is sent instead.
Jemma's compressed json messages are usually so small that the compressed message is actually bigger than the original one or that the compression gain is often smaller than the threshold, so ATM compressing them seems useless.

What i've described above can be noticed looking at Jemma logs:

WARN org.jabsorb.JSONRPCServlet - gzipping resulted in a larger output size! aborting (sending non-gzipped response)... 
you may want to increase the gzip threshold if this happens a lot! original size = 1598 gzipped size = 1621

Is this issue actually relevant? It depends on where the Jemma is deployed.
While i don't have actual numbers, i suspect that when deployed on gateways with a slow CPU, the cpu time lost trying endlessly to compress json messages is not negligible (and could be used to perform other tasks).

I'm going to send in open a pull request for this (since i've already made this modification and tested it), that completely disables gzip compression. Feel free to keep it on hold until actual stats on performance will be measured.

First release of the full repository

(to be evaluated)

Beyond selecting an appropriate logging framework, we should also perform a full round of review of all bundles and harmonize all levels and conventions. High-level information to ensure we don't derive is kept here

(Note: to be split into several tickets)

short high-level documentation for all bundles - just 1 paragraph outlining the main features of each bundle.

Descrivere bene come si può estendere per aggiungere nuovi device, per aggiungere nuove radio diverse da ZigBee, per modificare la GUI, …

This is related to #22

• https://github.com/openhab/openhab (list more here)
• openadr http://openadr.org/
• https://www.alljoyn.org/
• https://www.homegear.eu/index.php/Main_Page#Download_Homegear

try to define a set of APIs and provide an implementation to ease the integration of non ZigBee HA compliant devices (e.g. Plugwise)

Verify JavaGAL and other bundles are using an appropriate package naming convention

To perform ana analysis of top resource-consuming tasks in JEMMA, and optimize most relevant code parts

E.g. to deploy a local server, or to use a cloud provider, etc.

The next code-base should only have dependencies towards bundles/poms which are available on mainstream repositories (e.g. mavencentral)

Create mailing list systems (google groups) - including links to subscribe and some tuturial to post

Maven-based toolchain shall be working for compile and run, using a private maven repository for those dependencies we cannot easily pull from public repositories.

According to this guide we could use Sonatype OSS Repository. But maybe we can consider also some alternatives.

see here

e.g. UPS, battery, etc.

Rationale: so the project names show nicely in the github home page.
(also to be checked : is this a good practice for OSGi and Maven ? )