I've been trying to integrate Serial Gateway directly into the Raspberry Pi following these instructions (https://github.com/mysensors/Raspberry) to no avail.

I run sudo ./PiSerialGateway and it creates /dev/ttyMySensorsGateway, which is a symlink to /dev/pts/1 (owner = root, group = tty). I symlink then /dev/ttyMySensorsGateway to /dev/ttyUSB020, which is recognised by domoticz under MySensors Gateway USB hardware.

In the controller log I see this error:

2015-10-22 21:57:34.881 MySensors: Using serial port: /dev/ttyUSB020
2015-10-22 21:57:34.881 Error: MySensors: Error opening serial port!

This is the output of running PiSerialGateway:

Starting PiGatewaySerial...
Protocol version - 1.4
Created PTY '/dev/pts/1'
Gateway tty: /dev/ttyMySensorsGateway
================ SPI Configuration ================
CSN Pin      = CE0 (PI Hardware Driven)
CE Pin      = Custom GPIO25
Clock Speed    = 8 Mhz
================ NRF Configuration ================
STATUS       = 0x0e RX_DR=0 TX_DS=0 MAX_RT=0 RX_P_NO=7 TX_FULL=0
RX_ADDR_P0-1    = 0xe7e7e7e7e7 0xc2c2c2c2c2
RX_ADDR_P2-5    = 0xff 0xc4 0xc5 0xc6
TX_ADDR       = 0xe7e7e7e7e7
RX_PW_P0-6    = 0x00 0x00 0x20 0x00 0x00 0x00
EN_AA       = 0x3b
EN_RXADDR    = 0x07
RF_CH       = 0x4c
RF_SETUP    = 0x23
CONFIG       = 0x0e
DYNPD/FEATURE    = 0x3f 0x06
Data Rate    = 250KBPS
Model       = nRF24L01+
CRC Length    = 16 bits
PA Power    = PA_LOW

Any clues?

@Yveaux said:

@Viper_Scull said:

#define BCM2835_GPIO_PADS (BCM2835_PERI_BASE + 0x3000)

Shot in the dark: could be a matter of braces.
Try:

#define BCM2835_GPIO_PADS               ((BCM2835_PERI_BASE) + 0x3000)

It doesn't work. Same errors.

The defines are used in bcm2835.c like this:

bcm2835_pads = (volatile uint32_t *)mapmem("pads", BCM2835_BLOCK_SIZE, memfd, BCM2835_GPIO_PADS);

A few more things:
·The compiler is called with these options:

gcc -Wall -fPIC -Ofast -mfpu=vfp -mfloat-abi=hard -mtune=arm1176jzf-s -march=armv7-a -D BCM2835_PERI_BASE=0x -c bcm2835.c

and in bcm2835.h we have:

#ifndef BCM2835_PERI_BASE
#define BCM2835_PERI_BASE               0x20000000
#endif

I checked the Makefile to see the flags and:

CCFLAGS += -D BCM2835_PERI_BASE=0x${IOBASE}

So, if I'm not mistaken, it's not getting anything from $(IOBASE) and it's defining BCM2835_PERI_BASE as 0x, and that's what causes the compilation to fail, right?

Checking what IOBASE is we find :

IOBASE := $(shell cat /proc/iomem | grep bcm2708_vcio | cut -f 1 -d "-")

but in /proc/iomem there's no bcm2708_vcio. This is the result:

00000000-3affffff : System RAM
  00008000-00775ccf : Kernel code
  007de000-0092378b : Kernel data
3f006000-3f006fff : dwc_otg
3f007000-3f007eff : /soc/dma@7e007000
3f00b840-3f00b84e : /soc/vchiq
3f00b880-3f00b8bf : /soc/mailbox@7e00b800
3f200000-3f2000b3 : /soc/gpio@7e200000
3f201000-3f201fff : /soc/uart@7e201000
  3f201000-3f201fff : uart-pl011
3f204000-3f204fff : /soc/spi@7e204000
3f300000-3f3000ff : /soc/mmc@7e300000
3f980000-3f98ffff : dwc_otg

Any ideas on this bcm2708_vcio??

