Domoticz

Posted: **Thursday 28 January 2016 23:48**

I started my Domotica with some KAKU switches, sensors and remotes. To make it a a bit smarter and fancier, I added a Mediola gateway. Soon I found out that the Mediola box does not do much for the smartness. It's is quite fancy, though. It comes with a mobile app and you can buy mobile device remote control app design software to it. I did that. And again: very fancy, not smart. I also bought some 868MHz LED controllers and Sunscreen motors.
https://www.conrad.nl/nl/mediola-aio-ga ... 26582.html
This Mediola Gateway contains two 868MHz tranceivers, one 433MHz tranceiver, one infrared tranceiver and connections for: power, network, additional infrared LEDs, some logic for switching on timer, event, sunrise/sundown. No further options for adding more smartness, except for the http command interface and the fact that it broadcasts almost all that 'happens' on 1902/UDP.

First 'smart' project: to gradually increase the aquarium LED light from dark to fully lit in 15 minutes, by one push of a button, and to gradually turn off by one push of a button or by timer. These gradually-on and gradually-off automations need to be interruptable by a push on the mentioned button. Well, Mediola couldn't do that.

So, I got a Raspberry PI 2, looked at OpenHAB and Domoticz. Easy choice: Domoticz. Now... to make the Domoticz and the Mediola 'work' together...

To make things easy, I got an RFXTRX433E. (I need an 868MHz tranceiver, too. ...very much...)
So, my LED controllers and sunscreen motors are 868MHz, so, still out of reach for the Domoticz. I managed to craft some LUA that enables Domoticz to control these 868MHz devices, by sending http to the Mediola, which transmits it over 868MHz. For example, when I push my KAKU switch, Domoticz picks it up, sends a http request to the Mediola, which sends an 868MHz command to the LED controller, which powers the LEDs that light up the room. From 'push' to 'light' takes about 1.5 to 2 seconds and that is not good for the WAF.

So... is there anybody out there that also tries to make Domoticz and Mediola to 'work' together? (or successfully made it happen?)

If so, would be good to share ideas and scripts. I'll share mine if anyone is interested.

Posted: **Tuesday 02 February 2016 22:30**

Hmm... 37 reads, no replies... well... I'll post my progress, anyway... It's worth reading: two WAF-increasing tips, in here.

So.. Update: I was able to speed up the reaction time considerably and implement something new on the Mediola.

1st implementation version involved a KAKU-RC switch in Domoticz, which triggered a LUA script, which triggered a virtual/dummy dimmer, which triggered another LUA script that puts an OpenURL in the commandArray, which triggered the Mediola to send an 868MHz command to the RGB controller.
Now at my 2nd implementation, these LUA scripts are integrated into one LUA script. This LUA executes curl to send the command to the Mediola and the virtual/dummy dimmer is updated by the commandArray. Response times are now approx 200 to 300 ms and the WAF gone up.

Apparently, after returning the commandArray, Domoticz is rushing to put out RF commands. After that, it still needs some time to do housekeeping, like, updating switch states in the DB, GUI, logs and whatever, before it's ready to execute the next device trigger. So, by eliminating that extra execution loop, I gained quite a big increase in performance.

Next step is, to check a PING switch, to see if the Mediola is up, before sending a command by using curl. If you don't do this, your Domoticz will totally freeze until the curl command times out, when the Mediola would be down. It's good practice to make sure that LUA scripts will always finish as fast as possible. So no sleep loops, no ping checks, no polling, nothing. If you need to do such, first, check if Domoticz has something for it. If not, then implement it in an external script, configure it to run as a daemon and let it report results to a Domoticz uservariable or virtual/dummy switch by using API/JSON.

I already made a daemonized Python script that listens for Mediola http commands on a port, and replies just like a Mediola gateway would do. This fake Mediola gateway has been added in the mentioned design software. Commands are forwarded to Domoticz using the API. This allows me to add the Domoticz server as a Mediola gateway in the remote control design software and I'm able to control Domoticz by using the Mediola remote control app. Currently only the Mediola RGB colorpicker is implemented in that way. Normal Mediola buttons can send a http request straight to Domoticz.

Another WAF project: I turned a KAKU AYCT-102 remote control in a very simple 433MHz TV remote control. This replaces two 'complicated' remote controls for one 'simple' remote control: TV on and off, Select Cable-tuner HDMI, Select Kodi HDMI, Cable-tuner channel up and down, TV volume up and down. For the more advanced TV/tuner/Kodi control functions, I use Mediola's app and Yatse.
The KAKU commands are translated to OpenURL-commandArrays that instruct the Mediola gateway to send the appropriate IR signal. The volume controls are slow, because the TV needs many commands for a bit of volume increase. I kinda solved this by putting multiple transmits for that command: in the script, using curl, and in the OpenURL-commandArray. A better solution would be to have the Mediola repeat the volume-commands, or learn longer IR remote keypresses to the Mediola. I'll be experimenting with that. One usually holds down a volume control button on a remote. Doing that on a KAKU remote does not work well for Domotica systems.
Of course this can also be done by connecting an IR LED transmitter gadget directly to the GPIOs of your Domoticz Raspberry. In my case that would be a bit unpractical, because the Domoticz Raspberry is located in another room.
And it could also be done by using only the Mediola, but that would involve creating extra tasks in the Mediola. Since I have no info on how many tasks it can store and how it will be performing if there would be a lot of tasks, I already decided to only use it when really needed.

