Hey, Anthony.

Yeah, the cube is the temperamental bit. It forgets the sensors every few weeks/months.

I have opened up the python web page to the web, secured behind a password, and it's OK to use. I mainly use it to monitor the system and look at the pretty graphs. I think the CC1101 with OpenHAB or custom software is the way to go.

Let me know if you get the Pi and CC1101 installed. I can't recall exactly what was wrong but I think it may be one of the packages that it tries to download no longer exists. It's something I really want to get fully working the way I want it, but to be honest it does a good job anyway.

Stu

Hey, @demusss. I'm still using the python script talking to the MAX! Cube. It's a little temperamental but works most of the time. I finally got my hardware (CC1101) but, if I remember right, the homegear instructions listed above don't seem to work anymore. There's a missing module? I can't recall now. I'm sure I could sort it out but I just haven't had time.

Ideally, I'd like to talk to the system myself via the CC1101 and write the software myself instead of relying on OpenHAB but time is the limiting factor, unfortunately.

Maybe I'll pick it up again this weekend and try and get the CC1101 comms working.

Stu

@Pigsy I've gone back to this in an attempt to get it working with Google Home. However, it isn't as simple as it first seemed. I can't get it working with the ESP MAC address so don't know what it's doing. I suspect the WeMo app would need to register it first which isn't possible since it doesn't emulate that part of the setup.

If I had an actual real device I could probably sniff the network and emulate this part too, then (assuming the WeMo servers don't require a WeMo reserved MAC) it may work. Unfortunately I don't have a WeMo device or the time to reverse engineer the app setup so for now it's just Alexa compatible

@Sergio-Rius Oh well, it doesn't look too hard to adapt for the error.

Thanks, @LastSamurai, I went and compared the DIrty PCB files with the v1.3 ones on OpenHardware.IO and they are indeed different. It looks like the DIrtyPCB link is out of date and still has the error on them.
@Sergio-Rius would be very grateful if you could update those files

I've been running a small test setup for some time with just 1 node and 1 gateway. For some reason, in the past week or so, I've noticed that the "present" doesn't either send or get to the gateway. I'm using MYSController to look at the messages but if I delete the node and let it re-register itself, it only gets its name and sometimes 1 of the 4 sensors presented. It once got 2 of them. I don't think it's a transmission problem as the node can happily send hundreds of quick fire messages without dropout.

Has anyone encountered this? Can anyone think of a reason this would happen before I start debugging the code?

Thanks,

The project where I had to write to flash?

This was a network connected temperature and humidity sensor for a store room which had a built-in OLED display but was also network connected and hosted a website for graphing data output and displaying historical and real-time data. I wrote to flash so I could update the web page and other data OTA which was too big to fit in RAM or EEPROM and I didn't want to store on the SD card in case it was removed for any reason. It wasn't MySensors connected, unfortunately

Awesome! That has saved me a lot of work

I knew I should have spent some time doing the research before emptying my ideas into the forum!

I've been involved in a project recently that needed to write to FLASH memory at runtime. This made me think about OTA updates of MySensor nodes. As I understand it, MySensors uses an external EEPROM to store the update in then rewrites the FLASH from this EEPROM. I'm thinking, would it be possible to do this without the EEPROM?

This is what I'm thinking... Let's say your sketch takes up 55% of atmega328 FLASH (based on a recent sketch of mine). You can write an independent sketch that could handle comms, downloading and flashing that can sit at top of memory. Assuming it is small enough to fit in with your existing sketch and any replacement sketch you may upload. It would obviously have to be a little more intelligent than a dumb flash bootloader. For instance, it would need to know if a download has failed or is partial and be able to communicate this back to the controller and only reboot when the entire new sketch is flashed.

I think it would be a pain to write and be very limited in flexibility regarding the size of the sketches you can upload, but it would mean you could make nodes without having custom boards with EEPROM built-in or adding EEPROMs to your simple designs.

Am I crazy, or is this something that would be useful to some? I'd certainly find it useful.

It is indeed. But I've designed a home lighting control system that is completely stand alone so needs no controller. You can still add a controller if you want, but the actual messages and switching are all contained either in the nodes or on the gateway. I wanted a robust system that didn't rely on a separate PC to function when there was no real need for one.

So for me, being able to add Alexa into the lighting system without relying on a controller is useful.