The define is the line 350 of bcm2835.h, that's why I was puzzled. I won't be able to have a look at it again until monday. I'll see where it's being used and get back with the observations.

Thanks!

this is the error it spits:

error: invalid suffix "x" on integer constant bcm2835.h:350:28  note: in expansion of macro ‘BCM2835_PERI_BASE’

Well actually there are many erros, but all are the same. Looks like defining like this:

#define BCM2835_GPIO_PADS               (BCM2835_PERI_BASE + 0x3000)

is causing some error.

Do you see anything wrong here?

@epierre, already asked. Turns out, domoticz doesn't support V_VARs. Changing V_VAR1 in the sketch for V_DUST_LEVEL works.

@epierre said:

@Viper_Scull If you follow my method, it considers clean air has no toxic gas so it should be 0.

If you are able to do a calibration, you could change that, but I would recommend to keep the straight lean air way if you cannot do that.

@epierre I use the AirQualitySensor example in the MySensors library that I believe is your work indeed. Happy now to know that it's ok 0ppm for clean air.

One thing I noticed on the sketch is that last_mq inital value is 0. If we are in clean air, no value is send to the gateway when connected because val_mq = last_mq, so the controller would have no data to display unless it sets it to zero by default or gas is present.

By the way, I can't get domoticz to recognize this sensor. It receives the name of the sketch and the version, but although I can see that the sensor sends the value, there's no sign of it in the log of domotic and no device is recognized.

is it normal that the reads of my MQ-2 sensor are 0ppm in fresh air?
If I use a lighter to throw some gas, the reads skyrocket and then without gas they go back to zero.
Should I adjust the sensitivity?

@Vladut-Grecu said:

Oh.. for the gas sensor they are ok. Last one (green) seems a little bit more polished. The presence of the usb port is not important, you can solder it off. The usb is the output. Check the picture again. It's your choice.

Yes, you're right, it's the output. I didn't take a close look to the image. The green one seems more polished as you say. I'll try with those.

@Anticimex said:

@m26872 said:

Sorry, but the 220uA is drawn continously. Since most of my (and many others) battery applications have long sleep durations, the sleep mode power consumption is the first priority. Second is probably limiting the radio usage (meaning you can do things with just the arduino).

My take on low power measurement.
I have not gotten around to actually build it yet but I hope to do some measurements in my "lab" this spring.

That's a very interesting project. In the thread some of you say that if VBatt = Vcc (no regulator like I'd like to have) then using the divider to measure the charge is non-sense and it's way better to use the internal functionality, Am I wrong?

@Vladut-Grecu said:

Neither. Those will boost it till 5v. You need something like this.

But that one wouldn't be enough to feed the 5V that the MQ-2 gas sensor requires, would it?

Sorry, I've been swamped the last couple of days.

@Vladut-Grecu said:

Did you consider not recharging the battery over 3.3v? The nrf's 3.3v is a must. You can't go over 3.378v. (tested by me, before the poor little guy fried)

LiPo batteries should not go below 3V if I'm not mistaken, so charging it to 3.3V would make me recharge it more often. The sensor is for my folks because they still have butane gas for hot water, so I'd like it to last as long as possible. If, like you say, the chinese clon can't operate at more than 3.378V, I'll stick to 2 x AA batteries.

As the main power drain occurs when the sensor reads and the radio sends, I thought of measuring the battery just after that happens, which in this case it'd be like a minute or so. Therefore the extra cycles to read the analog input should be negligible.

About the step up converter, the store has a couple listed. This one http://goo.gl/1gwmm2 has a usb input and the other one http://www.ebay.com/itm/291352631612?rmvSB=true doesn't. The second one is better to use ion this case, isn't it?

@epierre said in Powering with LiPo a mini pro without regulator:

@Vladut-Grecu not really, but keep in mind that some sensors need to reach the needed temperature to be read, so you may need to heat for 10 minutes before reading and thus you will drain your battery. Also, even with a slepp, you may need an on/off on powering the gas sensor for it is continuously powered.

So you say the sensor would be continuously powered even though we do a gw.sleep?? The heater has a power consumption of 900mW.