Posts made by jirm

@mtiutiu

Wooow Wooow Wooow ! Here they are !

This one gang you designed will be my 1st Livolo hack
So many many thanks @mtiutiu

Best regards

Uploaded and public shared this plate design at OSHPark for anyone interested:

https://oshpark.com/shared_projects/wG8bXaBJ

PD: I'm not affiliated in any way to OSHPark and only uploaded and shared the @mtiutiu desing there for facilitation purposes for anyone interested that needed do a quick order of that plate boards in a good board build service at enough good price.

Best regards

Thank you so much @mtiutiu !!
Awesome good done job.

I'm too wait for alone 1 gang version that is mainly I need.

@marceloaqno

Awesome !!!
Thank you so much.

Best regards

@marceloaqno

I´m really happy ear that !

RFM69 is one of best RF transceivers in these days for IoT.
So good news I believe for Mysensors community.

You know if are any hope that RFM69 will be added too to OPI boards support mysgw development ?

Congratulations for that great work !

@alexus

Few weeks ago I uploaded and shared to Oshpark pcb web service this @mtiutiu pcb design (but take care !!! I think this is not last one version @mtiutiu design), so anyone can easily find it there and order build some pcb if like.

You can check it at https://oshpark.com/shared_projects , and easyly find it with only enter "livolo" word in the search case.

Sadly I don't have enough time yet to involve more in this project, but in near future I'm going to that and test that awesome design that this project have.

Regards

@tonnerre33

Personally I think that much better specs from RFM vs NRF and the working radio band (433, 868 Mhz vs 2,4 Ghz) are most than enough reasons to spend that 2 $ more on RFM.

But...more always is better. So we can dream with another plate board version for NRF in the future...who knows

@mtiutiu
Of course all we are here to help you make all the proper test needed with all Livolo parts that we speak. One or two gang with/and one or two way, other plate hardware revisions, etc...

That all we need for do that is the avaibilitty to get your plate boards designs working on our houses.

Personally I'm so busy (and so lazy) to make all this project working from scratch trying to find plate board manufacturer, solder all (wooow smd) parts, etc... etc... and need if possible some at least "semi-mounted" plate boards printed and with the smd parts soldered.

@mtiutiu

Hi all

Can I suggest some improvements for that project?

For sure I agree with @tonnerre33 about make a version board for only one gang switch.
I buy regularly (once a month or so) some parts from livolo and from last 4 or 6 months I see that the switch plate boards (for the EU version) are the same on hardware specs at least from 6 or 9 month ago.
But we can expect that in near future (maybe few months) Livolo manufacturer make some changes and updates on his designs, because they regulary are doing that in past. So we need keep prepared for that and for make the propper updates to this project to mantain it working with the next version Livolo switchs.

1. -One gang switch I think is most common switch people have installed or at least I think is needed too with this two gang project version.

2.- Maybe will be better use (or make another plate board version) for the RFM69HW (high power), because the pinount on HW not match with RFM69CW you use, and HW type have same working specs but with the plus that HW type have high power possibilities and is most easy to find and both have similar price.

3.- How can be little better documented all the changes (wiring) we need do on the power relay plate board?
At least for me is hard to do correct wiring only seeing the photo and is easy to do some mistake trying to solder the wiring in the correct pins and places.
So I suggest trying to do some more work on that and maybe include some scheme and plan and take all best pic from each wiring bridge is needed to do that we can see without doubts the correct place to solder it.

PD: @tonnerre33 I think one or two way switch function not be affected with this project plate board, because that function only differ on the pic (MCU) Livolo switch firmware and litles changes on power relay plate board to wire the additional pic pin output two way function to the COM connector.
Nothing of that function should be affected by anything that this plate modifies on the Livolo switch.

My best wishes !

@mtiutiu

Wooow wooow !!
Really a good job. Perfect looking and really accurate design board.
Sure it´s a winner project.
I only wait you can post us how can we get these wonders.

My best wishes

@Nca78 jejeje, " We have just solved a serious problem for Livolo manufacturers " of course I only wanted joking with that.

Livolo guys know perfectly what they are doing, and what are their objectives.

My best wishes.

@mtiutiu

Okay. According to your observations 200mw (peak) is required to feed the additional RF plate and to that must be added the self-consumption of the Livolo's power circuit.

