pi@Domoticz3:~/Raspberry$ sudo /etc/init.d/PiGatewaySerial start
[....] Starting PiGatewaySerial (via systemctl): PiGatewaySerial.serviceFailed to start PiGatewaySerial.service: Unit PiGatewaySerial.service failed to load: No such file or directory.
or this error
pi@raspberrypi ~ $ sudo /usr/local/sbin/PiGatewaySerial
sudo: /usr/local/sbin/PiGatewaySerial: command not found
you have probably forgotten to run sudo make install. Read the instructions again, and follow them this time
In my case I did need simply to restart. I did "make install" but I did need to restart
@MikeF Dirtypcbs rarely takes more than 3-4 weeks for me too (in germany), but you are right, a local source would be great. There are several producers here too, but for everyone I know prices are at least 5 times what the chinese take.
If you (or someone else) finds a european service that produces prototypes (1-3 boards) for less than 15€ per piece please share it! Could come in very handy when developing new boards.
@pouniok My personal experience with nRF24 isn't bad. I used a pa+na-Version for the GW and a Repeater Node 2 floors downstairs to cover my hole house, both together with an adopter plate @70ct.
The receiver in your picture is known to be some of the worst rf-hw ever sold, so no wonder, this doesn't really work (sender is ok). Better use RXB12 (or similar), they are really good receivers and available on ebay for 4 Euro/5 pieces, if you like to stay at 433 (which imo is a bad rf-band to use, it's too noisy).
With MQTT, I have no experience, but imo, this only is usefull, if you have also to integrate other HW that natively "speaks" MQTT or want to make some parts available over internet. Otherwise, it just doubles data handling to controller (this is at least the case when using FHEM as controller) and may cause some delay (and a lot more possible points of failure). For me, this is more or less a no-go, I like to keep things as simple as can...
@Boots33 said in [How to build an overridable MySensors relay based device
You can still notify the controller of the change but use node to node to activate the light. This is usually the simplest way to go. It also has the advantage that even if the controller is not available the light will still switch.
Ok - I'll look into that.
Like i said having the switch connected to the node that controls the light is the most reliable way, but not always the most convenient.
The node is going to be in a plug socket type device instead of in the lamp in some way. The lamp will plug into this socket. So I can't work out a way to conveniently have the local switch attached to that without being quite ugly and ungainly.
Where is the node that will control the light going to be. Are you fitting it inside the lamp or is it to be external?
It'll be external - built into a plug socket. I figured that gives me more space to work, much like the X10 equipment I'm replacing.
With the inability to get signal strength from the nRF24, I'm open to any suggestions to fairly evaluate the boards I've collected. Don't think the wife will let me spring for a spectrum analyzer...
Somewhere in the other thread I posted a sketch for automatically counting packet loss percentages. That's the best way that I've been able to think of. Signal strength, bit error rate, and packet loss rate should all be very strongly correlated to one another.