[tuto] Hapcan with openhab on cubieboard

[pheex]

Hello,

First, sorry for my poor english level

I'll try to explain how i succefully connect hapcan and openhab together.

Openhab (http://www.openhab.org/) is an opensource home automation framework (Java osgi).
The purpose is to add more intelligence and connectivity (mobile) to hapcan.
Openhab is multi protocol, working with a lot of device.
I use the TCP binding to communicate with the hapcan ethernet module. (i have modified the TCP binding code a little, see below)


**** General overview ******

So, openhab work with "binding", i use the TCP binding (modified version) for exchange hapcan message with hapcan tcp module.
A designer app allow to define items (switch,...), sitemap (web, ou iphone, android app), rules,...
My setup use a cubieboard (http://en.wikipedia.org/wiki/Cubieboard) as a server, working great.
I have modified the TCP binding (from openhab) in order to exchange hex binary message with hapcan.(Ascii message by default)
Setup is easy. (except tcp binding modification )


**** installation ******
TODO


***** Sample setup ******
items :

Group All
Group gGF (All)
Group Status (All)

/* active groups */
Group:Switch:OR(ON, OFF) Lights "All Lights [(%d)]" (All)

/* Lights */
Switch Light_Salon_Ceiling "Salon" (gGF,Lights) {tcp=">[ON:192.168.1.120'MAP(switch_salon.map)'], >[OFF:192.168.1.120'MAP(switch_salon.map)']]"}
Switch Light_Bureau_Ceiling "Bureau" (gGF,Lights) {tcp=">[ON:192.168.1.120'MAP(switch_bureau.map)'], >[OFF:192.168.1.120'MAP(switch_bureau.map)']"}
Switch Light_Couloir_Ceiling "Entrée" (gGF,Lights) {tcp=">[ON:192.168.1.120'MAP(switch_entree.map)'], >[OFF:192.168.1.120'MAP(switch_entree.map)']"}
Switch Light_Chambre_Ceiling "Chambre" (gGF,Lights) {tcp=">[ON:192.168.1.120'MAP(switch_chambre.map)'], >[OFF:192.168.1.120'MAP(switch_chambre.map)']"}
Switch Light_led_Ceiling "LED" (gGF,Lights) {tcp=">[ON:192.168.1.120'MAP(switch_led.map)'], >[OFF:192.168.1.120'MAP(switch_led.map)']"}


switch_bureau.map:
ON=AA301005A9FFFF04FCFFFFFFFFE8A5
OFF=AA301005A9FFFF04FCFFFFFFFFE8A5
AA302005AAFFFF04FFFFFF080006A5=ON
AA302005AAFFFF0400FFFF080007A5=OFF


sitemap:
sitemap demo label="Main Menu"
{
Frame {
Group item=gGF label="Appart" icon="groundfloor"
}
}


**** Android app screenshot *****

Android app

**** HTML5 app screenshot *****

HTML5 app

****** To do *****
When we setup a module with hapcan programmer, a lot of message are send over the ethernet module and received by openhab server.
There are flooding openhab, and this take a while to process the message queue. So the openhab system doesn't respond for a moment.

A nice feature could be add to the ethernet module : a kind of NAT configuration feature
ex: all configuration message are send only to port 1001 (programmer), not 1002 (openhab)


Regards,
pHeex

[Jacek]

Thank you pHeex for sharing this with us.
Regards
Jacek

[pawel]

Hello
I wanted to try openhab. Could you share a modified TCP binding for openhab?

[pheex]

Hi,

Yes. It's a "dev" version, there a lot of log message, but it's fully fonctionnal (work with openhab 1.4.0). I have to clean the code and compile another "prod" version without the log.

org.openhab.binding.tcp-1.4.0.jar.zip

tcp binding for hapcan

(69.76 KiB) Downloaded 751 times

Note: it replace default tcp binding, you can't use default tcp binding and my binding together (the best was to created a new plugin but i have compilation error when i created a new plugin from scratch)

pHeex.

[pawel]

Super thanks.
I'll be tested.
If the new version I hope to update

[Jacek]

****** To do *****
When we setup a module with hapcan programmer, a lot of message are send over the ethernet module and received by openhab server.
There are flooding openhab, and this take a while to process the message queue. So the openhab system doesn't respond for a moment.

A nice feature could be add to the ethernet module : a kind of NAT configuration feature
ex: all configuration message are send only to port 1001 (programmer), not 1002 (openhab)

This feature is added to the new Tibbo module firmware univ_3-102-0-x_tibbo_EM500_v2.1 http://hapcan.com/devices/universal/uni ... /index.htm
Please try if it is what you need.

Regards
Jacek

[pheex]

Hi Jacek,

Thanks for the new firmware, i'll try it as soon as possible !

Regards
pHeex

[pheex]

Super thanks.
I'll be tested.
If the new version I hope to update

Test are successful ?

[pawel]

Yes! Thank you again.
It is true that sometimes it happens that something goes wrong, it is attached and says that off ... or breaks the connection and did not deduct it started again. But it is rather a matter of configuration.

And by the way blind control works but would have been nice if they could also examine in what position are the blinds. Do you also introduce such functionality?

[pheex]

To keep the connection alive be sure a "time message" is send every minute by the ethernet module
I did'nt found yet the right setting to manage disconnections (ethernet cable unplug or ethernet module reboot for example)
With on/off module, my openhab instance is pretty stable. No state desynchronization.

I have only test on/off switch for now, i don't have blind controller but i'll test rgb led controller very soon. Stay tune

[pheex]

Hi Jacek,

Thanks for the new firmware, i'll try it as soon as possible !

Regards
pHeex

Hi Jacek,

I have tested the new firmware but it don't seem to work as i expected.

I choose socket 2 for communication with openhab and i select "block programming message - yes"

Then in Hapcan programmer i select a module and then read the module configuration (read button). In the same time i analyse openhab log and see a large message production. I'm doing something wrong ?

Thanks
pHeex

[Jacek]

He pheex
I've just tested with demo system. Port 80 is unblocked, and 79 is blocked for programming messages. It blocks programming messages, but you are right - not all. 6% of them are still passing through the socket. I suspect there is something wrong in the code (below). Please have a look, maybe you can spot a bug.

Code: Select all

main.tbs file
'-------------------------------------------------------------------------------
sub On_ser_data_arrival

	'take maximum data and send to each established socket
	if (wDataLen>0) then
		sData = ser.getdata(wDataLen)                              'take from serial buffer
		wDataLen = len(sData)                                      'data might be shorter
		
		'remove programming frames
		sBlockedData = ""                                          'all data without programming messages
		iPos=1
		for i=1 to wDataLen
			if asc(mid(sData,i,1)) <> &hAA then                     'frame beginning?
				sBlockedData =sBlockedData + mid(sData,i,1)          'no
			else	
				if asc(mid(sData,i+14,1)) <> &hA5 then			   	'frame end?
					sBlockedData =sBlockedData + mid(sData,i,1)       'no
				else
					if asc(mid(sData,i+1,1)) > &h0F then              'programming frame type?
						sBlockedData = sBlockedData+mid(sData,i,15)    'no
					end if
					i = i+14
				end if
			end if
		next i	
		
		for i=1 to sockets_in_use
			sock.num=i
			if (sock.statesimple = PL_SSTS_EST) then                 'check only sockets with established connection
				if bSockBlock(i) = true then
					sock.setdata(sBlockedData)
				else	
					sock.setdata(sData)
				end if
				sock.send
			end if	
		next i	
	end if	

[pheex]

Don't see anything wrong...

Can serial contain incomplete message ? first part of a message in a frame and last part in the following frame ?

ex:
serial buffer
frame 1 : AA040105A90000000000000000B3A5 AA040105A90000000000000000B3A5 AA040105A9
frame 2 : 0000000000000000B3A5 AA040105A90000000000000000B3A5 AA040105A90000000000000000B3A5

[Jacek]

This is exactly what I was thinking about. UNIV 3 processor sends whole frames with small gaps between them, but Tibbo module decides when to run On_ser_data_arrival event and it is done by its OS, completely out of software control. It look like this event sometimes is right in the middle of the frame, which causes that broken frame is passing through the filter.

The option would be reading only whole frames from serial buffer. I'll have to think how to do this.
..reading byte by byte from the buffer might be too slow...

[pawel]

Note: it replace default tcp binding, you can't use default tcp binding and my binding together (the best was to created a new plugin but i have compilation error when i created a new plugin from scratch)

I do not know at which point you have a problem, but I managed to force mvn to create a new plugin. Compiling also succeeded, but .... I'm too weak to program in Java :/