I'm now focused on Domoticz, so the goal is to put the smartness in the Domoticz and reduce the Mediola to just a tranceiver. Currently there are just 4 tasks, translating KAKU RF commands to 868MHz commands for the two sunscreen motors. It needs some LUA that will command the Mediola to send these by 868MHz. That would be faster, the Mediola task list would be empty and my goal would be achieved.
Just need to wait for some sunny weather. Neighbors might think I gone cuckoo, for moving up and down my sunscreens for a while, while testing this in the darkness of the evening.

Thanks for reading this rather lengthy post 'till the end.
Again... does anyone else here own a Mediola gateway? You don't have to write half a book. A simple 'yes' will do.
Thanks.

Posted: **Sunday 13 March 2016 17:15**

Hi, I also bought a Mediola gateway mid summer last year, and it does a lot of good things, but when I discovered Domoticz and installed it to my Raspberry Pi (first generation), I like the open source. It is also compatible with my logitech harmony hub, which I own since the launch of it.

So, for the moment I dit not buy the an RFX transceiver (quite expensive) as I can control my blends, etc with my mediola.

Now I am looking for a way to use my mediola as a slave device for sending the RX/IR-commands controlled by domotics.

I also have a Smappee monitoring, which I believe, can be integrated to the Domoticz package.

I think we are at the same wavelength, so please tell me more how you managed it to get them work together.

Jan.

Posted: **Tuesday 15 March 2016 0:27**

Hi. Welcome to the wonderful world of Domoticz and Mediola.

Later on, I'll probably write more, but here's some things to get you going:

I have a big LUA script that does all kind of things. It starts by checking what device changed and it ends with sending results to the comandArray. Read up on it on the Domoticz Wiki Events page.
I created dummy domoticz switches using virtual hardware. When I operate those in Domoticz, the LUA script will trigger.

This scriplet will instruct Domoticz to make the Mediola send an IR command, using it's internal blaster:

Code: Select all

	if dev=='TV channel' and cmd=='Off' then 		rcc='190826000001002A0608CC044F0099007A0099019300992E7608CC021F00995D20000101010101010101010101010201010101010101020101010202020201020202030405040504050405&XC_FNC=Send2&ir=00'
	end
	cmdarr='OpenURL'
	cmd='http://mediola-IP/command?code='..rcc

This scriplet controls my blinds. I don't know why I did this with OS calls and curl commands. If there's no specific needs to do it like this, you should send your commands using commandArray OpenURL.

Code: Select all

if dev=='Screen big window' and (cmd=='On' or cmd=='Closed') then --close
	local curlcommand = "curl 'http://mediola-IP/command?XC_FNC=SendSC&type=UR&data=BCDE24'"
	os.execute(curlcommand)
end
if dev=='Screen big window' and (cmd=='Off' or cmd=='Open') then --open
	local curlcommand = "curl 'http://mediola-IP/command?XC_FNC=SendSC&type=UR&data=BCDE21'"
	os.execute(curlcommand)
end

Type=UR means that it needs to command a UniRoll blind drive motor. Data is the address, last number of data is the command.

I don't have examples of KAKU commands anymore, because I control my KAKUs by RFXCOM tranceiver.

Somewhere on the Mediola site, you can find a PDF document that describes the http api (in German). Some commands are explained there. With that, you can create basic Mediola command URLs. Commands for controlling specific hardware will need to be sniffed. I have an Android with an app that captures network traffic and the Mediola remote control app. I capture the commands that the Mediola app sends and use that info to create the URLs for Domoticz, to send to the Mediola.

If you want to make Domoticz react to wireless signals, you need to listen to broadcasts on port 1902 (UDP). I'm using this Python code for that:

Code: Select all

#!/usr/bin/env python

import socket
import urllib2

UDP_IP = "255.255.255.255"
UDP_PORT = 1902

sock = socket.socket(socket.AF_INET, # Internet
                     socket.SOCK_DGRAM) # UDP
sock.bind((UDP_IP, UDP_PORT))

while True:
	data, addr = sock.recvfrom(1024) # buffer size is 1024 bytes
	if data.find("{XC_EVT}",0,10) <> -1 :
		type=data[:data.find(",",0,len(data))-1]
		type=type[17:]
		data=data[data.find("data",0,len(data))+7:]
		data=data[:len(data)-2]
		url="http://localhost:8080/json.htm?type=command&param=updateuservariable&idx=3&vname=udp2dom&vtype=2&vvalue="+type+"_"+data
		urllib2.urlopen(url).read()

		# interpreting things like: {XC_EVT}{"type":"IT","data":"030206"}
# sending things like: http://localhost:8080/json.htm?type=command&param=updateuservariable&idx=2&vname=udp2dom&vtype=2&vvalue=stringthatcontainsthereceivedcommand

I made this run as a daemon on the same PI as Domoticz runs on. The udp2dom variable needs to be created in Domoticz. Then you can write a LUA script that gets triggered on this variable change. That LUA can update your virtual switches.
I see that I included an example on how a KAKU command looks like. Type:IT means InterTechno, which is a German/Austrian brand of the same stuff as KAKU/CoCo.

The best way is that someone would write a Domoticz hardware driver for the Mediola. I can't do that, so, I'm working around that with a lot of scripting.

PS: The Android app that I use for finding out what the Mediola app says to the Mediola, so I can mimic that in Domoticz:
https://play.google.com/store/apps/deta ... sslcapture

Domoticz

Mediola gateway V4 Plus & Domoticz...

Mediola gateway V4 Plus & Domoticz...

Re: Mediola gateway V4 Plus & Domoticz...

Re: Mediola gateway V4 Plus & Domoticz...

Re: Mediola gateway V4 Plus & Domoticz...