• RE: MQTT GW with RFM69 on RPi

    @frits Thank you for your input. My gateway definitely becomes unreliable after a while.

    Maybe your hint regarding signing is worth some investigation. My sensors (temperature / humidity) which don't use signing seem to work fine over time. My actuators are using signing and become unreliable after a time. Currently I'm using a 2.2.0 gateway with 2.3.2 nodes and the suspicious debug message hasn't appeared yet. Maybe I will disable signing at all and test again.

    posted in Troubleshooting
  • RE: MQTT GW with RFM69 on RPi posted in Troubleshooting
  • RE: RFM69(HW) 433Mhz interference with other home devices?

    Hey @joaoabs ,

    no this is not an intended behaviour. The usage of the frequencies 433 MHz, 868 MHz etc. is limited by regulations. The devices aren't allowed to continously send packets and block a frequency.

    I myself am using RFM69(HW) but in 868 MHz mode and Homematic devices that use the same frequency. Works without a problem!

    Try to figure out which node jams the frequency by disabling all nodes and switch them on one by one and checkout at which time your garage door stops working.

    posted in Troubleshooting
  • RE: MQTT GW with RFM69 on RPi

    @Yveaux I'm simply running the stock code from github:

    https://github.com/mysensors/MySensors/blob/development/examples_linux/mysgw.cpp

    I've only configured (./configure) the make process and that's it. No changes to the code.

    Happens with 2.3.2 and 2.4-alpha.

    posted in Troubleshooting
  • MQTT GW with RFM69 on RPi

    Hello!

    I've a strange problem with my RPi gateway that happens with my Wemo D1 gateway too. Both gateways are MQTT gateways with an attached RFM69.

    For simplicity I focus on the RPi gateway. The gateway uses version 2.3.2 with the configure parameters set:

    ./configure --my-transport=rfm69 --my-rfm69-frequency=868 --my-is-rfm69hw --my-gateway=mqtt --my-controller-ip-address=192.168.2.13 --my-mqtt-publish-topic-prefix=mysensors-out --my-mqtt-subscribe-topic-prefix=mysensors-in --my-mqtt-client-id=mygateway1 --my-signing=software
    

    The gateway itself works but fires a lot Dec 02 16:09:11 DEBUG !MCO:PRO:RC=1 messages before a message is passed to the mysensors network. Receiving messages works fine.

    Here's a debug output from the gateway:

    Dec 02 16:08:08 INFO  Starting gateway...
    Dec 02 16:08:08 INFO  Protocol version - 2.3.2
    Dec 02 16:08:08 DEBUG MCO:BGN:INIT GW,CP=RPNGLS--,FQ=NA,REL=255,VER=2.3.2
    Dec 02 16:08:08 DEBUG TSF:LRT:OK
    Dec 02 16:08:08 DEBUG TSM:INIT
    Dec 02 16:08:08 DEBUG TSF:WUR:MS=0
    Dec 02 16:08:08 DEBUG TSM:INIT:TSP OK
    Dec 02 16:08:08 DEBUG TSM:INIT:GW MODE
    Dec 02 16:08:08 DEBUG TSM:READY:ID=0,PAR=0,DIS=0
    Dec 02 16:08:08 DEBUG MCO:REG:NOT NEEDED
    Dec 02 16:08:08 DEBUG MCO:BGN:STP
    Dec 02 16:08:08 DEBUG MCO:BGN:INIT OK,TSP=1
    Dec 02 16:08:08 DEBUG GWT:RMQ:CONNECTING...
    Dec 02 16:08:08 DEBUG connected to 192.168.2.13
    Dec 02 16:08:08 DEBUG GWT:RMQ:OK
    Dec 02 16:08:08 DEBUG GWT:TPS:TOPIC=mysensors-out/0/255/0/0/18,MSG SENT
    Dec 02 16:08:08 DEBUG TSM:READY:NWD REQ
    Dec 02 16:08:08 DEBUG ?TSF:MSG:SEND,0-0-255-255,s=255,c=3,t=20,pt=0,l=0,sg=0,ft=0,st=OK:
    Dec 02 16:08:08 DEBUG TSF:MSG:READ,99-99-0,s=255,c=3,t=21,pt=1,l=1,sg=0:0
    Dec 02 16:08:08 DEBUG GWT:TPS:TOPIC=mysensors-out/99/255/3/0/21,MSG SENT
    Dec 02 16:08:08 DEBUG TSF:MSG:READ,0-99-255,s=255,c=3,t=20,pt=0,l=0,sg=0:
    Dec 02 16:08:08 DEBUG TSF:MSG:BC
    Dec 02 16:08:09 DEBUG TSF:MSG:READ,0-98-255,s=255,c=3,t=20,pt=0,l=0,sg=0:
    Dec 02 16:08:09 DEBUG TSF:MSG:BC
    Dec 02 16:08:10 DEBUG TSF:MSG:READ,98-99-0,s=255,c=3,t=21,pt=1,l=1,sg=0:99
    Dec 02 16:08:10 DEBUG GWT:TPS:TOPIC=mysensors-out/98/255/3/0/21,MSG SENT
    Dec 02 16:08:10 DEBUG TSF:MSG:READ,0-97-255,s=255,c=3,t=20,pt=0,l=0,sg=0:
    Dec 02 16:08:10 DEBUG TSF:MSG:BC
    Dec 02 16:08:10 DEBUG TSF:MSG:READ,97-99-0,s=255,c=3,t=21,pt=1,l=1,sg=0:98
    Dec 02 16:08:10 DEBUG GWT:TPS:TOPIC=mysensors-out/97/255/3/0/21,MSG SENT
    Dec 02 16:08:39 DEBUG TSF:MSG:READ,98-99-0,s=255,c=3,t=22,pt=5,l=4,sg=0:181035246
    Dec 02 16:08:39 DEBUG GWT:TPS:TOPIC=mysensors-out/98/255/3/0/22,MSG SENT
    Dec 02 16:08:42 DEBUG GWT:IMQ:TOPIC=mysensors-in/98/4/1/0/2, MSG RECEIVED
    Dec 02 16:08:42 DEBUG TSF:MSG:SEND,0-0-99-98,s=4,c=3,t=16,pt=0,l=0,sg=0,ft=0,st=OK:
    Dec 02 16:08:42 DEBUG !MCO:PRO:RC=1
    Dec 02 16:08:42 DEBUG !MCO:PRO:RC=1
    Dec 02 16:08:42 DEBUG !MCO:PRO:RC=1
    Dec 02 16:08:42 DEBUG !MCO:PRO:RC=1
    Dec 02 16:08:42 DEBUG !MCO:PRO:RC=1
    Dec 02 16:08:42 DEBUG !MCO:PRO:RC=1
    Dec 02 16:08:42 DEBUG !MCO:PRO:RC=1
    Dec 02 16:08:42 DEBUG !MCO:PRO:RC=1
    Dec 02 16:08:42 DEBUG !MCO:PRO:RC=1
    Dec 02 16:08:42 DEBUG !MCO:PRO:RC=1
    Dec 02 16:08:42 DEBUG !MCO:PRO:RC=1
    Dec 02 16:08:42 DEBUG !MCO:PRO:RC=1
    Dec 02 16:08:42 DEBUG !MCO:PRO:RC=1
    Dec 02 16:08:42 DEBUG !MCO:PRO:RC=1
    Dec 02 16:08:42 DEBUG !MCO:PRO:RC=1
    Dec 02 16:08:42 DEBUG !MCO:PRO:RC=1
    Dec 02 16:08:42 DEBUG !MCO:PRO:RC=1
    Dec 02 16:08:42 DEBUG !MCO:PRO:RC=1
    Dec 02 16:08:42 DEBUG !MCO:PRO:RC=1
    Dec 02 16:08:42 DEBUG !MCO:PRO:RC=1
    Dec 02 16:08:42 DEBUG !MCO:PRO:RC=1
    Dec 02 16:08:42 DEBUG !MCO:PRO:RC=1
    Dec 02 16:08:42 DEBUG !MCO:PRO:RC=1
    Dec 02 16:08:42 DEBUG !MCO:PRO:RC=1
    Dec 02 16:08:42 DEBUG !MCO:PRO:RC=1
    Dec 02 16:08:43 DEBUG !MCO:PRO:RC=1
    Dec 02 16:08:43 DEBUG !MCO:PRO:RC=1
    Dec 02 16:08:43 DEBUG !MCO:PRO:RC=1
    Dec 02 16:08:43 DEBUG !MCO:PRO:RC=1
    Dec 02 16:08:43 DEBUG !MCO:PRO:RC=1
    Dec 02 16:08:43 DEBUG !MCO:PRO:RC=1
    Dec 02 16:08:43 DEBUG !MCO:PRO:RC=1
    Dec 02 16:08:43 DEBUG !MCO:PRO:RC=1
    Dec 02 16:08:43 DEBUG !MCO:PRO:RC=1
    Dec 02 16:08:43 DEBUG !MCO:PRO:RC=1
    Dec 02 16:08:43 DEBUG !MCO:PRO:RC=1
    Dec 02 16:08:43 DEBUG !MCO:PRO:RC=1
    Dec 02 16:08:43 DEBUG !MCO:PRO:RC=1
    Dec 02 16:08:43 DEBUG !MCO:PRO:RC=1
    Dec 02 16:08:43 DEBUG !MCO:PRO:RC=1
    Dec 02 16:08:43 DEBUG !MCO:PRO:RC=1
    Dec 02 16:08:43 DEBUG !MCO:PRO:RC=1
    Dec 02 16:08:43 DEBUG !MCO:PRO:RC=1
    Dec 02 16:08:43 DEBUG !MCO:PRO:RC=1
    Dec 02 16:08:43 DEBUG !MCO:PRO:RC=1
    Dec 02 16:08:43 DEBUG !MCO:PRO:RC=1
    Dec 02 16:08:43 DEBUG !MCO:PRO:RC=1
    Dec 02 16:08:43 DEBUG !MCO:PRO:RC=1
    Dec 02 16:08:43 DEBUG !MCO:PRO:RC=1
    Dec 02 16:08:43 DEBUG !MCO:PRO:RC=1
    Dec 02 16:08:43 DEBUG !MCO:PRO:RC=1
    Dec 02 16:08:43 DEBUG !MCO:PRO:RC=1
    Dec 02 16:08:43 DEBUG !MCO:PRO:RC=1
    Dec 02 16:08:43 DEBUG !MCO:PRO:RC=1
    Dec 02 16:08:43 DEBUG !MCO:PRO:RC=1
    Dec 02 16:08:43 DEBUG !MCO:PRO:RC=1
    Dec 02 16:08:43 DEBUG !MCO:PRO:RC=1
    Dec 02 16:08:43 DEBUG !MCO:PRO:RC=1
    Dec 02 16:08:43 DEBUG !MCO:PRO:RC=1
    Dec 02 16:08:43 DEBUG !MCO:PRO:RC=1
    Dec 02 16:08:43 DEBUG !MCO:PRO:RC=1
    Dec 02 16:08:43 DEBUG !MCO:PRO:RC=1
    Dec 02 16:08:43 DEBUG !MCO:PRO:RC=1
    Dec 02 16:08:43 DEBUG !MCO:PRO:RC=1
    Dec 02 16:08:43 DEBUG !MCO:PRO:RC=1
    Dec 02 16:08:43 DEBUG TSF:MSG:READ,98-99-0,s=255,c=3,t=17,pt=6,l=25,sg=0:<NONCE>
    Dec 02 16:08:43 DEBUG TSF:MSG:SEND,0-0-99-98,s=4,c=1,t=2,pt=0,l=1,sg=1,ft=0,st=OK:1
    Dec 02 16:08:46 DEBUG TSF:MSG:READ,97-99-0,s=255,c=3,t=22,pt=5,l=4,sg=0:181033345
    Dec 02 16:08:46 DEBUG GWT:TPS:TOPIC=mysensors-out/97/255/3/0/22,MSG SENT
    

    git status ensures that there are no changes to the code.

    Any idea what is happening here?

    With the Wemos D1 MQTT gateway I've seen the same behaviour, and after a time it escalates to RC=2 and becomes less responsive.

    The same happens with the current development version.

    posted in Troubleshooting
  • RE: nRF5 action!

    @ncollins If you have the gumption to do it, it might open up some interesting new possibilities. In the past programming bluetooth was a bit daunting, but it seems like some of the newer tools may be easier to learn: e.g. https://learn.adafruit.com/introducing-the-adafruit-nrf52840-feather/bluefruit-nrf52-api

    posted in My Project
  • RE: nRF5 action!

    @ncollins The sandeepmitry library has incomplete coverage, but what it does provide is access to the nRF5 registers. From there you can do whatever it is that you want to do by manipulating the registers directly. That makes it closer to assembly language, at least in thought process, than the confortable arduino library support you may be accustomed to.
    I haven't tracked the arduino or adafruit implementations. Maybe by now they have better library support? Alternatively, mbed and sager and probably others have their own library support for it, so there's always that which you can look into. Come to think of it, IIRC, Arduino simply adopted the mbed platform for the nRF52 rather than roll their own, which was a rather unusual move. That may mean it may never be completely "arduino" in the same way other arduino platforms are.

    posted in My Project
  • RE: 💬 InlineCleaner

    @openhardware-io

    Hi, the link you gave in your description isn't working: "One pack of Greenstar replacement rollers https://www.hagebau.de/p/renovo-ersatzwalzen-greenstar-6-cm-3-stueck-anHG_PROD_4046806013680/ Costs: 3,99 €"

    I did find the following, though the price is different from what you reported, and it looks different than what's in your photo: https://www.hagebau.de/p/renovo-farbwalze-greenstar-25-cm-12-mm-florhoehe-weiss-gruen-blau-anP7000129076/?searchType=devided&q=greenstar rollers&itemId=B1072454 Are you actually unwinding the nap of a paint roller and using it in your machine as a dust remover?

    posted in OpenHardware.io
  • RE: Using an Arduino Uno as ISP for programming 5V and 3.3V boards without soldering the needed connections

    Another way is to align the header pins landing pattern in a zig-zag so as to make a temporary solderless connection held in place by the spring tension of the misaligned header pins:
    alt text
    I've tried it and it works, but because of the wear on the through-hole plating it's not really appropriate for frequent use. For a once-and-done setup though it seems to work just fine. For instance, Ideally you'd install a wireless bootloader just once and then from then on you don't need a physical connection.

    posted in My Project
  • a truly great build plate

    I recently switched to using Prusa's textured PEI-Ultem build plate, and it works wonderfully with PETG: no brims are needed and prints stick very well while printing, and yet prints release with little to no effort after it has cooled to room temperature.
    https://shop.prusa3d.com/en/i3-accessories-mk3s-mk25s-etc/214-powder-coated-spring-steel-sheet.html

    In my view it is a significant improvement over the smooth PEI build plate that Prusa released a couple years ago.

    Anyone here discovered any other build plates that they really like?

    posted in Enclosures / 3D Printing