I can't figure out how to test the balance of given accounts when writing unit tests.
For example, Bob buys something. He pays 10 NEAR. 3 NEAR should go to alice.near, 7 NEAR should go to bob.near. I want to check if the 3 and the 7 NEAR are there. I'm using VMContext. I tried switching the context, so I can use env::account_balance(), but that will not solve my problem.
let mut context = get_context(600_000_000_000_000_000_000_000); // Alice is person who interacts
testing_env!(context.build());
let mut contract = Contract::new_default_meta(to_valid_account("vault.near"), to_valid_account("carol.near")); // Vault is owner, Carol will be admin
let price = U128(500_000_000_000_000_000_000_000);
contract.mint_root(test_token_metadata(), to_valid_account("carol.near"), price.clone(), None,
Some(HashMap::from([ // Alice: 20%
(to_valid_account("alice.near"), 2000), // Vault: 80%
(to_valid_account("vault.near"), 8000)
]))
);
log!("caller: {:?}", env::current_account_id());
log!("Alice balance: {:?}", env::account_balance());
context.predecessor_account_id(to_valid_account("bob.near")); // Bob interacts with the contract
context.signer_account_id(to_valid_account("bob.near"));
//testing_env!(context.build());
contract.buy_nft_from_vault("fono-root-0-0".to_string());
context.predecessor_account_id(to_valid_account("alice.near")); // Bob interacts with the contract
context.signer_account_id(to_valid_account("alice.near"));
log!("caller: {:?}", env::current_account_id());
log!("Alice balance: {:?}", env::account_balance());
I'm looking for a function that looks something like this: context_get_balance("alice.near"); And it would give me the balance for alice.near in the simulated blockchain. Is it possible to do this somehow? Maybe it is not possible to do this. If not, what is the best approach when writing similar unit tests?
Related
Please help in adding a take profit to this wonderful script, currently the profit is being taken after the appearance of an opposite signal, and I am looking for adding a percentage instead, for example, when 2% is achieved, the deal is exited, I tried to modify a lot, but the result comes out the opposite of what I want When I order a long, the quarter-reap signal appears down by 2%, and vice versa. Link of script: https://www.tradingview.com/script/HCfdtUut-Neural-Network/
//Long
if tradetrendoption ? alternatelong and mabuy and longpositions : alternatelong and longpositions
strategy.entry("longposition", strategy.long, comment="Long Entry")
if (shortentry or printstoplong) and longpositions
strategy.close("longposition", comment="Long Exit")
//Short
if tradetrendoption ? alternateshort and masell and shortpositions : alternateshort and shortpositions
strategy.entry("shortposition", strategy.short, comment=" Short Entry")
if (longentry or printstopshort) and shortpositions
strategy.close("shortposition", comment="Short Exit")
I'm trying to create a script to sell token on pancakeswap and cant seem to get it to work.
I'm able to buy just fine but cannot sell.
I'm getting Fail with error 'TransferHelper: TRANSFER_FROM_FAILED'
The script is a hit and miss with the balance of the tokens depending of the decimals. I just wish there was a way that I could put 100% of balance.
pancakeswap2_txn = contract.functions.swapExactTokensForETHSupportingFeeOnTransferTokens(
tokenValue, 0, [contract_id, spend],
sender_address,
(int(time.time()) + 1000000)
).buildTransaction({
'from': sender_address,
'gas': 1800000,
'gasPrice': web3.toWei(input("How much Gwei: "), 'gwei'),
'nonce': web3.eth.get_transaction_count(sender_address),
})
signed_txn = web3.eth.account.sign_transaction(pancakeswap2_txn, private_key = config.private)
tx_token = web3.eth.send_raw_transaction(signed_txn.rawTransaction)
You just need to enable/approve the tokens you want to swap in PancakeSwap. I did it manually (buy and sell each token to approve.)
I'm trying to replicate values from pine script cci() function in golang. I've found this lib https://github.com/markcheno/go-talib/blob/master/talib.go#L1821
but it gives totally different values than cci function does
pseudo code how do I use the lib
cci := talib.Cci(latest14CandlesHighArray, latest14CandlesLowArray, latest14CandlesCloseArray, 14)
The lib gives me the following data
Timestamp: 2021-05-22 18:59:27.675, Symbol: BTCUSDT, Interval: 5m, Open: 38193.78000000, Close: 38122.16000000, High: 38283.55000000, Low: 38067.92000000, StartTime: 2021-05-22 18:55:00.000, EndTime: 2021-05-22 18:59:59.999, Sma: 38091.41020000, Cci0: -16.63898084, Cci1: -53.92565811,
While current cci values on TradingView are: cci0 - -136, cci1 - -49
could anyone guide what do I miss?
Thank you
P.S. cci0 - current candle cci, cci1 - previous candle cci
PineScript has really great reference when looking for functions, usually even supplying the pine code to recreate it.
https://www.tradingview.com/pine-script-reference/v4/#fun_cci
The code wasn't provided for cci, but a step-by-step explanation was.
Here is how I managed to recreate the cci function using Pine, following the steps in the reference:
// This source code is subject to the terms of the Mozilla Public License 2.0 at https://mozilla.org/MPL/2.0/
// © bajaco
//#version=4
study("CCI Breakdown", overlay=false, precision=16)
cci_breakdown(src, p) =>
// The CCI (commodity channel index) is calculated as the
// 1. difference between the typical price of a commodity and its simple moving average,
// divided by the
// 2. mean absolute deviation of the typical price.
// 3. The index is scaled by an inverse factor of 0.015
// to provide more readable numbers
// 1. diff
ma = sma(src,p)
diff = src - ma
// 2. mad
s = 0.0
for i = 0 to p - 1
s := s + abs(src[i] - ma)
mad = s / p
// 3. Scaling
mcci = diff/mad / 0.015
mcci
plot(cci(close, 100))
plot(cci_breakdown(close,100))
I didn't know what mean absolute deviation meant, but at least in their implementation it appears to be taking the difference from the mean for each value in the range, but NOT changing the mean value as you go back.
I don't know Go but that's the logic.
We have a prototype of esper running, but the performance is considerably lacking. I guess this is my fault somehow rather than inherently an issue with esper, so was looking for help in locating where my performance issue is.
I am running one instance of the esper service, and I have allocated the memory constraints as follows: -Xmx6G -Xms1G (I have tried various combinations of these values). And it can use 4 cores of the CPU. No other services are running at the time of these tests, only esper, kafka, zookeeper.
I am using Akka Streams to stream events into Esper, the service is very simple, it streams in from kafka, inserts the events into Esper Runtime, Esper has 3 EPStatements tested and working. There is one listener and I add it to all 3 statements, the listener outputs the matched events to kafka.
Some things I've tried to isolate where the performance issue is:
Remove some EPStatements
Remove all EPStatements
Remove Listener
Remove EPStatements and Listener
Remove esper .sendEvent(...) (This improves performance significantly, so it seems an esper issue, rather than an akka issue)
Only number 4 above caused any significant observable performance benefit.
Below is an example query we're running through esper. It's tested and works, I have read the performance tuning section of the documentation and it seems ok to me. All my queries follow a similar format:
select * from EsperEvent#time(5 minutes)
match_recognize (
partition by asset_id
measures A as event1, B as event2, C as event3
pattern (A Z* B Z* C)
interval 10 seconds or terminated
define
A as A.eventtype = 13 AND A.win_EventID = "4624" AND A.win_LogonType = "3",
B as B.eventtype = 13 AND B.win_EventID = "4672",
C as C.eventtype = 13 AND (C.win_EventID = "4697" OR C.win_EventID = "7045")
)
Some Code..
Here is my akka stream:
kafkaConsumer
.via(parsing) // Parse the json event to a POJO for esper. Have tried without this step also, no performance impact
.via(esperFlow) // mapAsync call to sendEvent(...)
//Here I am using kafka to measure the flow throughput rate. This is where I establish my throughput rate, based on the rate messages are written to "esper_flow_through" topic.
.map(rec => new ProducerRecord[Array[Byte], String]("esper_flow_through", Serialization.write(rec)))
.runWith(sink)
esperFlow (Parallelism = 4 by default):
val esperFlow = Flow[EsperEvent]
.mapAsync(Parallelism)(event => Future {
engine.getEPRuntime.sendEvent(event)
event
})
Listener:
override def update(newEvents: Array[EventBean], oldEvents: Array[EventBean], statement: EPStatement, epServiceProvider: EPServiceProvider): Unit = Future {
logger.info(s"Received Listener updates: Query Name: ${statement.getName} ---- ${newEvents.map(_.getUnderlying)}, $oldEvents")
statement.getName match {
case "SERVICE_INSTALL" => serviceInstall.increment(newEvents.length)
case "ADMIN_GROUP" => adminGroup.increment(newEvents.length)
case "SMB_SHARE" => smbShare.increment(newEvents.length)
}
newEvents.map(_.getUnderlying.toString).toList
.foreach(queryMatch => {
val record: ProducerRecord[Array[Byte], String] = new ProducerRecord[Array[Byte], String]("esper_output", queryMatch)
producer.send(record)
})
}
Performance observations:
Input stream has a rate of ~2.4k per second.
We see esper is unable to keep up from the beginning. Maxing out at ~600 per second
Esper gradually decreses in throughput
Eventually esper throughput stabalises <100 per second
Profiling, nothing seems out of sorts here:
The rate seems very low, so I am assuming I am missing something here with regards to some esper configuration?
Our target throughput is to have ~10k per second. We are a long way from this, and we have a similar POC in Spark that gets closer to this target.
Update:
Following #user650839 comments, I was able to improve my throughput to a steady 1k per second. Both of these queries produce the same throughput:
select * from EsperEvent(eventtype = 13 and win_EventID in ("4624", "4672", "4697", "7045"))#time(5 minutes)
match_recognize (
partition by asset_id
measures A as event1, B as event2, C as event3
pattern (A B C)
interval 10 seconds or terminated
define
A as A.eventtype = 13 AND A.win_EventID = "4624" AND A.win_LogonType = "3",
B as B.eventtype = 13 AND B.win_EventID = "4672",
C as C.eventtype = 13 AND (C.win_EventID = "4697" OR C.win_EventID = "7045"))
create context NetworkLogonThenInstallationOfANewService
start EsperEvent(eventtype = 13 AND win_EventID = "4624" AND win_LogonType = "3")
end pattern [
b=EsperEvent(eventtype = 13 AND win_EventID = "4672") ->
c=EsperEvent(eventtype = 13 AND (win_EventID = "4697" OR win_EventID = "7045"))
where timer:within(5 minutes)
]
context NetworkLogonThenInstallationOfANewService select * from EsperEvent output when terminated
However 1k per second is still too slow for our needs.
The match-recognize is ill-defined. An A-event or B-event or C-event event can also be a Z event since anything matches a Z-event (Z is undefined). Therefore there is a HUGE number of combinations that is possible. I think for 4 incoming events there are already like 1*2*3*4 combinations that the match recognize keeps track off! Match-recognize tracks all possible combinations and when stuff matches match-recognize sorts and ranks the combinations and outputs all/any/some. Match-recognize may be a poor choice here or maybe define Z as something that doesn't also match A/B/C.
Instead of match-recognize I would go with a context that initiates with an A-event and terminates with a C-event with "output when terminated".
Also, they way you designed the query the time window will retain all events. You could do better.
select * from EsperEvent(eventtype = 13 and win_EventID in ("4624", "4672", "4692", "7045"))#time(5 minutes)
match_recognize (
.........
define
A as A.win_EventID = "4624" AND A.win_LogonType = "3",
B as B.win_EventID = "4672",
C as C.win_EventID = "4697" OR C.win_EventID = "7045"
)
Notice, the EsperEvent(eventtype=13 ....) discards events before they go into the time window. There is a performance tip in the docs around using filter criteria to remove unwanted events.
EDIT: A mistake is measuring IO throughput and Esper throughput as one. Remove the IO. Test Esper using Esper APIs with data your code produces. Once confident add the IO back.
I am trying to use ECDH/ECDSA to secure my transport. And I ported micro-ECC to mbed as a test, since I am not familiar with assembly, all assembly optimization is disabled. Here is my project.
The running code prints information to console as following:
microECC test
Start ECC computation
make key 1
RNG():
5647A0B05F947B4958E6AD073D1B1BC844B973131247106CAA89BBA6747D965
7828AC7240A3733939EC09EE3327EAB55A366239516FFDE82AABAAAA428A8E9F
A85C8C162E8AADA7407F2BF7ACDF6DC6EFE2C7111B91623612C979C32776F7D
182D69A2108F85E37F36B3428A8EA07C05EA8C608983425E6A460458AD465B
6AC6DC351EC5D4E75FB55FD7749971E16E5CA069A56C20730F1D8525E43FFA
2A81D1F46817F40B18EEF5606797208B591A9A8D79B30FA76C6942DA1F464239
518458C17CE01045477D06FA597B0388248BB0C379B03DC93A4B33414CC89B6B
2702D42E4A606F071FF24B7FBFC60671E69F7E87AC35024332C9D453A7388
5F3902CB45349175ECF5BD7C307884465B0BB745B979111605E2C33384756
4E3841E96CAE82C239B6838A1FF80FF92B9F6AF671E57CBD15CAF3EA63C5BF3F
7642C9234191B9CE4EA408A7767A18D15E900F2C3D03FB6448E7839B257C889F
79F2306F1491BE021410231B5240D0002FCFF2AF307918102D266E85143DBC40
56FFD07A264869663FAFA43741B9BD241F8058F23A74221319B948512403982
663D2C8066DD7D4C6523D7EB568D1072491FCF9149D80AA9340603E9BD8333
545E49B652AF11BF5B23665670A99AEC176DB6752074AC5C225BB4D97815676F
74601D7C3707C3530194C955BA764B2C7E06EE17BCC4207E37F7D1D4B3E3F
354CC32C13C25EF67F8BA1C0453D296229AE6D664460F8C7688889317FA3286
462F7DF42B6E7F282B1DB175287CF0BE102FCB474FF7952B2381746C571BC4
677A38B1209B0CE6C504C5DA09E170105A0D0A6C46A8B562959FADAAE73B7
115B3CC84BDC6F97900289E156913B548ED461D2E70B58A245849A96256BCDA
4162196C1242AA2D709A9E5735FFC6415C5EB8F24B01AA411985BD2972D9555C
7D0F65481769C4842D09E1E152114EB912DED22A5A9A607E76B5047061C578E8
23993CDF1D2879B47FC5C7FF7CC79DF148EE489384652FB5306B8587718A3C4
781DE9DE227DB88F420C93EB373998F52F34B99375D7D1BA7E00055B4CE5647A
public1:
FA624B9E629CD6ACFA0F27B38E937FCA9B85610412E25DAA2044BF0D05DAD5E0A7FB0EFBB152147D
private1:
005AA72C06F34B2D2EAAB395EE70CF5DA261AD5969
time: 293ms
make key 2
RNG():
403BAB06244092E721807F8D2C4FC4162D5496BD6C9927E619BB3F2A7427F1B3
5B6B432D5AD7761D64424272D5D380D23CFB62E22D072807AA8BA7972E22130
2E67B3333FB4BFDB6D2FE1E7A03908E36128251642F642970DEFFCD4F37250C
19A66B8311FAF0709D0BBA615D3373C7A7C79EA2C5614F966C4126E7CEE94B1
282385F91A9134162D8B2A2C3EFE4356A17815677DA72D07ABE35BB5C5D8A27
63B9BA5518BD3216437CC4AF48C7E167227ADC9C23F9BC5B614FF84F30C68D3C
5D064FB81FC6891B22E548C5521C96A542CECC7A324548E6D1ADB6A54DCD923
4112C6264EE2C42D41648A88AF1CD003C8E4600616DDE903F344D822346E650
7CBB54BC73CF9B2D44162A324C1870D27B223074748678145B3DF11384BFF7
5BCAFC2329E832235586E2CD2A83B84C1AD741275559E1996A489E064E4CA07A
55DE6EAA23D704697D25289616942CD8275DC73F5926982468C80CC959E41041
538461A8646F5231146AF60F1EF3B3D211C2DF44DF7B815424C9D627D5D540E
BADC4714BE1C2D444D1182C2BBF44D2302B3E8454D4BB186F53DB54129825B8
C2076591AFDB4865990A8D326F547BE732216312BB7C8EE75B6FCB23EAD3F89
5BB4DF8D69EAE87552E8D995FCF563358929D4E2737FE79141B9A944D48902A
4E66031E4FA3F93A2B5E684554165C707BB3070E4CC3DFE74E8DFFD58D182D1
4EECF6668F92B39792A44A1E7319BD7F03D1A45DD8C78C2F5274523F5DE801
3F8832F8100E39DD5E819EE9593176AE1E6DE7A2538264C2381CFEEF232204F8
1410F25B788BED3535BB9C4BC1A186515516F715A531356BD2920B353F2EFC
39D09BB262DCB67722CEFE0F67FC2EB77DF2CE2A126C2BA24DB1289E6445D164
7E1FAF7C74CCD1602018CCEB46EFD7BEB18B067EE04DE4C2E3CB888B3803
6E735880798E58F045FBEBD3555C9E905222467A68100C1F21A797F52204CF18
17A98EE8185DBB8A49A3D7D124CD485D2BB7C2BD2F3E8613471831D915606222
2F1E08B1547D8B7F31A97CBC3E9E7259C40CCAC781FE6886775AEB978BAF
RNG():
790A66D74370521F2165EE8D73D20D565F9C2FAA790809CE64CD667B6F4907F5
150965DD17CD22F0C7F8B2DB6E5F85C023C264374B03630F2DA3DC14543C
72F70D1A4061862C7FED7EF11DE66BBB8CC8BB06FC0DC5A7BE7758F58F5EFBD
33C6E2D56391DB3844EEC3682541B3D26E3FEF6853E93F422398CF6A3AF72801
9D6D9F31865D7653E1F0A2356573FFC739B95A325569E2F7AEF7BAB5618A250
1E68D403114D0296C1168403BFA7043A1FAE49823044915B700D92D698EC
7EDD3F018C4DDE26F8EA64713305D7ADAD11A014B7BBFB35218CC545928CDE
2DD8D4BE19461FBA612104E5EF2218615481C0B710084105376D8D85198AF01
268B632276727582BE897426367AEDE6506AB695B5C1568389F5D2DE04B73A
6303EA524929A92F5545772418CD8C382F2A90FE75FE08447BA5917C3503B3B3
7FC65D4C6260CE7E355F69477B573C564A8F7DB44EB9DB8120B3D7169D94362
502F963F22B3F35321B9CBB27A3B4E2B3FDCAD5E6455033F83817B16A904EB2
5762D58D2CBEFA815290AAC27504A8D579579FC96520DF3B4AA49ED44760BC93
18B7DB5255D7DE476E412395677672AE3ED46F3A49B3E40F58A8A4F12E08E306
3BC5C90D8AED008281937C29CE470662938D561AD1922725E2DE7AAE7F9CC
2DAD303F129164DF42284DFE4C13C8A0599007B964DC1E0248633F5E6F3FBBCB
7598E8893510BD2B765225975D8411E81283F9885714772B60ABAABE69E50B86
59BB14E37668D54399C2796395A286B4D89E174615B25A0309AB0164FC043
1A0EB6243D515529796A55A94792FBCA3E3B254C102DA43535655E805AD76A98
5239D4E0603638D75FE7E36A1C730E676BA51FB6E32D1FB5989BD273DF8C760
789313FC183396BC48A508183B291BFF209DAC5B37B9F0FF3D3DF9C4745C2598
7C14BDDA2195E24963776BAB16F2204C4DBC94D3461C67BD66CCAB7C4927FDA5
192E8B55165F72566A7D8BE25D54482564B47BB1D5C31F55CA4D5FA658461C1
57F6D2D56A575E55627860C869AAD8D3399C9C3A4BBDA80979F6C33E3109784F
public2:
85BFA8BDEBB60ACF996FFA810BF6B21D291B71488C0DC505B647D6EDF23C0612A2CC1F8AFD70DADD
private2:
005E64D1E4C98466DDD62A410A29264EEE8133A2E3
time: 430ms
make share secret 1
RNG():
26EAA6DF22BEA937F2C68B41A084AA438C36773F2D05035E73D657243C6A25
2EF7A4E83F7FAE9654D8A9887A78D1687B7AA385D867EF91C8B66066FF67C73
F57D2F073EA8F1B76E25A4D65884D7212857F91CCB724A6DB357323C7B3E7D
B8444D60F35CD365137F577EEA209712DD606865E612F73AD03DB22E8EE99
17A93C833D8EA1A91D8025284C3A40653FD5461F4B2CE62976C3964DF70AD70
67C8E5053E896F91364CF1EB3694D77B3A292B6A4AF6A70232D154DF33F01522
6949A64617DED047721E86165993D68387211AB11238F6919F6584A712B673C
7F67C388678B150F49C309405F32205651EB0B70430490BC11B5E00452AEA47E
689AECE7389658C9781890113379A135222CDA9F20AAE92250AB3A1419CBFE7A
2E76FFB5650CAB7E16D587645E4EF20A558F3A6D4DBC795B12B6065576801F7B
25E54E893EDE3C8C567D8B7F67433D0670E906F1AC1CA1B3EDE1D5D1987C19
12299C62BF15798DBCFE795BE3E074CAA89C53D526436BC08A5A1C836097
71E47DBE66C3DAA31D7B8AD15F0B3192758BBFCD65DA59AE145588C965814E8B
5B8ED2F65AEA96105A975FB85A3595D340383F45CBC43756D445F813BE5AA93
52906B0D1514FD87E4F74EA2391C4A65578E0C73B5E5E11C1CD99482B7F6
4EB8E2F34ACD3C587086D5663AECFE33503FFF6F14FADB7422155F8510193A76
142CF4A02356BD163BF1457A7C5F1486672ABB4D4B943B906A496AC65FD9A05C
CCDD05D6B5E44E01D1E87266D89B7372DC4254F11D5B1A85D5E2D79784D9AB2
7FFF52BC45E8F7C65D67E4067990EB211D30C78E2D8238A634AB0F5E3CDEB1B6
2E1F30A11DD0310B5DD6470A69C7E0AB7EAE43D954933CC53607ABD16ED708DC
r: 0001
secret1:
AA343FE06CD9534E38DCB762B5EE3590FDA318BA
time: 265ms
make share secret 2
RNG():
87E54CF4A3D8C24266D2D6910373029B367F68170F0FEF1A340B2E2DD291B1
1272327D718CF6AE323938426974B4A36781C7F1315B93618B2036A3248918F
331B0A87D4C439117ECD85421D42263B30FC95309C101C3E83FF29783F550A
69DBF82977DF2BC2755EDF13B84AE422693D13654E3E34968A330386335C2F8
4F4E0B8DCC9B0B038587D4734CE1AC07E0BDA094A06CBC76E47732A44C01DB1
5FF58FAB65AE65F39587E0C217F0B5810ED532B1DA260A26F0BAD1B1F7C1117
300BECF47A04B2D63F00D90E4CA9D0F96DEA8AE56DD9954678E4D4BC6846A887
1CCA26ED54E83DFD35F60D18156086D6791B0FCE4436A5133D8CD0A36705B6BE
6D6C7CCD7917C6F21E5E00F16900DA72BBCB3E524E01EC22F28FEA43E60071C
42FEF6E11FE764D57E360A5E3C9299181D8A7ED15FCD62C14326406C2EB56AF0
328E6C9F7C2DED7863E09E72DF3589861C6C13D643B54CF22150711616D86FF
5A7231857061C65A1934BB8944E6A242366F12041C32F585D585BF13D7C39BF
6E971F861E7C2D567730F1C1735C81134FC44DB7001D70EEBF47BDB23C688
4E44287746594A462379EA695AEFA5CB19E5B7F9587905971517BFAE69C83010
646E962E2597F4DA19AA5AC74A7BFA9C5D5804E187C35D750A12F9F65CF8EA4
34737A6970F02868594C7DE768174BF438C10643A57114A62F574ED4CD32591
C53462048D52BC63A5B0DEDE39F64E2ECE9F9A4C8D8BA54C36A71018F4D477
94163D052F6CC2C3A33E7AB30F111C31F89DC2E2B4328C6582733A11168F7D
198B8B25415FAA6B407727B4D394E1A1B84F0B578EEE2FF4EEE94281BF86FED
14A83511752434E267DFA09848EF6D87744A4DBE44F110EE46FC046E4FC1F034
r: 0001
secret2:
AA343FE06CD9534E38DCB762B5EE3590FDA318BA
time: 265ms
However, the result keeps same, including random number, public/private keys and shared keys. I actually added a random_test() to check its RNG.
#if defined(RNG_TEST)
void randtest()
{
uint8_t buf[16];
pc.printf("randtest():\r\n");
for(int i=0; i<16; i++){
buf[i] = rand();
pc.printf("%02X",buf[i]);
}
}
#endif
And its random number keeps changing anyway.
Well, eveything is caused by a poor RNG. The rand() is not a TRNG. So the result always the same. Now I used two seperated ADC as RNG, so at least result for Private/Public Keys, Share keys and random numbers are changing every time.
Now I moved to verify the ECDH with Python counterpart. If it is successful, then a simple ECDH can be used in a real IoT project.