I believe that in this case, it is not so important to calculate the peak power because given the dynamic of our operation (the peak power transmissions usually need a few ms), I'm certain that this peak power can be easily provided by the own current reserve stored in the capacitor itself, and because that I think is necessary focus tries to guarantee the stable supply of current for the "normal" operation of both circuits (additional plate and livolo), and that requires at least 15ma (I think that is the min) and much better if we can guarantee about 20-30ma.

In the next link you can see a fairly exhaustive analysis of current variations vs RF output power in a typical RFM69HW operation, which shows that the average current is around 20-30ma and the peaks can reach 80ma:

Https://www.andrehessling.de/2015/02/07/figuring-out-the-power-level-settings-of-hoperfs-rfm69-hwhcw-modules/

So trying to make a global vision of the power needs for that project in general and taking into account that usually we will always ignore the true capacity to generate current of the several type of loads that can be connected, the different topology of housing wiring (self-capacity, spur, etc ...), the huge variations in impedance of the loads according to their type, their dynamics of operation, etc. I think is much more reasonable and closer to the real needs use capacitors of at least 470nf min (although I would opt for 680nf or maybe 1uf), to guarantee that there will always be a enough constant current supply capacity really closer or exceeds demanded in any circumstances.
Therefore I would not consider so much in calculations the capacity of the own loads for the power supply and only would calculate the capacity of supply by using the correct value of the capacitor that in any case will have to be installed.

I think it is very important to guarantee the stability of the circuit operation (speaking in the long term) given the "infinite" possibilities of characteristics so variable that can be found in the installations of any house.

Collaterall efffect: When installing this capacitor we removed the load limitation of > 3w for Livolo's Switch, so generally now they can be used "independently" of the power and type of the load.

We have just solved a serious problem for Livolo manufacturers

Regards.

@mtiutiu

I totally agree about all your observations.

In our typically use case (on house with maybe 10-20 switch´s total) all my considerations about reactive power and consum increase can be totally overlooked because we are on really small values, but I think we need make all the important and proper warnings for anyone try to use on "any" environment.

And I think is so very difficult to find any other alternative solution to the proposed, which I insist that in any case and according to all the data we have is fully adjusted and satisfactory to our needs.

Thanks to you.

My best wishes

@mtiutiu

Hi @mtiutiu, You are the genius !!!.
I'm really happy to hear that you've finally achieved the desired results. Believe me that joy is mine if on anything but minimal I have contributed to you can achieve the desired goal.
I firmly believe that your development is the one that with difference and from my modest point of view has the key to success both because of its general approach and the fabulous development that I see you are performing in the accurate design of the additional circuit and I am sure that this design will be the future reference to give the Livolo's the possibility about true bidirectional RF control.

Regarding the circuit that Livolo sells to avoid the problems of switch flickering by low power loads (less than 3W) this is a circuit with active components and is not a circuit designed to provide more power but to guarantee the switch of a " minimum " but regulated and constant current and providing it with better immunity because the current fluctuations caused by some electronic loads (led and similar) when they are at rest.

So it is not at all something that can be compared to the function of the capacitor in parallel to the load that provides an absolute increase of the current flow through the load circuit (and therefore of the switch) due to its behavior resistive in AC (more correctly its impedance), and this last is the characteristic that here we are looking for.

Just point out that a couple of details regarding the use of a capacitor in this way, and is that the consumption will be constant activated the load or not although we speak of an increase in very low consumption (100ma @ 220V = 2.5W aprox) but should not be neglected if we intend to "modify" by this way a relatively high number of loads and in this cases I think at least imposes a previous calculation of the constant power that we will increased because of add a "pile" of parallel load caps.
Also not should we lose on sight the fact that we will introduce a reactive component (reactive power) that can affect the character of our electrical installation and that as I say if it is used generically in many loads it is necessary to calculate its effect in our installation to avoid some displeasure with our electric company and their invoices.

Finally let's do some simple math to calculate a capacitor value that might be appropriate.
Thus, the capacitive reactance is expressed as Xc = 1 / (w * C) where w is omega (equals 2 * pi * f, where f is the frequency) and C is the capacity in farads.
So if we wanted to have 20ma at 220V we would need a resistance of 4K (obviously I not do here this calculation of the simple ohm law) and therefore in my country that we have 50Hz frequency the capacity we would need would be C = 1 / (w * Xc) => C = 1 / (314 * 4000 ) = 729nF

