Hi
I have been searching if this cable can be used like the cn105 for Mitsubishi devices, but so far I only found libraries for daikin that use IR. Is there really no other way than IR?
@skywatch said in Go to loop(); when parent/gateway can't be found.:
ai tempo, potresti dare un
Just insert this line:
#define MY_TRANSPORT_WAIT_READY_MS 1000
before : #include <MySensors.h>
this is all, so if the Gateway is not available after 1000 Milli seconds, the scketch is performed anyway
@BearWithBeard said in GUIDE - NRF5 / NRF51 / NRF52 for beginners:
From the two ports the BMP provides, you want to use the GDB Server. If Windows only provides generic names for both ("USB Serial Device" or something), the one with the lower number should be the right choice.
Strangely, my BMP uses the higher port number as the GDB server and the lower one as the serial port. I think this is unusual since it is opposite of what most guides say to expect. So, try the higher one if the lower one doesn't work.
Besides what Bob (?) mentioned (you seem to be making progress, breadboard unreliability, specifics), I would point out that there have been a number of discussions about ACKs, re-sending, reliability, keeping stats of NACK percentages (as a possible indicator of some problem), etc. over the years. The most recent I can recall was probably this one that I learned about when @BearWithBeard mentioned it here in my evidence based radio testing method (and capacitors) thread. My thread is more about hardware and radio testing, but we get into the subject of software ACKs etc. there in my thread a bit, and also in the linked thread.
Is that the sort of stuff you are looking for?
@henk-herck - thanks for your reply and suggestions.
I changed the pins to output and set them as high, but unfortunately it didn't change the outcome. In the end I soldered some wire into the OpenSprinkler's expansion board to help me get to that row of pins which allowed me to work around my issue.
I'd never really looked at the Orange Pi range before and went a bit down a rabbit hole looking at them yesterday. They're quite interesting and I'll look into them a bit more today.
When looking in the log parser, I notice the following:
At 14924, 34877, 54829, node 7 is requesting data from node 0:
Received Message
Sender: 7
Last Node: 7
Destination: 0
Sensor Id: 1
Command: REQ
Message Type: V_VAR1
Payload Type: P_STRING
Payload Length: 0
Signing: 0
Payload:
This probably corresponds to this code in the node:
// No count received. Try requesting it again
request(CHILD_ID, V_VAR1);
My guess is that the node expects this variable to be available at the controller. I don't have much experience with requesting variables so I don't have any good suggestions unfortunately.
The log also shows that the FPAR requests that failed earlier work fine now:
Sent Message
Sender: 0
Last Node: 0
Next Node: 7
Destination: 7
Sensor Id: 255
Command: INTERNAL
Message Type:I_FIND_PARENT_RESPONSE
Payload Type: P_BYTE
Payload Length: 1
Signing: 0
Failed uplink counter: 0
Status: OK (OK=success, NACK=no radio ACK received)
Payload: 0
@henk-herck said in Why is stropts.h included ?:
the manufactures are not that interested
There is this, which is true, and then there is outright hostility towards F/LOSS development, which is typically a product of dinosaur business model lock-in mindset (RPi, Nvidea, etc...), which I can only hope will finally die off sooner or later.
@henk-herck said in Why is stropts.h included ?:
amlogic ,allwinner ,rockchip are less known socs but have nice features
Yes, personally I am well aware, but good to mention for others reading. Currently I am eagerly awaiting the release of the version of Helios64 (Rockchip based, IIRC) which is supposed to come with ECC RAM! This will eventually become my new 64-bit ARM ECC ZFS NAS (wow that was a lot of alphabet soup!).
@ozrex,
I don't want to assume your knowledge level. However the truth is that you will probably need to put together different bits and pieces from various threads in order to come up with your own custom solution (the A/C interface (IR) part, the battery part, etc...).
Maybe it is worth it to create your own new thread, or maybe you want to keep researching / trying on your own a little longer first. The latter is admirable, and is the way I usually do it, too. Some times to a fault in my own case. Don't suffer along in silence if you are struggling to find the information, make a thread instead. If it becomes too difficult you may give up. We all need some small successes along the way to keep motivated and keep it fun.
Probably best to create a new thread (I don't want to derail this one too much) but something you might want to look into is OpenMQTTGateway. I use it for my 433mhz, but it also supports RF, BLE, LoRa (and perhaps others in future) all on the same gateway! To me that was the way to go... And so far has been flawless for me.
@TRS-80
"Arduino IDE" is hardly an glorified notepad, it is beyond useless, why can't it save your board config with your project FFS!!!.
I'm using arduino plugin for atmel studio, since it's only way to use hardware debuggers, both AVR dragon and ATMEL ICE work great.
