@maghac @moskovskiy82 I came across this some time ago, with an RGB LED project. Whilst I can't recall the details, it's to do with setting the Arduino's PWM timers - apparently, the frequencies of the R(ed) & B(lue) channels can be close enough to causing 'beating', which gives rise to flickering. This statement changes the frequency of one of the channels slightly, thereby eliminating the flickering.

Separately from this, you can find a local 3d-printing service on 3dhubs.com - I found one local to me this way, who did my first print, which got me onto the 3d trail (I subsequently bought a Prusa i3 MkII kit).

...or you can use a 3d-printing service - email them the stl file (follow @dbemowsk's link above, to his Thingiverse page).

Your box looks really good!

Re bevelling: I did a quick Google for 'openscad bevel' - haven't looked at the results, don't know if any of these are what you want.

I've used openSCAD a few times now, to print enclosures, including MySensors and RaspberryPi's (note to self: must publish these here / on Thingiverse), and I like the way you can precisely define shapes through its structured language.

I recently came across an RPi case with rounded corners and edges, which was simply achieved by creating small spheres at each of the corners, and then producing a 'hull' around them:


Here's some simple code which I used to create the above examples:

// Rounded box example
r = 2;
box = [80, 40, 20];
hull_build(box,r);

//Utility module to make a solid box with rounded corners
module hull_build(box,r){
    //spheres at the corners of a box and run hull over it
    x = box  - 2 * [r,r,r];
    difference(){
    hull(){
        for (i=[0:1]){
            for (j=[0:1]) {
                for (k=[0:1]){
                        translate([i*x[0],j*x[1],k*x[2]]+[r,r,r]) //move up r because we moved box up
                            sphere(r);
                            }            
                        }   
                    }  
              }   
         }  
}

I'm using one of these : http://uk.tp-link.com/products/details/cat-5258_HS110.html

I've written a Python script to read this in Domoticz (not MySensors though).

Got this working OK. I built a MQTT / W5100 gateway as per the instructions in the MySensors Build section, and changed the topic prefixes and controller IP address in the example sketch.

Initially this failed, as I had connected Vcc on the W5100 to 5V instead of 3.3V, and I had the prefixes the wrong way round (i.e., /out instead of /in).

(BTW: I'm using MySensors 2.1.0 and Domoticz 3.6371 - latest / recent beta.)

@jpaulin said:

@MikeF
Domoticz can now interpret the MySensors MQTT format from a MySensors MQTT Client Gateway without JSON stuff, it's straight forward. To make it work just change the Topic Prefix in the MySensors Gateway and the rest is solved under the hood. Auto discovery etc works now as any other MySensors Gateway with Domoticz.

Thanks for this, @jpaulin - I'll build an MQTT / ethernet gateway and see how I get on.

Hi @jpaulin, can you explain how you got this working with MySensors?

As far as I can tell, MySensors and Domoticz use very different MQTT message formats.

Some examples:
MySensors:

mygateway1-out/2/1/1/0/49 55.722519;13.018121;13

Domoticz:

{ "idx" : 222, "nvalue" : 0, "svalue" : "22.5" }

Note: I can publish to the 'domoticz/in' topic from the command line OK:

mosquitto_pub -h 192.168.0.63 -m '{ "idx" : 222, "nvalue" : 0, "svalue" : "22.5" }' -t 'domoticz/in'

(this updates a dummy temperature node in Domoticz) , so I know that MQTT is working in Domoticz.

Be careful powering the Nano from 12V - there are reports elsewhere on this forum of some versions getting fried at this voltage!

Is there a 'local' source of PCBs for MySensors (i.e., UK / Europe)?

I've just (14 November) received 3 of @sundberg84's Low Power Node PTH v2 (atmega328p and NRF24L01+) boards from OSH Park in the US, which I ordered on 24 October - panelisation and fabrication was actually quick, and they were finished and posted on 2 November. Elapsed time was 3 weeks, but I understand it can be up to twice this for boards from China (e.g., dirtypcb's).

It would be good if there was a more local source, with shorter elapsed times.

I've now uploaded an external view - see my earlier post.

... and here's mine - in white:


(now managed to upload pics in portrait!)

I'm using a BME280 instead of a BMP180 and DHT22.

@ceech, could you make a version for the UK - without the flag? :smile:

Thanks, @AWI - using wait() instead of sleep() works.

However, isn't there an issue for battery-powered nodes in using wait rather than sleep? Sleep worked OK on my sketch under MySensors 1.5 - maybe the use of gw.begin(incomingMessage, NODE_ID) woke it up?

Will this also be the case with other sketches which receive messages from the controller? for example, I have still to convert an RGB LED sketch which gets a hex value (in the form 0xrrggbb) from the controller?

I've been converting my sketches to MySensors 2.0.0, and I seem to have hit a problem with a node using V_TEXT and S_INFO, getting a text value from Domoticz. Previously - under 1.5 - I had added V_TEXT and S_INFO to MyMessage.h, and this worked OK. (I have a text sensor in Domoticz, and typically this has a value such as 10.3#77#3, which I'm parsing in the sketch.)

Now, however, I cannot get the sketch to read the value.

I've stripped the sketch down to the bare basics here:

// Text Sensor
// MySensors 2.0.0

#define MY_DEBUG

#define MY_RADIO_NRF24
#define MY_RF24_CE_PIN 7
#define MY_RF24_CS_PIN 8

#define MY_NODE_ID 40

#include <MySensors.h>

#define SKETCH_NAME "Text sensor"
#define SKETCH_MAJOR_VER "2.0"

#define TEXT_CHILD_ID 11

unsigned long SLEEP_TIME = 30000;  	//  0.5 min. (300 sec.) sleep time between reads (seconds * 1000 milliseconds)
String tempSensor;
String outsideTemp;

MyMessage textMsg(TEXT_CHILD_ID, V_TEXT);

void presentation()
{
	// Send the sketch version information to the gateway and Controller
	sendSketchInfo(SKETCH_NAME, SKETCH_MAJOR_VER);

	present(TEXT_CHILD_ID, S_INFO);
} 

void setup()  
{  

}

void loop() 
{
	request(TEXT_CHILD_ID, V_TEXT); 
  
	// Sleep until something happens with the sensor
	sleep(SLEEP_TIME);
} 

void receive(const MyMessage &message) {
	if (message.type == V_TEXT)
	{
		tempSensor = message.getString();
		int sepIndex = tempSensor.indexOf('#');
		outsideTemp = tempSensor.substring(0, sepIndex);
		Serial.println(tempSensor);
	}
}

The main difference was changing 'void incoming Message' to 'void receive'.

I've included a sample of the serial output here:

TSP:MSG:SEND 40-40-0-0 s=11,c=2,t=47,pt=0,l=0,sg=0,ft=0,st=ok:
TSP:MSG:SEND 40-40-0-0 s=11,c=2,t=47,pt=0,l=0,sg=0,ft=0,st=ok:
TSP:MSG:SEND 40-40-0-0 s=11,c=2,t=47,pt=0,l=0,sg=0,ft=0,st=ok:

The sketch seems to be sending out empty text strings, but not issuing any reads.

Any clues? Thanks in anticipation.

Inspired by this, I eventually got round to making a smaller gateway:

I'm powering this from a 5V USB source, with an AM1117 3.3V regulator for the radio.

I also took the opportunity to use the MySensors 2.0.0 Serial Gateway example, and to convert my existing sketches - I followed this thread.

I've built nodes using two versions of the Ceech board intended for solar cells - one with the LTC4079 charger, the other with the earlier LTC4067 charger.

I now want to use one of these as a pulse power sensor without sleep (as per MySensors example sketch), so it needs to be on non-battery power, i.e., from a 5V USB charger. If I remove the battery, which input should I connect the 5V to: the battery input or the solar input?