Summing up the capacitor you have tested on 470nf gives you a constant current of about 15ma when the circuit is in standby (load off), and don't forget we have a capacitor so we can achieve much more current from his reserve (this is for what was designed) and we can manage the current peak draw when RF transceiver are full active working on sending (Hope RFM69W/HW typically have current peaks over 30-40 ma on 100-200ms duration on sending cicles at full RF power) and seeing all seams should be enough to power any RF transceiver and a low power mcu if its consumption is well controlled by its proper use.

With this capacitor we are increasing the consumption of the load circuit in only about 0.5W, but let's not forget that this will be constant consumption in 24/365 hours / days a year.

So I keep close tuned with your evolution here.

Best regards

@mtiutiu

I think you have the solution very close. I´m sure It is simply a matter of "fine-tuning" the Livolo's power circuitry so that they can provide enough energy (much more than designed) for the extra circuitry, something for which they are not prepared at all, but should not be too difficult to achieve if necessary. Considerations.

1.- The power circuit depends on the "consumption" that can be achieved over the load connected to the switch, so it is necessary to ensure that the load has enough "power draw" to allow pass through at least 100-150mA from AC which should be achieved with a load about 40/60W.
It is also something that can be compensated by adding a bypass capacitor (parallel to the load) of between 100 and 470 nf (of type X2 and 250V better 400 V to go safer), but all this is matter the try and error to achieve the target.

2.- It must be able to avoid the Livolo power circuit so that additional power can be consumed without being affected by the circuit status of the switch, either in standby or active mode. In theory that can be done through the bridges @DJONvl and @Tigroenot indicates in the post you mentions https://forum.mysensors.org/topic/2775/livolo-glass-panel-touch-light-wall-switch-Arduino-433mhz/63 , and whit that should be possible to have the necessary power and several of them seems have confirmed that it is possible.

Perhaps the problem arises to be able to correctly identify which are the correct modifications to be made in each Livolo switch since there are different types of circuits according to the world region to which they are addressed and different revisions of printed circuit so it is critical and not very obvious as Identify the jumpers and connections to be modified and how the power bypass in each case must be performed in order to extract the current to feed the additional circuit.

I think the latter is the most complicated and difficult to perform correctly, but nothing compared to all the work you have already done, so I'm sure you've almost got it.

If I could help you, I suggest some posts (unfortunately only spoken in Russian ;-), o. c. you need use google translator to try to understand) where you will see in the lower page intersting people discussions that are given some patterns and ideas to modify the circuit and that seems have managed to extract required current to power additional circuits.

Http://mysku.ru/blog/aliexpress/12956.html

I also indicated the analysis (I think original) of a person who performed reverse engineering to extract the schematic circuit from the assembled Livolo switch and where it discusses some aspects of its operation that can help.

Http://we.easyelectronics.ru/Shematech/preparirovanie-sensornogo-vyklyuchatelya-livolo.html

Please do not be discouraged and persevere a little more than you already have it!

Greetings.

@DJONvl

Yesss @DJONvl . Thats is !!!! .
You got it !!!

Please can you post all the details about how you are do it ??

How you are managed to achieve enough power from Livolo ??

How you wired the esp8266 and where on the livolo switch ??

You can post the schematic ??

Please, all details you can...

Regards

@DJONvl
Woow !
Livolo+Esp8266 working ??? ... sounds very good.
But we can not see the video seems you try to upload here ...

@mtiutiu

Awesome project !

I will follow your evolution really close.

I hope in few time you can post to us "first shot" from your pcb design for test.

Regards

@marceloaqno
@mfalkvidd @Tag @pansen @Reza @mihai.aldea @hausinger

Wooow woow woow !!!

Only few days "off" and the problem to make work Mysensors on OPI are solved.

So many many thanks to all people here that have been involved to make that OPI good little boards can work with Mysensors.

This is the proof that when good people join can reach the most difficult achievements and all humanity can benefit.

Awesome work !

Regards

@hausinger

Of course you dont need any SPI bus.
And so sorry but before I checked so badly the error you posted.

Not seems any related working error for mysgw. I think you have mysgw working fine, seems only they can not connect/work with sensor node.

You seems only need check node communication and adjust node configuration to have your mysgw working.

I don't see you found so much trouble to make working from usb-rs485 adapter if you can do it with usb/serial node, it's only matter that the driver of adapter can work with mysgw without so much issues.

Regards

@mihai.aldea

Indeed good info about GPIO port.

I will be aware about your progress...seems your approach is a sure win.

Thanks

@hausinger

Hi again to all OPI users.

I like see that are great movements here.

