Building of a wireless sensor box

[sweetpi]

The next big thing is to build some open hardware sensors for pimatic.

The Quest is to build a hardware 433mhz sender based on arduino or a ATtiny AVRs that collects environment data like light intensity, temperature, humidity and motion.

I already did some work with a ATtiny. I think it shouldn't be to hard to extend this.

Design goals are: Low Cost and battery powerd.

I would do it myself but want to focus on developing/stabilisation and documentation at the moment, so help would be nice :)

[thexperiments]

Great idea, sadly I, as you have already noticed, have not very much time
:(. But if there are any questions or problems you want to discuss just
ask. I also know HW development including PCB Layout and lowlevel MCU
programming.

2014-02-24 9:14 GMT+01:00 sweetpi notifications@github.com:

The big next thing is to build some open hardware sensors for pimatic.

The Quest is to build a hardware 433mhz sender based on arduino or a
ATtiny AVRs that collects environment data like light intensity,
temperature, humidity and motion.

I already did some work with a attinyhttps://github.com/sweetpi/attiny-433mhz-sender.
I think it shouldn't be to hard to extend this.

Design goals are: Low Cost and battery powerd.

I would do it myself but want to focus on developing/stabilisation and
documentation at the momenet, so help would be nice :)

Reply to this email directly or view it on GitHubhttps://github.com//issues/74
.

[bjoerns1983]

Just starting with pimatic, because it is the first good looking project which can handle my Intertechno devices by default.
I like the idea of the environmental sensors based on the ATtiny. Especially if you send them to sleep they are ideal for battery powered usage. For example to measure temperature and humidity in every room.
The question for my is if it would make sense to first make up our minds about the protocol how to send and receive the data and than build the hardware.

Some nice inspiration about the hardware could be found here for example:
http://www.3bm.de/2013/09/15/batteriebetriebene-funk-temperatursensoren-fuer-arduino/

Or we could use the TinyTX Sensors: http://nathan.chantrell.net/tinytx-wireless-sensor/

[sweetpi]

I like the idea of the environmental sensors based on the ATtiny. Especially if you send them to sleep they are ideal for battery powered usage. For example to measure temperature and humidity in every room.

Fully agree.

The question for my is if it would make sense to first make up our minds about the protocol how to send and receive the data and than build the hardware.

I would use pilight for receiving, so we have almost nothing to build at the receiver side. We could just use on of the existing implemented protocols for temperature and humidity. The only remaining Problem would be integrating light intensity and motion detection. We would have to implement a additional pilight protocol for that.

Your given readings are looking very interesting. The TinyTX would be a nice sensor. What I don't like is the expensive HopeRF module but it looks like there is a version that uses the cheap OOK/ASK sender.

[bjoerns1983]

You are right the Hope RF Modules are expensive. But they have some advantages for example an integrated sleepmode and we should not forget that these modules are transceivers. That save some space and cables.

I like the idea using an existing protocol that would make things much easier.

[sweetpi]

But do we need receiving capabilities for the sensor? I think both RF modules are ok. But these OOK/ASK senderes are so extremly cheep and easy to use. But supporting both or just the Hope RF module in the beginning would of cause be another option.

[elektronaut69]

Have a look at this thread: http://www.forum-raspberrypi.de/showthread.php?tid=7472

They have developed a rf sensor. Even a PCB is available. I did not have a look at the protocols so I do not know if it will work with pilight/pimatic.

[bjoerns1983]

Unfortunately i have no RFM12B at hand, but maybe i have some time this weekend to tinker around with my arduino und my Low Cost 433MHz sender.

[sweetpi]

Unfortunately i have no RFM12B at hand, but maybe i have some time this weekend to tinker around with my arduino und my Low Cost 433MHz sender.

Would be cool.

[bjoerns1983]

Tried a bit last night, but the simple problem is that i dont get my RF receiver working with pilight, the transmitter is no issue. Also i have seen that the description in the pilight wiki does not directly reflect pulse lenght etc. Maybe it would be simpler to create a completely new datagram for the "Pimatic"-Sensor. But first i have to get my receiver running in combination with pilight.

[sweetpi]

Tried a bit last night, but the simple problem is that i dont get my RF receiver working with pilight, the transmitter is no issue.

Which one are you using? http://wiki.pilight.org/doku.php/receivers

