@Jodaille Thanx for the link to the project. I think I'll order one of those sensors this weekend. As I hope it can also send the amount of rain that is falling.
I do have to check the optical sensor. But I really like the heating in the controlli sensor
@ptr727 This chip will work for a single channel dimmer, but has trouble operating as part of a multi channel dimmer. I prototyped a one channel design and had it working but gave up as I could not get a workable design for a 4 channel unit.
Meanwhile I made progress with my project. Together with some colleagues I want to install a real-time measurement system with more than 30 channels (i.e. 30 Nano BLE 33 measuring accel. and gyro.) and one evaluation unit (another Nano BLE 33 combined with other computers). The 6 values (2*x,y,z) of 16 Bit each shall be transmitted with 10 measurements per second.
Instead of spontaneous sending beacons with new measurement values from the 30 devices (to many collisions, real-time simply not possible) I use a master-slave polling, done by the evaluation unit. And I continue using non-connectable/non-scannable BLE-Beacons, for the request messages and for the response messages.
Meanwhile, my beacons can be detected by typical BLE scanner APPs on my smartphone (Android 10). I do not know, why that did not work at the beginning. May be I corrected some mistakes incidentally in the last months.
I am working also on a channel hopping (in case of disturbances by other devices with BT and WLAN) and using more channels for higher measurement speed. But the implementation of that will start later.
8 hours later
Now I found a reason for the behavior of the Scan-APPs: My request beacons (without data, only user address of 6 bytes) are detected, but not the response beacons with data.
I do not need the smartphones now (the speed of about 500 beacons per second is to fast for them), so I am happy with my solution.
I can confirm the solution posted by FarmerEd works for me. I was able to transmit from a Lora32u4 ii (node) to a TTGO Lora32 gateway.
As pointed in his post, the right line was:
#define MY_RFM95_IRQ_NUM digitalPinToInterrupt(7)
instead of #define MY_RFM95_IRQ_NUM MY_RFM95_IRQ_PIN
or #define MY_RFM95_IRQ_NUM 7
Thanks very much again for taking the time to post the solution.
Main problem (already "quickfix" solved) is completely new and incompatibile interrupt system implemented in new (post-2016) ATtinys. More flexible, but also coming with some problems when using Arduino-like code and few libraries. Other than that, due to completely new power management these features I don't tested yet, may not work properly...