I think main goal here is achieve that OPI board can run mysensors for herself connected radio boards.
Of course that can work OPI (or any board) if we attach over some port the radio board, because use of any "conventional" port (means usb, serial, eth) is the same for any hardware from the software view.

Said this, I would simplificate (and reduce all hardware to minimum) all things I can and with a powerful board I can concentrate much of the roles needed.
Attach directly (means through GPIO) all hardware the board can manage without issues is my goal, and I think other much people.

I think the error posted @hausinger for run mysgw seems derived from de main problem we see when try compile mysensors on OPI, and is that the need (maybe although not always necessary) that SPIDEV driver are up and working properly and mysensors software can not detect SPI bus (then fail SPIDEV) on OPI while is not being adapted all software stuff from some mysensor coder.

I hope some mysensors coder hear our call and soon can help here.

Regards

@jirm
As a side comment, posting interesting good info about Orange PI GPIO ports assignment and usage, that can help too:

http://www.cnx-software.com/2015/09/26/status-of-orange-pi-boards-gpio-support/

@Tag

I just see than on your previous compilation for NRF24 build from Tmr24h that you confirm is working OK, the compilation have same "bad" cpu type A53 that I figure that is a bad selection for H3 and seems that is not any problem...so now I'dont understand nothing..
Well mean only understand that we need a mysensor coder for help an guidance and if available make to it all the changes needed for OPI on mysenros.

So we need help for all.

Regards

@Tag

Thanks to you to make the effort to try our "suppositions" ...

Mmmm...I see some interesting things on your results.

First all your results on OPI really differ from @eyesoft posted on the github. That can mean that Banana are much different (on drivers aspect) than OPI and then same solution cannot be applied to both...bad thing for us.

Then I see on make that the soc (and cpu) are bad seleected (I said this issue yesterday to @marceloaqno on general support post for mysensors gateway) because seems in the configure file have a bad selection about that specs when soc are a H3, and select a bad A53 type of cpu when is Armv7.

Then I don't know if all subsequent errors raised are significant or simply derived from that initially bad cpu selection.

Last I see that have issues on GPIO pins, but this is something we hoped would happen.

Anyway, I'm not coder so maybe are totally grong on all my observations and we need some coder (preferible @marceloaqno ) help us to deal with all that.

Regards and thanks to you !

Hi @Tag

We ( I and @pansen ) talked about that fork over mysensors github that @marceloaqno are doing to support Bananapi.

Banana have same soc than OPI, so the issues are the same on both boards for compile mysensors at least at that point. Maybe own OPI GPIO library (If I remeber Wiringpi or similar name or so) will be needed added to the mysensors software, but hope this can be easily do it like one last point.

Can you give a try on your OPI board and post results doing same commands than @eyesoft are doing for Banana on the forked github?
Then we can see if the same solution than @marceloaqno are building for Banana can be directly applied to our OPI.

I mean do this steps:

git clone https://github.com/marceloaqno/MySensors.git marceloaqno-spidev
git checkout spidev

...
then...

./configure --my-gateway=ethernet --my-transport=nrf24 --my-rf24-irq-pin=15 --my-rf24-channel=119

....
and last

make

@Tag, @pansen
I insist that I think that it would be very good if whatever ( @Tag ?? ) that has an OPI in place tried to run the mysgw install again and see what errors appear just after compile NRF24 driver, now that we know the TRM20h driver is working.
With this test we could try to transfer the result to @marceloqano (or any developer available here) to try to also modify the mysensors code for OPI.

Regards

@pansen
Yes...the test that @eyessoft did were indicated by @marceloaqno that is a developer on mysensors...so I suppose he are over it to solve.
I hope @marceloaqno (that knows about OPI issue and yesterday he too try help us with OPI) don't forget us and help to make work OPI too.
But we need some guy with OPI board ( @Tag ?? ) that in short time can follow the developer indications and run the test he purpose for debug and test when he are modifying the code .

So that's where we are for now...

Regards

@pansen Yes...This is a pull purpose to support Banana.
If you see yesterday messages on support post for Mysensors RPI Gateway, you can see some test for that guy @eyesoft and I like see this ended in that purpose on github. That's I would mean about all that before.

We can do the same about OPI boards because we are in exactly same situation and have the same test than Banana completed.

Generally speaking all this is I refer in my last post here.

Regards

Hi @pansen, yes no seems so much tricky and will need so much effort to make the proper changes to Mysensors code for install on OPI (and Banana) , but that is only matter that main code developers here that are maintaining this code like do that but in this moment I don't know what is in the developer's "brain" about include support for other boards than RPI....so like I said before we only can ask they and purpose include their support for OPI board and see what will happen.