Also i have seen that the description in the pilight wiki does not directly reflect pulse lenght etc. Maybe it would be simpler to create a completely new datagram for the "Pimatic"-Sensor.

I think thats not a problem, we can calulate the pulse length out of the stated timings or do some trial and error with pilight-debug. But the advantage of a own protocol would be that we could include a checksum and detect transmission errors.

Just read that @koffienl has already build a temperature sensor that is workgin with pilight: http://koffie.tweakblogs.net/blog/9847/diy-draadloze-temperatuursensor-voor-pilight.html

@koffienl: Could you give some details (in english) how you are getting the data into pilight?

[koffienl]

The post you mentioned talks about my prototype. Offcourse, as a nerd who is automating his household, I allready have taken the prototype in production ;)
What I currently have is a attiny with a DS18B20, sending the temperature every minute to pilight.

First prototype was sending the temperature by abusing the KaKu dim protocol. If the temperature is 15 of less, it uses ID 1, when between 15 and 30 degrees ID 2.
When the information was received by the pilight-daemon, a process/event script would take the info and resend it to a generic_weather.

Because our main goal was/is to build a same type of device as mentioned by @sweetpi we adopted the KaKu_dim protocol into a new prtocool.
For now it is called the probe protocol. With the protocol you can send a ID (similar to the KaKu ID), a sensor number (1-15) and a value (0-1023).
We want to build a attiny-based module, with multiple sensors (temp, pir, LDR, IR-sender, ..)

At this moment, the prototype is powered by a USB-port on my TV decoder, so there is absolutely no powersavings and sleepmodes yet. Offcrouse, the main goal is to make it low-powered and standalone.

For now, pilight receives the probe-protocol and write it back to config.json My pilight process script detectes the incoming probe update and resend it to pilight as a generic_weather update.
When this generich_weather device is udpated, pimatic will follow it's rules to determine wether it should open or close a valve for central heating.

The modified protocol is build by a colleague from work, who is running the project with me. At this moment pilight is capable of receiving our protocol, and in theory sending the protocol.
The attiny is only capable in sending the protocol, whe have yet to write a receiving part for the attiny.
One of my big 'wannahave' for the module: pilight send a update to a specific module, which in return sends a IR signal. With this setup I could control the AC's in specific living rooms.
Because we are using a lot of 434Mhz device (a lot of KaKu devices), we are thinking of building 315Mhz sender/receiver in the modul, to offload battery-power.

[sweetpi]

The post you mentioned talks about my prototype. Offcourse, as a nerd who is automating his household, I allready have taken the prototype in production ;)

Same here ;)

For now it is called the probe protocol. With the protocol you can send a ID (similar to the KaKu ID), a sensor number (1-15) and a value (0-1023).
We want to build a attiny-based module, with multiple sensors (temp, pir, LDR, IR-sender, ..)

Great idea. So just one protocol is needed for all sensor types. Is the protocol and ATtiny code public available (open source). I would love to try it out.

One of my big 'wannahave' for the module: pilight send a update to a specific module, which in return sends a IR signal. With this setup I could control the AC's in specific living rooms.

I had the same idea. A 433mhz -> IR gateway would be cool.

[koffienl]

Problem is: the code is not completely finished yet.
If you want, you can send me an email and I can provide you some files to test with ?

[bjoerns1983]

+1 for an own Protocol. Would be good if it could transport min. two Values per Datagram, e.g. Temp and humidity, a sensor ID, maybe network id and Battery status. That could be saved into a byte array and than send over the virtual wire.

So IR Gateway would be an actor in this case the HopeRF modules would be worth a look at.

[koffienl]

Our idea was to specify eveything as a seperate sensor in the module.
15 sensors per module should be more then enough. For examples:
Sensor 1 = temp
Sensor 2 = humidity
Sensor 3 = LDR (lux)
Sensor 4 = movement (PIR)
Sensor 5 =
Sensor 6 =
[..]
Sensor 15 = battery status / low

[sweetpi]

If you want, you can send me an email and I can provide you some files to test with ?

That would be create. However a public github repository would be much greater, so we could build and test it together.

Our idea was to specify eveything as a seperate sensor in the module.
15 sensors per module should be more then enough. For examples:

Sounds good. I think it doesn't make a big differents if we send packages with single values or combine more values..

[thexperiments]

