Sure, there is already the KiCAD file including everything to play around with on your own; added a picture of the schematic here for a quick glance without downloading.
Hi,
I finally received the boards from the manufacturer(big thanks to @Seeed-Fusion). I manage to assemble one board by soldering the components and such and...it WORKS(including OTA)! I will post the instructions on openhardware.io project page.
Hello, i'm making some progress; received the components this week.
Unfortunately it doesn't work... yet
For now i have SanityCheck failure in to logs.
I'm afraid my soldering of all these little components is not good. I tested with a multimeter the 4 pins and i have continuity on one of them but maybe not the others so i guess i will have to try remelting all these small regulators ???
@gregl I have used this procedure a few times:
Define for example a V_VAR1 message for the query (or use any other suitable message type depending on purpose),
Make a MQTT binding for this message i Openhab (for example bind it to a switch, a number or whatever fits the purpose)
Make a rule in Openhab that reacts on this incoming message ("When Item xxxxx received update then ......)
Fix whatever logic is needed in this rule so you can send the queried info back to the sensor. If no existing binding is suitable you can of course define a V_VAR2 message (or use other type which fits) for the return message.
In the "Incomingmessage" function use whatever logic is needed to decode the returned message.
Reason for choosing a custom type of message (like a V_VAR2) for sending the info back is of course that it is easy to sort it out from the stream entering the incoming messages function. If you have no other incoming messages or the logic for the queried info already is in place then you do not have to think about this.
Hope the explanation is understandable, if not please revert.
Not yet !
In fact, the interrupt must be short enough and fast enough to be sure to not miss the RFM69 interrupts.
The code for 8 dimmers will not be really more complicated : in fact, each time we got a zero cross, we must set a timer to zero, and then wait the good amount of milliseconds to turn on the needed outputs.
So, yes, we'll have an interrupts each 10ms (each time the wave crosses the zero, to be precise !), but I think all we have to do in the interrupt handler is set the timer to zero (or to micros() ...) and then on the main loop, wait the good amount of time for each output before setting them ON.
Seems simple on paper, perhaps it will not work on the chip....
In facts, my main concern is : will the RFM interrupt be short enough to not disturb the zero crossing interrupt ?
Although, not yet tested the RFM : do we NEED the interrupt pin ? Can't we poll frequently the RFM?
Hi,
nice projet. I am very interested in it.
But why you are using 5 V and not 3.3 V? The ATmea328 works with 3.3 V too and the NRF have to use 3.3 V.
The only restriction on 3.3 V is the clock limitation for the Atmega (8 MHz). But with no crystal it don't care.
For example you could use an HLK-PM03 instead of HLK-PM01 and remove the linear voltage regulator. So you get more space an everything have the same voltage level.
And another point is, it is recommended to use a capacitor (0.1 µF) to ground for each voltage pin (Vcc, Avcc, Aref).