I'm too not a software coder, so can reply properly about coding and her methods and best practices but anyone can always "purpose" the changes to the responsible developers directly on through the github repository of the concrete software (similar to report issues, purpose improvements, etc...) and then if approved by developers they make the changes to the code.

Of course always anyone can fork the github (if is licence allowed) and make another branch/project to fits its own purposes.

Regards.

@Tag
I see... Then we have a driver installed properly on OPI from where Mysensors gateway are derived that they use. So agree this issue seems easily fixable on mysensors code.
Can you now that have a NRF24 driver installed try follow the step by step mysgw installation process ( https://www.mysensors.org/build/raspberry ) and post here what happens ?

I figure that SPI library (for OPI) is needed too for the master driver TMR20h, so seems is only needed adapt the mysgw code to use this when the OPI board are detected.
I belive this next too lines extracted from your test say SPI is well detected and ready:

.....
[SECTION] Detecting DRIVER
[OK] DRIVER detected:SPIDEV.
....

I think banana boards are in the exact same situation than OPI (yesterday someone run the same tests in Banana board and have the same result) and maybe is easy can include both at same time on Mysensors.

Now is matter that any mysensors coder can ear our call and help us to deal with mysensors code

See you

Hi @pansen
Totally agree that is needed modify mysensors code (at least some files of mysgw installation process) to make work it on OPI board. But I'm little more optimistic with that because some coder here ( @marceloaqno ??? ) sure would help mostly if only is needed include the changes on code but we can offer he all the workaround about issues we found and tested all the code that can avoid the problems.
About SPI.h , of course we need provide tested the proper all OPI librarys that differ from Raspi.
Regard this I´m figure that the SPI library is included in the driver for NRF24 (Tmr20h) that @aand some days ago feedback is working fine on OPI.
If so then only will be need changed this library to de mysgw installation process when a OPI board is detected.

See you

@Tag
I agree to open a new thread specifically to try to run Mysensor on Orange PI.

With some help here from Mysensors coders I belive is possible to make it work soon.

As a summary I think that you can already make several tests that yesterday were suggested by @marceloaqno and @aanden @hausinger and in the general all OPI users for post of support to the installation of mysgw to see the result of the same and evaluate if these produce some progress in the solution.

I have some rage at not being able to do them test myself and help much bettter, but I am away from home during these days and I have no possibility.

In any case try to summarize what would be convenient to try on first place if can detect nrf24 module with RF24 driver, as suggested yesterday by @marceloaqno:

The configure script from MySensor repo is based on the https://github.com/TMRh20/RF24/blob/master/configure.

Could you try with theTMRh20 master branch and post the result?

Git clone https://github.com/TMRh20/RF24.git
Cd RF24
./configure
Make

As reference that maybe can help too below post about install NRF24 module on OPI and Armbian, that they finally make work the board:
https://forum.armbian.com/index.php/topic/3161-orange-pi-one-with-nrf24l01/

Regards

@Oli
Good !
I like when people can make something work that nobody even knows what it is

For me it usually happens just the opposite I am not able to make work even the things I know perfectly well ... maybe it will be a matter of "bad karma"

@Oli I´m thinking is hard to "only" update (changing from develop to master branch) directly from github if the repository is not been previously prepared to do this kind of updates... but maybe I´m wrong.

Will be good you give feedback if you get it.

Cheers

@Oli First you need delete all Mysensors directory on your machine.
Then use step by step the guide on Mysensors Gateway installation process:
https://www.mysensors.org/build/raspberry
Dont forget put command sudo on sentences if needed.

Regards

@marceloaqno I see some huge steps up on BananaPi...seems only need add SPIDEV support for make it working...

@marceloaqno Sadly I´m so much bussy and traveling for few days and cannot acces to my OPI´s , but I´m sure someone here (@aand , @hausinger, etc.. ) can give a try on her OPI the things we said before. At least I hope this ...

@jirm

As a side coment, the configure file is on the root Mysensors directory that is buid when you complete the first step "git clone https://github.com/mysensors/MySensors.git" on the mysgw install process.

Anyone can edit the file with a plain text editor and change the values for see what happens when try compile.

Regards

@eyesoft

Yes...I see. That error is that said @marceloaqno about own mysensors NRF24 drivers and SPI bus adapt for Raspberry, because for now mysensors is only supported at Raspi and arduinos.
On Banana CPU detection seems work better (I agree type seems not good...maybe you can change this on configure file and give a try to compile to see what happends) and I figure can work too on OPI too only changing that I said before, but then is raised NRF24 driver and SPI error.

I see that mysensors RF24 driver are derivated from that https://github.com/mz-fuzzy/RF24 build that at same time last this is forked directly from http://tmrh20.github.io/RF24Installer/RPi/install.sh that we know are working fine on OPI and armbian, so I figure that maybe it´s not so much hard to modify mysensors RF24 to adapt to work on OPI.

Hope any mysensors "coder" ear our call and cand give us some hand to make the changes on the mysensors build and we can compile the mysgw to OPI soon.

Cheers

@aand

Hi again!

I spend some time seeing and reading some of the files from the mysensors github build and I see some things that can help to understand why the error raised to @aand trying to compile on OPI.

First say that I´m not a coding expert, so please be nice with my if I´m wrong and say something stupid

I see in the .configure file that the machine detection have H3 Soc and this are fine detected , but then I see that selecting type and CPU flags seems not properly selected to match OPI specs , because on OPI soc H3 have a cpu armv7 (not armv8) and is a A20 and not A53.
So maybe that cpu "selection" is not correct for H3 soc , and is so easy try if anyone that have OPI and have time can change only that values in the config file and try to compile.
All the values on the A20 line seems correct for the OPI H3 soc, so only needed copy them from the A20 line to the H3 line, and give a try.

File Configure

.......

function gcc_cpu_flags {
local soc=$1
case $soc in
BCM2835)
flags="-march=armv6zk -mtune=arm1176jzf-s -mfpu=vfp -mfloat-abi=hard"
;;
BCM2836)
flags="-march=armv7-a -mtune=cortex-a7 -mfpu=neon-vfpv4 -mfloat-abi=hard"
;;
AM33XX)
flags="-march=armv7-a -mtune=cortex-a8 -mfpu=neon -mfloat-abi=hard"
;;
A10)
flags="-march=armv7-a -mtune=cortex-a8 -mfpu=neon -mfloat-abi=hard"
;;
A13)
flags="-march=armv7-a -mtune=cortex-a8 -mfpu=neon -mfloat-abi=hard"
;;
A20)
flags="-march=armv7-a -mtune=cortex-a7 -mfpu=neon-vfpv4 -mfloat-abi=hard"
;;
H3)
flags="-march=armv8-a -mtune=cortex-a53 -mfpu=neon-vfpv4 -mfloat-abi=hard"
;;
*)