remember to add some error correction and crc to the protocol some
"lightweight" encryption would also be great

2014-03-11 21:17 GMT+01:00 sweetpi notifications@github.com:

If you want, you can send me an email and I can provide you some files to
test with ?

That would be create. However a public github repository would be much
greater, so we could build and test it together.

Our idea was to specify eveything as a seperate sensor in the module.
15 sensors per module should be more then enough. For examples:

Sounds good. I think it doesn't make a big differents if we send packages
with single values or combine more values..

Reply to this email directly or view it on GitHubhttps://github.com//issues/74#issuecomment-37344445
.

[koffienl]

We don't have such options on a roadmap ;)

[sweetpi]

We don't have such options on a roadmap ;)

Do you plan to make your code open source? That would rise the chances to be well supported by pimatic extremly :)

[koffienl]

Sure it will, it basicly is a simple fork from the KaKu_dimmer protocol.
By the way : again .. the code is not written by me bu a colleague ;)

[koffienl]

Changed the behavior of the protocol a bit yesterday.
The device config in pilight is changed to this:

"probe": {
"name": "Probe Device",
"uuid": "0365-00-00-65-000300",
"protocol": [ "probe" ],
"id": [{
"id": "8934000"
}],
"movement": 0,
"temperature": 206
},


So, all the sensors (1-15) are put into the device object of the corresponding ID.
Now it's time to define what kind of sensors there should be in de the module and list them in the protocol.

These are the sensros we would like to use:

• temperature
• Humidity
• movement (PIR sensor)
• level of light (LDR sensor)

Any ideas for other sensors to add to the module? It should be a universal standalone module, that you can please in every room you like to gather information.
Other ideas are also more then welcome.

One of our biggest concerns is power consumption. We think we can reduce consumption by adding a very small second attiny based on the new band-filter from the pilight project. When received signals validate the protocol, it is allowed to wake up the main microprocessor at an interrupt. Also changing communication from 433Mhz to 315Mhz should rule out a lot of useless signals

Again: ideas are more then welcome

[sweetpi]

Sound great.

Any ideas for other sensors to add to the module?

A carbon dioxide (CO2) sensor would be cool, but seems to be very expensive.

One of our biggest concerns is power consumption. We think we can reduce consumption by adding a very small second attiny based on the new band-filter from the pilight project.

I don't understand why adding another Attiny should safe power. To reduce power consumption we have to dynamically lower the clock rate of the Attiny to the minimum needed, use sleep mode when possible and shut down power of all unused sensors, when they are not needed.

Also we should really add some error detection/correction codes like CRC or hamming codes.

Also changing communication from 433Mhz to 315Mhz should rule out a lot of useless signals.

Don't know for what these 315Mhz frequencies are used here in Germany, but no option for me because it it's not legal to use these here.

[elektronaut69]

If we want to measure air-quality a VOC-sensor could be an affordable alternative:

http://www.exp-tech.de/Sensoren/Seeed-Studio-Grove---Air-Quality-Sensor-1-0.html

http://www.voelkner.de/products/186298/Gassensor-Figaro-Tgs2600-B00.html

The power consumption of these sensors is very high though because of the heating.

[koffienl]

@sweetpi regarding the power consmption : every single type of noise would trigger the RF-receiver interrupt on the attiny.
My idea was : add a second, small, low powered attiny. The only thing it has to do : watch if all the jiberish match our protcol. ONLY when it is our protocol it is allowed to wake the main attiny and pass through the received code.
Just a brainfart for lowering power consumption :)

On the other hand : I personally can live with the fact that the module is powered with a 5v USB wire. Can be easily tucked away.

I had some strange issues with my prototype last days. The problem was : I no longer received info from the probe.
It happened at the moment I did some minor changes on the attiny code AND pilight code the same time.
Reverting everything didn;t solved te issue. Took me a few days to find out attiny decide to compile an older version of the library (located in the same folder).
No it's working again :p
I added a DHT11 sensor for the humidity (the temperature readings from DHT11 are less accurate than a DS18B20), works like a charm with this library : http://playground.arduino.cc/Main/DHTLib#.UyMXevldWCQ

edit:
Current prototype :

[koffienl]

I posted the tranmsitting (attiny) and receiving (pilight) code online : http://forum.pilight.org/Thread-Idea-PIR-wireless-motion-sensor?pid=4483#pid4483
Would be great if someone would take the project and make the attiny code capable of receiving and the pilight part capable of transmitting.

