OPEN HAB

[ifachsoftware]

Buongiorno a tutti , vorrei utilizzare questa discussione per condividere info su OpenHab che ritengo essere un'ottima soluzione per gestire non solo problemi di building automation ma anche problematiche di automazione.

L'unico problema che ho riscontrato è la carenza di documentazione e la necessità di fare parecchie prove perchè o mancano info o ci sono bachi o per l'ignoranza di certi dettagli del protocollo di comunicazione utilizzato.

Allego la prima prova , fatta con con ModBus TCP collegato ad un PLC Wago con Codesys  :

 

 

Prove OPENHAB.pdf

[ifachsoftware]

Aggiungo la modifica alla prova di sopra per collegarsi ad un DPT1 Knx di indirizzo 0/0/1

openhab.cfg :

# The slave start address (optional, defaults to '0')
#modbus:slave1.start=192.168.1.200

# The number of data item to read
# (optional, defaults to '0' - but set it to something meaningful)
#modbus:slave1.length=



modbus:tcp.slave1.connection=192.168.1.200
modbus:tcp.slave1.port=502
modbus:tcp.slave1.id=1
modbus:tcp.slave1.start=8192
modbus:tcp.slave1.length=1
modbus:tcp.slave1.type=coil 

# Value type, required for combined registers (details: http://www.simplymodbus.ca/FAQ.htm#Types)
# Can be "bit", "int8", "uint8", "int16", "uint16", "int32", "uint32", "float32"
# (optional, defaults to 'uint16')
#modbus:tcp.slave1.valuetype=bit


modbus:tcp.slave2.connection=192.168.1.200
modbus:tcp.slave2.port=502
modbus:tcp.slave2.id=1
modbus:tcp.slave2.start=12288
modbus:tcp.slave2.length=1
modbus:tcp.slave2.type=holding 
modbus:tcp.slave2.valuetype=int16

modbus:tcp.slave3.connection=192.168.1.200
modbus:tcp.slave3.port=502
modbus:tcp.slave3.id=1
modbus:tcp.slave3.start=12289
modbus:tcp.slave3.length=1
modbus:tcp.slave3.type=holding 
modbus:tcp.slave3.valuetype=int16

modbus:tcp.slave4.connection=192.168.1.200
modbus:tcp.slave4.port=502
modbus:tcp.slave4.id=1
modbus:tcp.slave4.start=12290
modbus:tcp.slave4.length=1
#modbus:tcp.slave4.type=input
modbus:tcp.slave4.type=holding 
modbus:tcp.slave4.valuetype=int16

# ==== Configurazione Knx ==============================================================

knx:type=TUNNEL
# Indirizzo del Gateway 
knx:ip=192.168.33.233
# Indirizzo del PC (DEVE ESSERE SULLA STESSA RETE SE NON NON VA)
knx:localIp=192.168.33.91

demo.sitemap:

sitemap demo label="Demo  Claudio"
{
	Frame {
		Group item=gClaudio icon="terrace"
		Setpoint item=Dimmer1 minValue=0 maxValue=100 step=1
		Setpoint item=Dimmer2 minValue=0 maxValue=100 step=1
		Setpoint item=Dimmer3 minValue=0 maxValue=100 step=1
	}
}

demo.items:

Group All
Group gGF 		(All)
Group gFF 		(All)
Group gC 		(All)
Group Outdoor 	(All)
Group Shutters 	(All)
Group Weather 	(All)
Group Status 	(All)

Group gClaudio  (All)


/* Claudio */
Contact Contact1 "Ciao [%s]" <gClaudio> (gClaudio)   {modbus="slave1:0"}
Switch MySwitch  "My Modbus Switch" <gClaudio> (gClaudio) {modbus="slave1:0"}
Number MySwitch1 "A [%d]" <gClaudio> (gClaudio) {modbus="slave2:0"}
Number Dimmer1 "A [%d]" <gClaudio> (gClaudio) {modbus="slave2:0"}
Number Dimmer2 "B [%d]" <gClaudio> (gClaudio) {modbus="slave3:0"} 
Number Dimmer3 "C [%d]" <gClaudio> (gClaudio) {modbus="slave4:0"}  
Switch TestKnx "TestKnx" <gClaudio> (gClaudio) { knx="0/0/1" }

Lo switch a video TestKnx funziona in maniera bidirezionale

Ora vorrei provare a far si che quando Arriva On dal Knx dall'indirizzo di gruppo 0/0/1 venga scritto sulla variabile A del Modbus un valore fisso : per esempio 20

Lo script che ho scritto è il seguente :

demo.script

say("CIAO DA CLAUDIO !")

if(TestKnx.state == ON)
{
	sendCommand(Dimmer1,20)
}

Pero' non funziona .....  avete qualche idea ?

 

 

 

[smoothhands]

Hai ragione... bisogna districarsi fra ciò che ha pubblicato chi ha

scritto un particolare binding e la community sperando che

qualcun altro ha avuto il tuo stesso problema.

Sei stato fortunato che il tuo PLC ha un accesso tramite

modbus TCP. il cui binding si comporta bene.

Qualcun altro com modbus RTU non è stato altrettanto fortunato 

[smoothhands]

Non usare gli script... forse ti complichi un pò le cose.

Crea invece una rule in quanto uno script altro non è che

il blocco when della rule.

Sono con l'ipad ed è scomodissimo.

Appena trovo un pc ti faccio un esempio.

[ifachsoftware]

Risolto 

demo.rules :

import org.openhab.core.library.types.*
import org.openhab.core.persistence.*
import org.openhab.model.script.actions.*


rule "Claudio"
	when
		Item TestKnx changed to ON
	then
		sendCommand(Dimmer1, 20)
		//postUpdate(Dimmer1, 20)
end

Cosi' funziona , mentre se usavo il PostUpdate scriveva , ma me lo riportava al valore di partenza subito dopo.

Qual'è la differenza ?

Grazie

Modificato: 21 gennaio 2016 da ifachsoftware

[smoothhands]

Devi considerare che tutto è basato sul concetto di Item e di event BUS.

sendCommand e postUpdate sono delle actions preconfigurate che agiscono sull'event BUS.

sendCommand invia comandi verso il binding e quindi genera delle azioni sul campo.

postUpdate, invece, effettua un aggiornamento dell'Item senza inviare nulla verso il binding.

Quindi cosa succede... che se fai solamente l'update il binding modbus dopo tot tempo 

effettua un refresh dovuto al polling sui registri del PLC e riaggiorna l'Item con quanto

letto dal campo.

Modificato: 21 gennaio 2016 da smoothhands

[smoothhands]

Comunque openHAB è una soluzione opensource e quindi non

c'è un'assistenza come potrebbe essere per altri prodotti commerciali.

Dato l'ampiezza che ha raggiunto il progetto è comunque apprezzabile la disponibilità

di documentazione per binding e la presenza di una community in diverse lingue per

dare un minimo di supporto. Supporto dato da altri utilizzatori comunque.

Io stesso, quel poco che ho imparato, l'ho fatto andando a leggermi più volte la

documentazione, provando direttamente e andandomi a leggere i sorgenti.

 

Modificato: 21 gennaio 2016 da smoothhands