@marceloaqno

Really thanks a lot for your work and very much appreciate you try to help us on our "fight" with the OPI board.
Sadly in this moment I cannot work because I'm out of time to try install all softw stuff on my OPI and try help much more to push it working with mysgw and so on.
I don't understand so much why is not working out of the box and the driver issue found and/what hardware communication issue are only on OPI with that similar derived Raspbian OS like Raspberry, and too not understand why cannot work on OPI because that SPI bus issue you say.
@aand reported nrf24 module work very well with TMRh20 driver, so seems hardware are OK on OPI for the module and I suppose still only discover and hopefully make it work avoiding the driver issue you say to compile properly mysgw softw.
Anyway, I only hope that anyone can help mainly here to make work mysgw on OPI too, and adapt it to work on Armbian, because OPI is a really good choice for HA controller board and sure in near future much people use it.

Is there any chance to substitute own nfr24 driver mysgw with the TMR20h, at least for testing purposes on OPI?

If any mysgw "code" people are reading this maybe can try to help us with some idea to try workaround the compilation issue on OPI.

Best regards and again many thanks!

PD: Only for test SPI purposses on armbian this can help (post 248) :
https://forum.armbian.com/index.php/topic/617-wip-orange-pi-one-support-for-the-upcoming-orange-pi-one/page-9#entry5747

Only for info, other interesting post about how to make work nrf24l01 module on OPI and armbian:
https://forum.armbian.com/index.php/topic/3161-orange-pi-one-with-nrf24l01/

Another one interesting post OPI One with armbian using NRF24 module:
https://forum.armbian.com/index.php/topic/3161-orange-pi-one-with-nrf24l01/

@marceloaqno

You mean the error posted @aand is because that?

You mean mysgw use own NRF24 drivers that is not supported on OPI although he have running Raspbian version?.