[sweetpi]

I posted the tranmsitting (attiny) and receiving (pilight) code online : http://forum.pilight.org/Thread-Idea-PIR-wireless-motion-sensor?pid=4483#pid4483

Great thanks for sharing! I will upload it to a github repository to manage changes. Whom should I mention as original author? Do you want some special license? (I would use GPL 2.)

[koffienl]

The actual code is written by co-rowker from work. His name is Michael.
I would just use the default GPL that the original code(s) has.
The newRemote for attiny is published with GPL v3, I'm not sure what GPL version CurlyMo uses for the pilight code.

Feel free to copy/use/alter the code. Let 's make a universal protocol capable of sending enough information to house all the sensor information in one module.

[Icesory]

Exact this is my RF-IR-Remote. It received 433MHz Kaku commands and sends a stored IR Command. So i can control home cinema with pimatic.
It is recomend to use the HomeduinoRFButtonsdevice. It is make for this xD
Ok i see a english documentation is needed. And now i stop hijacking this issue. new questions in a new issue or in my repository

[koffienl]

No pleae hijack this topic!
This is what the topic and box shoudl be : something we can ll put our stuff and ideas in and share code.

My first try for code sharing can be found here: https://github.com/koffienl/pimatic-probe

[Rantir]

Jeah, stay here Icesory i guess if we pull the stuff together this could be quite nice.
The Point is, so many ppl started to make somethink wirh homeautomation, but everyone did a little brick and now we got a bunch of bricks, but we need a nice wall ;)

Well, i see i need to buy some Hardware, what hardware are u using ?

[incmve]

Ok I have my first RF multi device.
atm only with a DS18b20 sensor with the arduino nano.
I took @koffienl his attiny code and changed is to arduino.

Any one wanting to test.
The code is on koffie his Git, he already merged the "arduino changes" in it:
https://github.com/koffienl/pimatic-probe

[koffienl]

Currently working:

• DS18B20
• DHT11

shortlist todo:

• Relay of kaku code
• PIR
• LDR

Prio for me is the relay. The idea is to configure pimatic device with a 'fake' unit/ID that is not configured on the receiver. When the specific modules receive the fake code, it will resend it using the correct code. When a kaku sender is sening with its real code, the probe will resend it using the fake code.
With this approach you make the box a sort of gateway, without any issues when some transmit happens to reach from pimatic to the kaku_device (or vise versa)

[incmve]

I got the sonar working if you want it

https://github.com/incmve/generic-rfbox/blob/development/sonar-ds18b20.ino

[jrot]

@incmve & @koffienl your code runs fine on my arduino mega. Keep up the good work.
Will purchase some extra arduino nano's.

Would be nice to log energy usage with it also.

[koffienl]

Nice :)
Got some KaKu retransmit/proxy code in development branch, not tested yet

[koffienl]

Guys .. I really need some coding help, I don't see where my problem is.

I have a working prototype with the following hardware:

• Arduino Nano clone
• Superheterodyne RF 433 sender & receiver
• DS18B20
• DHT11
• IR LED

Currently, this is what the sensor is capable of:

• Read temperature from DS18B20 and send as generic protocol
• Read humidity from DHT11 and send as generic protocol
• Interrupt on receiving valid KaKu protcol, do some stuff
• Sending IR signals

Now my problem is as follow: Every seperate function/module works perfect standalone. The problems start when I put it all together.
For sending IR code, I use the RAW data, because I want to send big bursts to my AC (not supported by the IR lib).
I want the module to send specific IR commandsm, based on KaKu command (receive a ON signal on a specific address -> send AC on with IR. Receive a OFF signal on a specific address -> send AC off with IR).

The KaKu->IR code is this part:

  if (receivedCode.address == 8934706 && receivedCode.unit == 9 && receivedCode.switchType == 0) {  
      Serial.print("receive 8934706-9 OFF \n");
      for (int i = 0; i < 2; i++) {
        irsend.sendRaw(AClivingOFF, AClivingOFF_len, 38);
        delay(100);   
      }
  }

