VoxCommando
Arduino & Other Home-made Gadgets (that work with VC!) => Arduino + MySensors => Topic started by: Kalle on December 19, 2014, 06:37:27 AM
-
Hi guys, this is one of our plan for the new year! :bignod
We are build some wireless sensors based on arduino hardware and the API from www.mysensors.org (http://www.mysensors.org), which is cheap and easy to handle. The sensors can be powerd by a battery/usb or power supply.
There are a lot of sensor available - for example: light switch, temperature, motion, humidity, water-level, light level, IR control, gas, dust and much more.
We started with examples from this website: http://www.mysensors.org/build/temp (http://www.mysensors.org/build/temp) which has also a fantastic community. You can use this sensors with a Vera controller by connecting a self-build gateway on his USB port or as stand alone solution with VoxCommando connect to a PC.
We have created a first sensor and also a gateway PCB-board. The sensor board has a size of 44x34mm and the gateway a size of 42x30mm. Now we do some tests to get sure everything works well. At the moment we can not really say how much it will cost, because it depends how many boards we produce and which sensor parts is needed. We think it will cost ~10$ per sensor node like a temperatur sensor.
If anybody is interesting to create his own sensor or have good ideas or maybe will help us, please feel free to post here.
If you need more information, please ask for.
BIG THANKS to www.mysensors.org (http://www.mysensors.org) for the great project!
here are some "first-looks-like" photos ;)
This is really a first look, without a case, but it will show you the size.
-
Here are some more images to give you an idea of the actual scale of the assembled base unit. Yes I know, my hands are ludicrous. :biglaugh
Also a schematic of the board. This is intended as a test board, so you can build all kinds of different sensors with it without extra soldering (once you have assembled it with all the headers etc. as shown)
-
This looks really cool.
Best wishes.
-
Nice! :D
I wanted to do something similar, but I'm still waiting for my Arduinos from china...
Did you already try how long the sensor can be powered by battery?
-
Hallo Dave,
die Batterie-Tests laufen noch. Ein Temperatur-Sensor läuft jetzt über 2 Wochen (mit 2 AA Batterien die aber nicht neu waren, ca. 90%) sind jetzt bei 50%. Im Moment habe ich aber noch keine LED oder Spannungsregler am ProMini gekappt. http://www.mysensors.org/build/battery (http://www.mysensors.org/build/battery)
Und der Arduino Sketch sollte auch noch ein wenig angepasst werden(momentan wird alle 10 Minuten der Status gesendet).
Für VoxCommando haben wir einen Python Script, der über das Gateway von allen Sensoren die Daten als Event mit angehängten payloads, an VC ausgibt. Danach speichert VC die Daten in Map-tables (Device ID, Art des Sensors, Daten des Sensors und Datum mit Uhrzeit seit der letzten Aktualisierung). Es werden also 3 Maps generiert, die dann alles automatisch aufnehmen. Bei Interesse melde dich, vor allem wenn Du PCB-boards brauchst. Für Arduino ProMinis habe ich eine sehr gute Ebay Adresse (2 EUR pro Stück und Lieferung innerhalb von 4-5 Tagen).
UPDATE 21.12.2014: Die Batterien sind jetzt nach ca.2 1/2 Wochen erschöpft. Ich habe einen neuen Test mit entfernten LED's und angepasstem arduino sketch gestartet (Der Sensor sendet jetzt alle 30 min seinen Batteriestatus an das Gateway).
-
Hi,
A few questions if I may.
Am I correct that if I don't have a Vera controller I can connect a Gateway via USB to my VC computer?
When do you think your software and hardware will become available for non programmers?
Best wishes.
-
You have already the Software - VoxCommando ;)
For this project, there is no Vera controller necessary and yes you can connect the gateway via USB to your PC.
You need only run our python script within the python plugin in VC. All sketches for the Arduino Sensors are at www.MySensors.org available, I think we will modify something in the sketches, because to create a sketch for a multisensor like motion, temp, infrared.
We will do first some tests to get sure everything is working fine with our PCB board and a bit fine tunning at the python code.
If you are able to solder things on a PCB-Board, the hardware is already available. To get "out of the box" working devices take a while but sorry, now I am still not able to tell you when it will available, maybe James have a idea.
-
Thank you kalle,
Yes - I was really thinking about the Python script :)
So I can be ready. I can just build the Gateway and Sensor from the the link http://www.mysensors.org/ ? Then I will be ready for when you are to make the python & arduino code available?
I will probably try the Temp sensor first - so that I can understand how things work.
Of course I will certainly support/buy any hardware you decide to produce in the future.
Best wishes.
-
Yes, you can build the gateway and the sensor and I can post the python script and some xml's for VC. You can use the temperatur sketch from www.mysensor.org (http://www.mysensor.org), but get sure that you have install also the mysensor libraries from her website: https://github.com/mysensors/Arduino/archive/master.zip (https://github.com/mysensors/Arduino/archive/master.zip)
Our PCB board is also not necessary, but it facilitates the building of the sensors.
-
I recommend you start with a breadboard (if you have one) and later you can think about getting a PCB in order to make a nice small package.
We are happy to share the files needed to make your own but at some point next year we may make a larger batch of PCBs that would cost a lot less than having just a few of your own made.
-
There are several ways to program your Arduino. I personally use the free software provided by Arduino but there are also plugins for your web browser etc. It's all free stuff.
The simplest (and still cheap) way to start is probably with two Arduino Nanos. If you want to use the Pro Mini (which is oddly smaller than the Nano) it is more difficult because the mini does not have a usb plug and you also need a special programmer (not too expensive but more complicated).
So for example you could get started with two of these (one for the gateway and one for a sensor): http://www.ebay.ca/itm/1P-HOT-USB-Nano-V3-0-ATmega328-16M-5V-Micro-controller-CH340G-board-For-Arduino-/271686219247?pt=LH_DefaultDomain_2&hash=item3f41c2b5ef
You also need other parts like the RF module and the actual sensor parts. All that information is available at the MySensors link that Kalle posted above.
-
Thank you.
Yes. I agree with all your recommendations. I'll come back when I have all the parts and tested.
Best wishes.
-
Hi Guys, now we can present a finished gateway which work with VoxCommando as controller.
Here is a short video, which demonstrate how VoxCommando controls our RGB-Dimmer-Sensor (Great Arduino-Sketch from Dave) ::banana
(https://www.youtube.com/embed/2P8ZKJulEJU)
And here some first pictures from the gateway in a housing (Zebrano-wood)
We have two different sizes of gateways.
https://www.dropbox.com/s/fiar02gnczsp6g5/gatewayPCBFront.png?dl=0 (https://www.dropbox.com/s/fiar02gnczsp6g5/gatewayPCBFront.png?dl=0)
https://www.dropbox.com/s/k11egvyy4v5ivgm/gatewayPCBback.png?dl=0 (https://www.dropbox.com/s/k11egvyy4v5ivgm/gatewayPCBback.png?dl=0)
https://www.dropbox.com/s/aptrp4p8285x5mo/P1040457.JPG?dl=0 (https://www.dropbox.com/s/aptrp4p8285x5mo/P1040457.JPG?dl=0)
https://www.dropbox.com/s/tjmnnspefrbjl8u/pcb1.jpg?dl=0 (https://www.dropbox.com/s/tjmnnspefrbjl8u/pcb1.jpg?dl=0)
https://www.dropbox.com/s/py0xv0zrt931s8s/P1040465.JPG?dl=0 (https://www.dropbox.com/s/py0xv0zrt931s8s/P1040465.JPG?dl=0)
https://www.dropbox.com/s/fz0gicwzu8kesmt/P1040467.JPG?dl=0 (https://www.dropbox.com/s/fz0gicwzu8kesmt/P1040467.JPG?dl=0)
https://www.dropbox.com/s/cnxg3djfcrz6pic/20150204_170824.jpg?dl=0 (https://www.dropbox.com/s/cnxg3djfcrz6pic/20150204_170824.jpg?dl=0)
https://www.dropbox.com/s/0fue9r3q5whzpr0/20150204_155126.jpg?dl=0 (https://www.dropbox.com/s/0fue9r3q5whzpr0/20150204_155126.jpg?dl=0)
https://www.dropbox.com/s/le8yiewlwwp1a4p/tinynanogateway.PNG?dl=0 (https://www.dropbox.com/s/le8yiewlwwp1a4p/tinynanogateway.PNG?dl=0)
I hope you will like it ;)
PS: It is possible to order a assembled gateway (without housing), or only the PCB-board to solder things by your self. Feel free to ask for details.
We have a lot of more sensors created to show you, but first we still wait for a batch of new sensor pcb's.
-
Amazing work Kalle and Dave! I look forward to trying out the RGB light strip myself soon. I love the little wood boxes. Guaranteeeeeeed high WAF!
I did some work today on the python code for the "controller" (serial communication between VC and the Gateway). I think that auto assignment of IDs for new sensors should work well now.
The next step is to store all collected sensor data in python variables (and to a file on disk) so VC can request info any time. I will work on this next.
-
It looks like the project is growing fast - great work at the python code James!
-
Very nice job! Can't wait to see more! ::) ::)
-
Any news about this? I'm building separate nodes for controlling lights and reading from sensors and im very excited to try thr python programs that you mentioned.
Thanks!
-
I will upload some python later today. It is still a bit of a work in progress. The python could be improved in many ways but it works.
Kalle and Dave have been working on all sorts of neat stuff like IR blasters RF blasters, and RGB light strips controllers.
-
Here is a starting point for the python code. It works pretty well. You need to set the com port for your gateway near the beginning of the code.
I don't have time to try to explain everything about it, but feel free to ask questions. Ideally this code should be written to put everything into a class but I'm not that experienced with python, and although I would be able to do it it would take me more time than I want to spend on it at the moment. If anyone out there who is good with python wants to help that would be great.
#VoxCommando read/write to serial port by James&Kalle
#you must have enabled the python-plugin in VoxCommando
#start this python script with VoxCommando
#this code is for using Sensors which build with sketches and Sensors from www.MySensors.org
#Protocol
#http://www.mysensors.org/build/serial_api
import clr
import io,json,sys
import time
clr.AddReference('System')
from System import *
from System.Collections.Generic import *
import traceback
## Init variables...
useComPort="COM3"
global sValSum
sValSum = ""
global inclusionMode
inclusionMode = True
minID=1 # default: 1
maxID=255 # defualt: 255
## prepare / clear log file
logFile = open("PY\\sensorLog.txt", "wt")
logFile.close()
## Initialize, try to load known IDs from file
## If a sensor is no longer used you can edit the text file "PY\sensorIDs.txt" to remove the id so it can be assigned to a new sensor.
try:
readIDsFile = open("PY\\sensorIDs.txt", "rt")
txtIDs = readIDsFile.read()
readIDsFile.close()
sensorIDs = json.loads(txtIDs)
print "loaded IDs"
print sensorIDs
except:
print "unable to load sensor IDs"
sensorIDs = []
def log(txt):
with open("PY\\sensorLog.txt", "a") as myfile:
myfile.write(txt+'\n')
def saveIDsToFile(saveIDs):
saveIDs.sort()
IDsFile = open("PY\\sensorIDs.txt", "wt")
strData = json.dumps(saveIDs)
IDsFile.write(strData)
IDsFile.close()
def registerID(newID):
intID = int(newID)
global sensorIDs
if intID in sensorIDs:
log( "ID already registered: "+str(newID))
else:
log( "registering new ID: "+newID)
sensorIDs.append(intID)
saveIDsToFile(sensorIDs)
def getNewID():
global sensorIDs
for i in range(minID,maxID):
if not (i in sensorIDs):
return i
return -1
def assignFreeID():
global inclusionMode
# we can check here to see if we are in "including mode or not"
# and if not then just log and return without assigning an ID
newID = getNewID();
log("free node ID: "+str(newID))
if newID==-1:
log( "error: there are no free IDs left!")
else:
if inclusionMode:
strMessage = "255;255;3;0;4;"+str(newID)
serialPort.WriteLine(strMessage)
print strMessage
log( "assigned new ID to sensor: " + strMessage)
else:
log("not in inclusionMode so not assigning ID to node")
###
### END of new sensor ID section
###
sensorTypes = {"0":"TEMP", "1":"HUM", "2":"LIGHT", "3":"DIMMER", "4":"PRESSURE", "5":"FORECAST", "6":"RAIN", "7":"RAINRATE", "8":"WIND", "9":"GUST", "10":"DIRECTION", "11":"UV", "12":"WEIGHT", "13":"DISTANCE", "14":"IMPEDANCE", "15":"ARMED", "16":"MOTION", "17":"WATT", "18":"KWH", "19":"SCENE_ON", "20":"SCENE_OFF", "21":"HEATER", "22":"HEATER_SW", "23":"LIGHT_LEVEL", "24":"VAR1", "25":"VAR2", "26":"VAR3", "27":"VAR4", "28":"VAR5", "29":"UP", "30":"DOWN", "31":"STOP", "32":"IR_SEND", "33":"IR_RECEIVE", "34":"FLOW", "35":"VOLUME", "36":"LOCK_STATUS", "37":"DUST_LEVEL", "38":"VOLTAGE", "39":"CURRENT"}
IntsubTypes = {"0":"BATTERY", "1":"TIME", "2":"VERSION", "3":"ID-REQUEST", "4":"ID-RESPONSE", "5":"INCLUSIONMODE", "6":"CONFIG", "7":"FIND-PARENT", "8":"RESPONSE-PARENT", "9":"LOG-MESSAGE", "10":"CHILDREN", "11":"SKETCHNAME", "12":"SKETCHVERSION", "13":"REBOOT", "14":"GATEWAY-READY"}
presTypes = {"0":"DOOR", "1":"MOTION", "2":"SMOKE", "3":"LIGHT", "4":"DIMMER", "5":"COVER", "6":"TEMP", "7":"HUM", "8":"BARO", "9":"WIND", "10":"RAIN", "11":"UV", "12":"WEIGHT", "13":"POWER", "14":"HEATER", "15":"DISTANCE", "16":"LIGHTLEVEL", "17":"ARDUINONODE", "18":"ARDUINORELAY", "19":"LOCK", "20":"IR", "21":"WATER", "22":"AIRQUALITY", "23":"CUSTOM", "24":"DUST", "25":"SCENECONTROLLER"}
def Ondata (sender, event):
try:
processData (sender)
except:
log( "error receiving serial data...")
log( traceback.format_exc() )
def processData (sender):
global sValSum
sData = sender.ReadLine ()
log("========NEW MESSAGE======")
log(sData )
dataParts = sData.split(";")
sensorID = dataParts[0]
childID = dataParts[1]
friendlyID = sensorID+"|"+childID
msgType = dataParts[2]
msgPayload = dataParts[5]
log( "Message type: "+msgType )
if msgType=="1":
#SET VALUE Message
sVal = msgPayload
if sVal[-1] == "+":
sValSum = sValSum + sVal[0:len(sVal)-1]
else:
print "SET VALUE Message -- node: " +friendlyID
registerID(sensorID)
sensTypeNum=dataParts[4]
sensorType = sensorTypes[sensTypeNum]
sValSum = sValSum + msgPayload
vc.triggerEvent("MySensorsValue."+sensorType+"."+friendlyID+"."+sValSum, List[str]([dataParts[0],dataParts[1],sValSum, sensorType]))
sValSum = ""
elif msgType=="0":
#PRESENTATION Message
log( "PRESENTATION Message")
#registerID(sensorID)
presTypeNum=dataParts[4]
presType = presTypes[presTypeNum]
log( "presType: "+presTypeNum+": "+presType)
#vc.triggerEvent("MySensorsPres."+presType+"."+friendlyID+"."+msgPayload, List[str]([dataParts[0],dataParts[1],msgPayload, presType]))
elif msgType=="3":
#INTERNAL Message
#log( "INTERNAL Message" )
IntsubTypeNum=dataParts[4]
IntsubType = IntsubTypes[IntsubTypeNum]
log( "Internal Message subType: "+IntsubTypeNum+": "+IntsubType )
#vc.triggerEvent("MySensorsIntsub."+IntsubType+"."+friendlyID+"."+msgPayload, List[str]([dataParts[0],dataParts[1],msgPayload, IntsubType]))
if sData=="255;255;3;0;3;" :
log( "Sensor has requested a new ID" )
assignFreeID()
def arduinoWrite(sendMessage):
global logbool
strParts = sendMessage.split(";")
length = len(strParts[5])
strPartsMsg = strParts[5]
print "sending: "+sendMessage
chunkSize=22
if length > chunkSize:
msgHeader=strParts[0]+";"+strParts[1]+";"+strParts[2]+";"+strParts[3]+";"+strParts[4]+";"
end = int(round(length/chunkSize-0.5))
for i in range(0, end):
msgPart = strPartsMsg[(i*chunkSize):((i+1)*chunkSize)]
print "chunk: "+ msgPart
serialPort.WriteLine(msgHeader+msgPart+"+")
time.sleep(0.1)
msgPart = strPartsMsg[((end)*chunkSize):(length)]
print "final chunk: "+ msgPart
serialPort.WriteLine(msgHeader+msgPart)
else:
serialPort.WriteLine(sendMessage)
print str
serialPort = IO.Ports.SerialPort(useComPort) #Which serial port which your gateway device is connected to
serialPort.BaudRate = 115200 #Baudrate for mySensors (must be 115000)
serialPort.DataBits = 8
serialPort.DataReceived += Ondata #function to call when serial data arrives from the gateway device
serialPort.Open()
log( "Serial connection established" )
vc.triggerEvent("MySensors.GatewayReady",None)
You can get this code to load at startup with something like this command:
<?xml version="1.0" encoding="utf-16"?>
<!--VoxCommando 2.1.4.2-->
<command id="1196" name="load python" enabled="true" alwaysOn="False" confirm="False" requiredConfidence="0" loop="False" loopDelay="0" loopMax="0" description="">
<action>
<cmdType>PY.ExecFile</cmdType>
<params>
<param>PY\MySensors20150303.py</param>
</params>
<cmdRepeat>1</cmdRepeat>
</action>
<event>python ready</event>
</command>
-
an idea for the py script, is to change serialPort.xxx to mysensor.xxxx or something like that to avoid conflict of naming in case of adding another serial port ... I suffered with this when I added a second serial port to connect arduino and XAP800
-
I don't understand your .xxx notation so maybe I'm misunderstanding what you are talking about.
Are you talking about renaming the serial port variable (object)? If so, then yes this is a good idea, but if we made proper classes then it would not be an issue. In general if we create a lot of global variables without putting them into classes then we run the risk of future conflicts with other scripts.
-
Yes the variable serialport
-
Any news about this? I'm building separate nodes for controlling lights and reading from sensors and im very excited to try thr python programs that you mentioned. Thanks!
Here are some pictures from our working RGB-Controller. Dave has written a arduino sketch, which let you Dim, changing to any colour, blink in any colour, fade to any colour and much more. I will also record a new demo video which shows the RGB controller in action next time.
If you need more information about our pojects (Wireless IR-Blaster, Temp/Hum. Sensors), let us know.
https://dl.dropboxusercontent.com/u/24196410/20150328_111425.jpg (https://dl.dropboxusercontent.com/u/24196410/20150328_111425.jpg)
https://dl.dropboxusercontent.com/u/24196410/20150328_113820.jpg (https://dl.dropboxusercontent.com/u/24196410/20150328_113820.jpg)
https://dl.dropboxusercontent.com/u/24196410/20150328_111336.jpg (https://dl.dropboxusercontent.com/u/24196410/20150328_111336.jpg)
https://dl.dropboxusercontent.com/u/24196410/20150328_111407.jpg (https://dl.dropboxusercontent.com/u/24196410/20150328_111407.jpg)
https://dl.dropboxusercontent.com/u/24196410/20150328_111511.jpg (https://dl.dropboxusercontent.com/u/24196410/20150328_111511.jpg)
-
Thanks for the script and the further information! I'm now waiting for the radios to arrive, they shall arrive to me in Brazil in 3 weeks, but I'll start all the programming stuff anyway and will test what is possible until then
I've already done my parallel arduino light switches, but since it's parallel with another manual switch, I'm looking for a reliable way of the arduino telling if the light is on or off. Will probably need a current sensor in the relays or something like that.
-
Now I have upload a demonstration video with the RGB Controller to youtube in action.
www.youtube.com/watch?v=I0eQkpekIus
I will create a public folder at dropbox.com if anybody is interested to download the Command-groups, arduino sketch or python scripts
-
RGB-Controller with motion sensor in 3D-printed case ;D
-
Good job :clap
-
RGB-Controller with motion sensor in 3D-printed case ;D
Beautiful. ::bow
Here's a photo of the assembled RGB controller itself
-
RGB-Controller with motion sensor in 3D-printed case ;D
How cool is that? Super.
-
Cooooooolllllll
-
RGB-Controller with motion sensor in 3D-printed case ;D
that is sweet, I can't wait until I can get my hands on one of the Light sensors great job :yay
-
Hi,
really loving your work!
Do you guys have a tutorial to your Arduino WLAN RGB Controller? Which parts do I need for this? How does Voxcommando communicate with the wlan rgb controller? Which protocol is it using to accomplish this?
Keep up the great work and thanks!
PS: Are you selling the RGB Controller/Entire setup somewhere?
Simon
-
Hallo Simon, willkommen im VoxCommando Forum.
Ja es gibt ein "Tutorial" zu dem RGB Controller welches aber nur Sinn macht wenn Du einen Controller hast.
Du benötigst als erstes einen MySensors-Serial-Gateway: http://www.mysensors.org/build/serial_gateway
Bild 6 und 7: http://voxcommando.com/forum/index.php?topic=1921.0
Es kann auch alles für den Anfang auf einem Steckbrett gebaut werden - wird aber schnell unübersichtlich und zudem haben wir SMD-Bauteile auf dem RGB-Controllerboard eingesetzt, welche nicht mit dem Steckbrett genutzt werden können und diese müssten dann erst mit anderen Bauteilen ersetzt werden müssen.
Ja wir haben den Gateway sowie den RGB Controller sebst gebaut und wenn Dave noch ein PCB board übrig hat, könntest Du eventuell einen fertigen RGB-Controller und Gateway von uns erwerben. Hier benötigst Du lediglich noch den LED-Strip mit passendem Netzteil (12V, 3-5A je nach LED-Strip Länge) und unseren python script.
Wenn Du den Controller selber bauen möchtest, kann ich Dir eine Liste mit den benötigten Teilen geben sowie das Layout für das Board.
Bei interesse einfach eine PM an mich oder Dave ;)
Dieser Gateway wird per USB an dem PC angeschlossen auf dem VC läuft. Dieser Gateway kann Daten von den Sensoren (RGB, Temperatur, Feuchte usw.) empfangen und an den Serial-Port (CommPort) ausgeben. Mit einem von uns erstellten python-script liest VC die Daten an dem Commport und speichert diese in Maptables. Wie man Sensoren baut und was man braucht steht hier:
http://www.mysensors.org/build/temp
Ein Temperatursensor ist ein guter start für den Anfang. Man muss keine Programmiersprachen können, die Sensorskripts gibt es ebenfalls auf der MySensors Webseite und es ist alles sehr gut beschrieben.
Ales basiert auf Arduino-Hardware und der MySensor library: http://www.mysensors.org/download/sensor_api_14
Ich hoffe ich konnte Dir ein wenig weiter helfen,
Kalle
-
Wow Kalle, das ist Wahnsinn! Danke für deine Antwort! Ich werde mich heute einlesen und bestimmt mit einem Haufen fragen zurückkommen :).
Danke für die Mühe und bis demnächst!
-
Kalle just recorded a video with the RF/IR-Blaster we are currently working on 8)
Dave has done a great work with the code and hardware - a prototype PCB is now in production! ::bow :hugs
Kalle
-
Looks awesome. :yay
Your office is starting to look almost as messy as mine. Mad scientist!
-
Great! I'm going to build one myself as soon as I manage to finish my new controller code with support to ack and responses from/to sensors.
Nice job!
-
Looks awesome. :yay
Your office is starting to look almost as messy as mine. Mad scientist!
Haha, yes I call it "Bermuda Triangle", because everything what you have stored here will never found ;D
-
The IR module is exactly what I am looking for.
Any idea when we can buy it and also the gateway?
Best wishes.
James.
-
I think it is no problem after the boards are arrived and some test are done. The IR/RF Blaster board is already in production (3 or 4 weeks ago), so maybe it will arrive next time.
At the moment we have no gateway pcb board in stock and to order only one is a bit expensive - maybe some others are interested in this stuff, but it is possible to build you an gateway on a prototyping board or without a board which looks not so pretty like this one: http://www.mysensors.org/build/serial_gateway
I can say nothing about the price but maybe Dave has a idea ;)
-
Thank you Kalle,
I think I can have a go at the Gateway. I purchased the parts some time ago. However if you have parts, I would certainly consider buying an assembled IR blaster. Please let me know. I may be delayed in replying to any response as I am away for the next week.
Best wishes.
James.
-
One question: Why did you guys have chosen to store the IR codes on a SD card?
I suppose this DYI IR Blaster can not work standalone, meaning that it depends on something else (VC in this case) to tell it to either learn or send a IR packet. Hence I see no reason for saving the learned IR packets in the device memory instead of the PC memory.
My idea for building my own custom IR Blaster is that saving it on a database table on the PC would be much better than saving on the device itself. Am I missing something?
-
Hi Marcus, you are absolutely right! This is what we tried first. Basically there are two ways to store IR-Codes. The first way is to find out which type of code is recorded (NEC/RC5/RC6/Panasonic/...) and use typical patterns to generate short codes. The library we are using to receive IR can (in theory) do this. But it doesn't work with all remotes (e.g. my Samsung TV remote didn't work). That is why we use raw codes, which basically just store the time the IR led is on and off for each code. The problem with raw codes is that they are much longer, but the maximum length for a MySensors message is 25 characters. We already had a solution where we splitted the code and added a "connector-character" to each message except the last and put the code back together with the python script. But we had problems with lost messages.
I recently bought some ESP8266 Wifi moduls. If I find some spare time, I will have a look at this and see if we maybe can run a little web server on the arduino. So we could create a IR/RF blaster which can be used as a standalone device and be controlled over a website and tcp/udp/http requests. I'm nearly sure this could be done, but it would be a lot of work and I'm not sure if it makes much sense, since my PC is running 24/7 anyway... :bonk
-
Dave, do you know what's the size of this RAW data in bytes for each package?
I suppose each byte of such raw data contains the time in micro or mili seconds that the input pin was high or low (1 or 0). This way, the protocol is irrelevant because once you alternate the output IR led again on the same sequence and timing, it is just acting exactly as the original Remote Controller.
If I'm right above, I'm wondering if it's possible to convert the data back to bytes on a shorter message, creating a intermediary data format that would be used only to send data back and forth between the computer and the arduino. The arduino would then translate the data back to original format before emitting such data through the IR led.
For example, if I send 64 bytes of data in an IR packet (lets say, the On button of the remote controller). Then, depending of the protocol I may have a maximum of 64 bytes * 8 bits = 512 bytes, each containing the timing of each bit. In reality, if I'm captuing raw data, there are also the control bits, like the start bit, the stop bit and the parity bit, which could turn the space necessary to store the data for a single IR packet to a total of 704 bytes!. But then, not all bits will be different, for example, one byte being recorded could be FF, meaning the raw data for this byte would be a long 1, stored in one single byte instead of 8 like I was saying. Anyway, I see how this can be a nightmare, but maybe there are alternatives?
Just a thought...
Otherwise, I can imagine many reasons for the data being lost when you divide it in many packets of 25 bytes. Where is the data being lost?
I'm just trying to help. I'll probably face the same problems once I try it myself, so I'm deeply interested.
-
68,4500,4450,550,1700,500,1700,550,1650,550,600,550,550,550,550,550,550,550,600,550,1650,550,1700,500,1700,550,550,550,550,550,600,550,550,550,550,550,1700,550,1650,550,550,550,1700,550,550,550,550,550,550,550,600,550,550,550,550,550,1700,550,550,550,1650,550,1700,550,1650,550,1700,550,
This is how a code for my Samsung TV looks, but there are codes for other devices which are at least 50% longer.
I'm not sure if I understand all of what you wrote. I tried to shorten the code, but the shortest I could come up with were codes with ~75 characters (converting the raw code from dec to base62). Another problem was the low ram of the arduino while converting those codes, but that is probaly because of my poor programming skills.
Otherwise, I can imagine many reasons for the data being lost when you divide it in many packets of 25 bytes. Where is the data being lost?
The data was lost between the sensor and the gateway. Most of the time not all messages could be received.
I'm just trying to help. I'll probably face the same problems once I try it myself, so I'm deeply interested.
Your help is always appreciated! When you are ready to try it and have any questions or want to see our attempts (sketches/py/hardware), just write a mail!
-
If I'm right, each of the values you see in this data that has been recorded by the library you're using in your arduino is the time spent before a bit changed from low to high (or vice versa).
This means the status of the digital pin which is reading from the IR receiver have changed its status as many times as the quantity of numbers registered, and each number individually means the time that pin stayed on the same state. As we have large values, two bytes are needed to register each bit time. One single bit (could use the most significant one) could be used to store the state (zero or one).
This is a technique that one can use to repeat data when the protocol is not known whatever is the protocol used, if you repeat the exact same bits in the same timing, that will result in the exact same data in the end. When the protocol is known, you can read bytes instead because either the hardware or the software knows in advance how the data will come (how in the lowest level, in the bit level)..
So reading from the first, the input pin stayed in a specific state for 68us (I wonder it's recording in microseconds), then changed to the opposite state for 4500us and so on.
This is kind of a poor's man oscilloscope recording. I've done that in the past for reverse engine a digital protocol.
-
As Dave has pointed out, we need to use the Raw method so that it can work with virtually any device. Raw codes can be quite long, and the maximum size for the MySensors API that we are using is 25 bytes (or characters since that is how messages are passed).
The iTach has a simple but effective method of compressing raw codes. Here is a sample compressed code for controlling my Samsung TV:
sendir,1:3,1,37993,1,1,171,171,21,64BB21,21CCC21,22BBBDDCDCBBDBDBDDDDBDBDBB21,4863
Keep in mind that this is just a sample code, and there could be other codes out there that are longer.
I don't fully understand how this code works, but obviously the letters stand for some number. Instead of writing 250,450,450,250 we can write BDDB etc. Other information is included such as what frequency is used (usually about 38K so we could probably drop this) and what the actual letters stand for. So what is the shortest code you could possibly come up with to represent this? Is that less than 25 characters?
Probably there is a way to do it. Using a whole byte to represent a letter is very wasteful. We could actually use a byte to represent 4 letter codes. A single byte is 8 bits.
00 = A
01 = B
10 = C
11 = D
BBCA would be represented as 01 01 10 00. This could be stored in a single character (decimal value is 88 or ascii letter 'X'). This is assuming that the protocol actually allows any byte value from 0-255. It might only work with ascii characters... I'm not sure.
We would also need to send information about what each letter stands for. Also, there will probably be more than 4 different pulse widths, so anomalous lengths would probably have to be sent directly somehow.
All to say, it might be possible to get it so that MOST codes could fit into a 25 byte message, but it won't be easy, and I think it's highly unlikely that it would be possible for ALL device codes.
This leaves two options.
1 - Use an SD card to store it on the device or do something similar.
2 - Send the message in parts.
or...
3 - Use short protocol codes when they can be detected and fall back to raw codes only when necessary. This would be nice, but does not actually remove the need to find a solution to handle raw codes.
4 - Don't use MySensors (just use an Arduino directly connected to via serial USB to your PC - easy fast cheap solution, but not wireless!)
Again, as Dave has pointed out, for option 2 we have run into problems with the fact that the MySensors protocol running on the NRF chips is not 100% reliable. The error checking is not perfect. I occasionally get weird messages from sensors that do not exist (the ID is transmitted incorrectly) or a temperature reading of -240 degrees etc. If we send multiple longer messages we increase the likelihood of errors. So we would need to implement our own error checking and possibly ask for the codes to be resent if we detect an error. This is also possible, but again, not a trivial task!
-
So reading from the first, the input pin stayed in a specific state for 68us (I wonder it's recording in microseconds), then changed to the opposite state for 4500us and so on.
I believe that the first number in Dave's example -- 68 -- actually indicates the full length of the IR code. That is, it indicates that 68 numbers will follow.
-
nime5ter, yes it is more likely to be the lenght. If you look at it, it recorded 67 numbers which refer to 67 bit times. BUT one important thing to notice is that the smallest amount of time you see in the data is 550 and I guess any larger value that you see there represents a period of time that the input pin of the arduino stayed for more time in the same logic state. So, when you see 1700 or 1650, it means 3 times the single bit time.
This is not necessarily pure data. Protocols as manchester for example use 2 halfs of a bit to represent a single bit value.
Anyway, I think it is crazy to reverse engineer a protocol nowadays. Most things are already done, we just need to adapt it. That's why I'm interested in looking at this, wondering if I can help with something.
-
James, I believe the correct way is to add support to the standard Samsung protocol or use a library that supports Samsung.
If the library does not support the protocol natively, then we can always reverse engineer it like I just did with Dave's capture.
It took me more time to make Excel to plot the graphic like I wanted than to actually make the reverse engineering, lol!
This graphic attached is a representation of how the data captured by Dave would look in an oscilloscope. Plus it shows what I was trying to explain.
From this analysis, now I know the code for the button that Dave has captured is actually 0xE0E0D02F (4 bytes long) which fits perfectly in the My Sensors max payload limit of 25 bytes.
The problem with Dave's sketch is one of:
1-The library used does not support the protocol as I showed in the graphic.
2-The library used must be configured correctly so it supports the right protocol.
I'm not sure because I did not have the libraries yet, nor I have researched about them. I only know that there are two well known: IRlib and IRremote.
Either way, I must say it looks really easy to write the sender/receiver routines by myself for this specific protocol. What I mean is that I could write a sketch to support this protocol and consequently we would save in in the PC only the code 0xE0E0D02F plus some extra information that can tell to the arduino what is the actual protocol to use when sending that data through the IR led. The data could easily go into a data table in VC.
This is the easy part.
The difficult part IMHO is to get someone else's code (specifically these IR libraries) and understand how the it does to automatically detect and switch between each protocol when receiving (learning) IR pulses (which in fact are digital 1s and 0s). I suppose that except in this Samsung TV that you guys are having trouble with, the arduino does already switch automatically when learning a new code, right?
If so, then it means the library has some intelligence to detect and switch to a receiving protocol so it can translate the packet and keep the actual code while removing the extra bits (like start bits, stop bits, etc.)
I'll try to start developing a sketch for my own IR blaster on monday. Unfortunately my TVs are either LG, Sony or AOC, so I cannot test the Samsung case myself for now, but I'll need to support it in the near future.
My plan is to use some of the publicly available IR libraries and I really hope I don't have to fix anything on them.
If you guys have more details about what libraries you have used and how you were getting errors with the samsung tv, I can maybe help and get my own code compatible with those tvs.
For example, if you try to learn an IR code using the standard IR receive routine from the lib, what is the captured code for the same button?
-
Dave, Is the button that you sent the raw data the Volume Down?
-
Hi Marcus,
we are using the IRremote library.
You are right, it is the code for volume down and the hex code you showed is exactly what I get with the library. But sending this code did not work. If I remember correctly, Kalle got this code to work, when he manually changed the sending routine to use the NECx protocol.
I think even if you manage to change the library, so it can identify the right protocol for Samsung, there will always be some devices where it does not work. E.g. Kalle has a reciever by Unitymedia. He wasn't able to learn codes for this device with this library and even not with his Global iTach, but it does work well with our receiver using raw codes.
There is another benefit of the raw codes: you can easily convert them to the commonly used Pronto Codes. My plan is to name the files with the IR codes after the function and put them in device specific folders on the sd card. Then I want to use Pronto codes instead of the "normal" raw codes. So you could just download the Pronto codes for your device, put it on the sd card and use it with VC without learning every single button yourself.
Edit: Ok, I just saw that using the IRlib library, I can detect the correct protocol (NECx) for my Samsung remote. But there will still be some exotic remotes where it will not work. So I personally would stick with the raw codes. But it shouldn't be too hard change the sketch to send the short codes and the protocol to VC, since this is what I do with the RF codes already.
-
Dave, :o I was not considering the out of standard remotes, which indeed are equally important.
I agree that raw codes should be used for more compatibility. They are more reliable most times and supposedly will work with any remote.
Be aware however, that the IR library that you are using may have a maximum length limitation for saving raw codes. For example, Air Conditioner remotes usually send the full config every time you press a button (kind of a sync between what you see on the remote LCD and the A/C unit). These may be very large packets of data if we are looking only to the bytes. But then it is worse, as you are tracking bits instead of bytes, then the size grows a lot. Add to it that most over the air protocols will have a single bit composed by two bits (just like I showed in the graphic) and hence there are more raw data to save.
So, if instead of 68 bit times you have for example 680? Would it still be able to save it?
Regarding the use of a SD card (which is the reason I started this discussion), I still would like to keep it away from my circuit just for simplicity. But I agree that it has its advantages. Just like you guys, I'll prioritize compatibility.
One last comment since you mentioned the limited size of memory in the arduinos. For saving only raw codes, maybe you can fire away the IRremote lib. I'll explain.
I did not get into details, but I suppose the lib has some significant amount of code (and presumably use of ram) to deal with each protocol, etc. But for saving raw codes, all you need is to monitor the state of the input pin of the arduino (which is connected to the output pin of the IR receiver chip) and use the timer to count the time between each change of state. The timer is a hardware feature on these microcontrollers and it counts time infinitely.
You'll attach an interrupt for that pin and keep looping until the current pin state is different from the previous. Once a change has been detected, you will have an interrupt that calls a function.
On the function that has been called, you will reset the timer because the pin has changed its state and you need to start counting the next one. And you will also save the time elapsed since the last state change in an array.
Once an idle state has been detected, ie a lot of time has passed without any changes to the pin state, you are finished and can save the entire array to the card.
What I mean, is that maybe its better to write you own functions to save the raw data because you don't need all the extra stuff that the library potentially have.
Thanks for the discussion and please keep us updated! ;)
-
Hi Marcus,
yes I'm planning to get rid of the IR library. I already have some code working without the library, which (hopefully) should be able to read those long AC codes, and I will try to integrate it in my sketch soon. Unfortunately I don't have one of those ACs (35°C today, I really wish I had one...), so I can not test it.
-
Unfortunately I have a long way before I get the IR Blaster done here. Otherwise I could run the test for you guys.
-
Dave, the codes are already available in the Logitec Database ;)
and they are really longer as a normal TV remote code, but I was able to capture this code with our IR-Blaster. This is no guarantee if it will work - I can check it at work with a Panasonic AC tomorrow.
-
The pcb boards arrived! 8)
I already assembled one and everything works fine! ;D
-
SAWEEEEET! ::banana ::banana ::banana
-
You guys are doing great stuff ... Wish I had more time to catch up ....
-
And this is how it looks fully assembled and ready to go :D
The size is ~ 65 x 45 x 32 mm
-
Yeahhhh, mine is also finished and works perfectly!
Now it is time to build a case with my 3D printer.
@Dave: If you have any idea for the 3D print or a STL file let me know ;)
-
Hey guys, just a quick update on the IR/RF-blaster:
You can now specify a folder and filename to save the IR code on the SD card when you learn codes with VC. Before I just numbered the filenames consecutively. I also was able to add support for (long) Pronto Hex codes! So now it is possible to just download codes for your device, put them on the SD card and use them with VC. 8)
The next point on my To-Do-list is now to add support for the new self-learning RF remotes.
-
GREAT JOB Dave, everything works perfect!
::bow :yay
-
I'm trying to follow along with what you all are doing here. Is the IR blaster a wireless one that receives its commands from VC? Maybe I'm just confused.
-
This is a custom universal IR Blaster, developed specifically for working with VC, conforming to MySensors (http://mysensors.org) protocol.
These guys have developed also a MySensors controller which is integrated with VoxCommando, so that commands said in VC can be converted to MySensors format in your PC, then sent to the serial gateway which is attached on your PC, and from there sent via radio (wireless) to the IR Blaster.
So, yes, this is what you think it is.
-
For those who don't already know this, MySensors is also compatible with Vera controllers. I'm not sure if the RBG and IR/RF stuff works with Vera or not, but all the sensors for motion, temp, humidity, light switches etc. do.
So you have the option if you already own a Vera of either connecting a MySensors gateway to your PC running VC and using the python code we have developed, or you can connect the bridge to you Vera controller and talk to it from VC through the Vera plugin.
-
hi,
i am really interested in building something like this for my setup but i don't know where to begin.
Is there a guide for this specific project and a list of items that are needed?
Thanking you in advance.
-
Hi bnikos83 and welcome in VC-Forum.
Yes, you can start from here: www.mysensors.org (http://www.mysensors.org)
There are a lot of examples and very good explained.
Which of the project do you mean? RGB controller, IR/RF-Blaster, temp/hum sensor ;)
-
Hi Kalle and thank you for your quick reply.
I am referring to the IR/RF-Blaster project.
I have allready browsed through www.mysensors.org but i was hoping for a more specific guide for the IR/RF-Blaster project which maybe i am missing.
Thank you again.
Nick