In any case, if so will be really fine if mysgw software allowed (or provide information about how to do it) to use any NRF24 driver (ex. TMRh20 fork that is working fine on OPI) and maybe too Hope RFMXX (I´m most interested in this last transceivers) because I think that generally speaking make a rigidly link with a type of hardware is not the best thing that can be done to really give the best functionality to any application.

Still keep waiting for anyone here than can help to install mysgw softw on OPI.

Thanks for your information

Best regards

@aand

The error you post seems because gcc compiler is not well supporting the processor, so maybe need substitute all gcc compiler version in the OS to solve the issue (that's I wanted say before with update).

apt-get update/upgrade cannot substituting "any" software to other because doing this only can push to last version the existing installed branch on the yet installed software on the OS.

So It's not any dependence error it's a gcc compiler error raised for some weird version incompatibility with the hardware installed. Strange error but this is seems means message error you posted. So seems needed reinstall all gcc compiler to avoid that.

Hope I explain enough...sorry about my bad english

See you...

I´m in the same boat as you, because for the moment I choose OPI hardware for my HA (Home Automation) system.
Agree with you that Armbian is much better OS than Raspbian in general terms and preferably the path to walk through for OPI, but in that case always we walk on a parallel side because Raspbian is today the most prefered OS for IoT on developments because Raspberry is the predominant hardware. So that means in future we need fight each installation.

In that case, Armbian forums sure is necesary place that can help to solve that problem too, but I think first better post here on mysensors software forums to try to get some more light about that specific error about mysensors gateway install process, and then at least have more info to report to someone that can help in Armbian.

I'm trying to find some help more about the issues you raise and if you maintain posting updates here will be so good for me and sure for others that can use OPI too now or on future.

OPI´s I´m sure is in near future a very good hardware (because they're so good relation cost-performance and quality) that mucho more people would choose for next coming IoT projects.

Regards

@aand

The las error you posted...is not on Raspbian but in Armbian ????

"gcc -MT build/drivers/Linux/log.o -MMD -MP -march=armv8-a -mtune=cortex-a53 -mfpu=neon-vfpv4 -mfloat-abi=hard -DMY_RA
DIO_NRF24 -DMY_GATEWAY_LINUX -DMY_DEBUG -Ofast -g -Wall -Wextra -I. -I./core -I./drivers/Linux -c drivers/Linux/log
.c -o build/drivers/Linux/log.o
cc1: error: bad value (armv8-a) for -march switch
cc1: error: bad value (cortex-a53) for -mtune switch"

In any case seems this is a gcc compiler error maybe because "wrong" version for that processor...so maybe trying to update gcc compiler can help to avoid that error?

@aand

Ok. Arrrggg ! .
So sad ear that OPI Raspbian fork is too not working out the box and but its not surprise because the poor software support form manufacturer. Maybe this is another no way road.
So seems only keep fighting with both OS (arm and rasp) to make it working.
Some sugestions ...
Will be fine if can post this issue but in software section here on mysensors forums. Maybe some mysensors gateway developers or any linux hack can help to trace the error you have on armbian or raspbian.
Maybe can find another "no official" OPI Raspbian fork that compile better to mygateway. Maybe post this issue in OPI forums will be good and someone there can help or provide other better Raspbian fork.

Sadly in this days I dont have time to try install on my OPI´s to help more.

Regards

@aand.
No dubt that NRF24 is detected and working on Armbian, but seems not properly detected on the build module process for the gateway installation process made for Raspbian. Sure because OS diferences from Raspbian and Armbian, raise this issue.
Why not directly use Raspbian on OPI to avoid that and sure other issues that will by found because all software are mainly build for Raspberry (Raspbian OS) and that is the only well tested?

I see Raspbian is available and updated for OPI trough his manufacturer.

http://www.orangepi.org/downloadresources/orangepipc/oragepipc_e930546e866b23585721e5d2a6.html

Regards

@aand said:

Orange Pi One

@aand

I think, maybe the hardware nrf24 radio its not properly detected or ready on OPI?
Seems ready state of the nrf24 board is needed in the moment to build/make the compilation of that module for the myGateway.

We have any chance to run any Raspbian version (not armbian) on OPI ?
Sure have so much differences about raspbian and armbian to aply same softw installation methods on both without adaptat in each case.

Im so interesed too for use OPI One like my HA Controller and MQTT Gateway, so will be really good if you can post here any evolution and impressions about using OPI for that.

Cheers

Sorry about the delay. So much bussy these days.
Pictures from my switch version:
3 first are from a dimmer, last are from swtich remote 1 gang - 1 way.
And a quick view I can see maybe only some little diferences comparing @Tigroenot version on main board mainly I see the antenna on mine and not on @Tigroenot and the central connection pad that seems he have on the rigth, but totally diferent on touch board I suposse because his pics are from a dual swtich version.
All my switch has ben purchased only 2 monts ago.

@Tigroenot

Thanks for the pics. I see now little much better how you wired and what is needed modify on switch board (wired bridges on red) to make it working. But form me still need added the schematic for understand all conections from/to arduino+nrf24 and Livolo to really see how all are working together.
So sorry yestarday but I stay so so busy to take pics from my switch´s, but I try today do my best to take some pics of them.

I think is so so similar connection like guys from smartsystems controllers are doing for her comercial project s you can see in schematic at min 2:30 on this youtube video https://www.youtube.com/watch?v=LNEE9tjnHR8

If it are so and are the same wired on both (your connections and smartsystems are doing to) I think the connection sources from livolo switch are well tested (over enough time and from diferent people) and is at this moment the better aproach to do that connections to livolo swith.
That is a great step.

I Still figuring how much current can drawn from livolo switch and how doing that in a secure maner and with a generical way to supply "any" radio system (better if can including esp) for provide livolo´s with feedback and additional remote way of control because for me still some dubts about that question. But like I say yesterday seems is time to test and test and not more throw more assumptions.

Regards

@Tigroenot Sorry I dont know Domoticz, and only few little steps in Home Assistant and in past some on Openhab...but I belive that any people there in Domoticz forums can help you for sure to make that work.
I only "ear" that easyesp is so "easy" to make it work with domoticz and for sure you know is trivial for setup easyesp to work a simple relay with any easpeasy sketch for that.
I dont know your exactly issue and how to help you better and also I'm a real newby in any home system, just starting now only with some few steps starting to try to make work livolo's like I want with a realiable (and hope easy way) to provide a good feedback status from them hope universal for any home automation system.
We need some look, but seems close to have some good results.
See you

@Tigroenot Ok I wait your pics. I half understand that you say we need to do but better "see" how do it that not suposse because is easy to kill the switch if that is not do it propperly.
I have same problems than you to post here pics from my switch boards and so on (I have all my house with livolo´s... near 40 switch) and need too some time to take good pics and feet to post it here, but tomorrow can upload some of them.

See you

@jirm
@Tigroenot .The BOD fuses you mean that we need forced to work the 328p at 1.8V and not at 2.7V as default is usually done?
How do you power the arduino + nrf24 circuit?
From what voltage of the switch livolo and since what "pins" ?.
I am not able to see exactly where to extract the feed (in the real circuit board) of the plate on the livolo (I use the version 2016 EU of switches).
You could put some schematic and / or pics regarding how to connect the feed on the livolo board because in the posts I have seen above I am not able to verify it in what correspond at least to my EU version switches?
regards

@Tigroenot Thank you for your quick reply.
I think additional power supply is not the right path for that, because needed modify all house wiring is a real pain and most costly solution.

If 250ma drawn current is avaiable from livolo switch I think is really so close for the "calculate" needs for a esp8266, so maybe is time to real test it and see what happends but If esp cannot not work properly it does not matter because you say have stable working arduino+nrf24 that is equal good solution or in some cases maybe better than an alone esp.

Maybe we always easily can add one parallel capacitor at loads (any 0,47nf X2 400V rated or livolo can provide someone too) to increase load current drawn if we find that some switch cannot drawn enough power from his load?

Regards

Too I´m start working to provide a universal way to feedback status (for HA) to all my Livolo switches. My main concern is how can get enought supply current to my radio circuit (actually im thinking on ESP8266) from a standard connected switch (only the live AC wire avaible for supply on switch wall case) because needed about 3/5 V with 300 ma (peak when wi-fi are at full work) and I cannot see how the supply circuit in the livolo switch can provide that enough amount of power to supply this element.
I cannot see nothing clear how can draw that amount of current trough "any" load connected over the switch...

@DJONvl or anyone had well tested what amount of power supply (3V or 5V,) can "secure" draw trough standard connected Livolo switch ?

Can any confirm if that circuit arduino+nrf24 have self power supply (additional) and how need connected and mainly how much current drawn arduino+nrf24 when they are full working ?

That guys https://www.youtube.com/watch?v=Ny8Rt75he0A had working a circuit (comercial purposes) but seems use aditional power supply for that.

Regards