For sending a ON signal, I would use

  if (receivedCode.address == 8934706 && receivedCode.unit == 9 && receivedCode.switchType == 1) {  
      Serial.print("receive 8934706-9 ON \n");
      for (int i = 0; i < 2; i++) {
        irsend.sendRaw(AClivingON, AClivingON_len, 38);               
        delay(100);           
      }
  }

The problem is : the moment I use 2 different variables for the irsend.sendRaw command, the entire module gets buggy.
I have pinned it down to the combination of the IR code and the DS18B20. When I strip off all the DS18B20 code from the project but use 2 different IR variables) everything works.
If I keep DS18B20 and use the same variable for irsend.sendRaw everything is fine.

So, this works:

  if (receivedCode.address == 8934706 && receivedCode.unit == 9 && receivedCode.switchType == 0) {  
      Serial.print("receive 8934706-9 OFF \n");
      for (int i = 0; i < 2; i++) {
        irsend.sendRaw(AClivingOFF, AClivingOFF_len, 38);
        delay(100);   
      }
  }


  if (receivedCode.address == 8934706 && receivedCode.unit == 9 && receivedCode.switchType == 1) {  
      Serial.print("receive 8934706-9 ON \n");
      for (int i = 0; i < 2; i++) {
        irsend.sendRaw(AClivingOFF, AClivingOFF_len, 38);               
        delay(100);           
      }
  }

This also works:

  if (receivedCode.address == 8934706 && receivedCode.unit == 9 && receivedCode.switchType == 0) {  
      Serial.print("receive 8934706-9 OFF \n");
      for (int i = 0; i < 2; i++) {
        irsend.sendRaw(AClivingON, AClivingON_len, 38);
        delay(100);   
      }
  }


  if (receivedCode.address == 8934706 && receivedCode.unit == 9 && receivedCode.switchType == 1) {  
      Serial.print("receive 8934706-9 ON \n");
      for (int i = 0; i < 2; i++) {
        irsend.sendRaw(AClivingON, AClivingON_len, 38);               
        delay(100);           
      }
  }

But this does not work:

  if (receivedCode.address == 8934706 && receivedCode.unit == 9 && receivedCode.switchType == 0) {  
      Serial.print("receive 8934706-9 OFF \n");
      for (int i = 0; i < 2; i++) {
        irsend.sendRaw(AClivingOFF, AClivingOFF_len, 38);
        delay(100);   
      }
  }


  if (receivedCode.address == 8934706 && receivedCode.unit == 9 && receivedCode.switchType == 1) {  
      Serial.print("receive 8934706-9 ON \n");
      for (int i = 0; i < 2; i++) {
        irsend.sendRaw(AClivingON, AClivingON_len, 38);               
        delay(100);           
      }
  }

My code is on github: https://github.com/koffienl/pimatic-probe in development branch.

[Icesory]

I think you use to much ram.
Try to set the stored AC-IR code as a const array.
Like this
https://github.com/Icesory/Rf-Ir-Remote/blob/master/RF_IR_Remote.ino#L37

[koffienl]

Thanks, I was allready guessing it has somethin to do with memory/buffer.
I tried to recreate the code from scatchm piece by piece, and it stopped working at a certain amount of serial prints.

When I change unsigned int AClivingON[] = {3420, 1592, 500, 1128, 464, ... to const unsigned int AClivingON[] = {3420, 1592, 500, 1128, 464,... I get the following error :

sketch_nov26a.ino: In function 'void retransmit(NewRemoteCode)':
sketch_nov26a:365: error: invalid conversion from 'const unsigned int*' to 'unsigned int*'
sketch_nov26a:365: error: initializing argument 1 of 'void IRsend::sendRaw(unsigned int*, int, int)'

Probably something obvious, but I'm no coder :(

[koffienl]

After reading some extra info today, I guess it has something to do with using to much RAM. I could store the long IR into PROGMEM, but that give other problems: http://forum.arduino.cc/index.php?topic=111179.0

If I cut down all my fancy debug text, it should give me some more space to do stuff.

[Icesory]

An const array is stored in the progmem. On the weekend I would look in to the Ir code the get an const array working.

[Icesory]

Sorry i have forgot you.
Go to this line in the IR library
https://github.com/shirriff/Arduino-IRremote/blob/master/IRremote.cpp#L114
and change it to this

void IRsend::sendRaw(const unsigned int buf[], int len, int hz)

[koffienl]

Sorry i have forgot you.
Go to this line in the IR library
https://github.com/shirriff/Arduino-IRremote/blob/master/IRremote.cpp#L114
and change it to this

No problem for delay ;)
I will try your change later, for now I have worked around to remove a lot of debug text and got it working.

Now, something different:
With all the extra homemade RF sensors, you get a lot of RF pollution, causing broadcast collision.
So one device sends info and the receiver is not aware of the new info.
This is not a big deal for a temperature update, but it is whem you try to turn off a homemade RF relay. Pimatic thinks it is turned off, but the relay never got the update change. When you add a talkback/confirm option on the receiver you are only making the problem bigger.

I found some bluetooth modules on ebay for the same price (or less) then a good RF kit.
If we could communicate with bluetooth then maybe we don't have this issue? With bluetooth you can communicate on MAC address.

The arduino part is easy: hook up on the rx and tx port, open a serial and you are done.
I have not found examples on how to initiate a BT connection from a arduino.

Is there anyone with experience on this? Can this solve our problem?

[jrot]

Take a look at this:

http://maniacbug.wordpress.com/2012/03/30/rf24network/

Already works on arduino and has Some battery powered models as well.

[Yves911]

I found some bluetooth modules on ebay for the same price (or less) then a good RF kit.
If we could communicate with bluetooth then maybe we don't have this issue? With bluetooth you can communicate on MAC address.

I like this idea, the benefit of 433 is that you can find a lot of HW for cheap, for homemade nodes i would also prefer to go to bluetooth LTE to avoid RF trafficjam

[bjoerns1983]

Biggest disadvantage of BT couldbe the limited range of these devices compared to the 433MHz RF equiptment.

[koffienl]

Biggest disadvantage of BT couldbe the limited range of these devices compared to the 433MHz RF equiptment.

Somehow I think the range could be the same. On the other hand : with some effort we could make a mash network ;)

[sebastienvg]

I'd like to get onboard with the "Remote Sensors Box" project. Can anyone list the requirements all in one place? Like what's needed on the raspberry (plugins and hardware) and what's the recommended remote sensor box setup.

[bjoerns1983]

Another option seems to be to go straight to WiFi instead of BT, for example with the very interesting ESP8266 SoC. Would only be the question how high the power draw is. I think it would be most useful if the sensor box could run battery powered.

Yep i also think that a Pimatic Forum or so would be great. Would it make more easy for beginners. I think i will setup my Pimatic HW over the holidays, than i might have time for that.

[koffienl]

Interesting! Costs seem to be the same as BT or RF kit. Personally I would prefer stable connections prior to battery power

[bjoerns1983]

Btw one German guy already did a nice example which could be useful: http://blog.schatenseite.de/archives/2014/09/30/wlan-mit-arduino-und-esp8266/

[leader21]

since this esp8226 is a SOC with GPIO and other stuff, could this be a single chip solution, without an arduino (sorry if this sounds stupidm but microcontrollers are not my world ;) ?
this sounds very interesting 'cause it's implemented into the wlan and not via rf.
but how about the power consumption on that? needs to be powered by a lithium battery i suggest.

[bjoerns1983]

Yep its a SoC but i dont know what possibilities you have with the cheap breakout boards your get from china. I think they are only meant to be used together with a microcontroller.
Nevertheless there is an SDK on the homepage of the manufacturer: http://bbs.espressif.com/, but i think the Arduino way is easier.

About the power draw, i think i read something about 80mA? But it also seems to support sleep modes etc.

[leader21]

well it can be set to deep sleep mode. could save some power.
here's an example how to setup wlan with an arduino
https://github.com/imjosh/espBasicExample
maybe this is useful for somebody.

[sebastienvg]

How about a fleet of these BlueDuino with BLE for low power and iBeacon capabilities for "future-proofness" and maybe make our pimatic "location aware" of sensors and/or users, and enhance pimatic-ping (could default pimatic tab on connection whether you're closer to this beacon or this one, create rules based on bluetooth presence or proximity). Ordering a couple anyway.

[koffienl]

I'm really exited about de the ESP8266 wifi modules. Ordered a few today :)
For sending data to external sources you have to use the AT+CIPSTART and AT+CIPSEND commands.
I think the easiest way to go is sending a PATCH update through the pimatic API. If anyone could help construct the commands to send with this module (I don;t know ow to send the user/pass)