Cannot pair MSS315 via MQTT

Version of the custom_component

Latest
Describe the bug
After seeing this issue https://github.com/bytespider/Meross/issues/72 I cannot pair the MSS315 on either a local broker and the meross lan add-on. The android pairing app does not work (I have to use matter for setting up the wifi) and when running the command below the device fails to connect (see logs) and then resets itself
npx meross setup --gateway  192.168.X.Y --wifi-ssid ssid --wifi-pass password --mqtt mqtts://hass:2001 --wifi-cipher 3 --wifi-encryption 6 --wifi-channel 1 --verbose --key keyigotfromtheandroidapp
Debug log

2023-12-11 16:40:47.635929141 DEBUG:Broker reported client (null) (username: censoredmac, ip: 192.168.X.Y) disconnected for reason -1
2023-12-11 16:40:47.635707088 DEBUG:Local MQTT: received message on topic $SYS/client-disconnections: b'{"event": "disconnect", "data":{"client_id":"(null)","username":"censoredmac","address":"192.168.X.Y", "reason":-1}}'

This is very criptic.
Where this log comes from ? i.e. mosquitto log or ?
I cannot find anything about reason: -1 and I think it would be better to inspect the mosquitto logs (set to verbose) in order to get more insights about this.
Apparently, the issue is between the device and the broker which somehow cannot correctly establish an MQTT session

This is very criptic. Where this log comes from ? i.e. mosquitto log or ? I cannot find anything about reason: -1 and I think it would be better to inspect the mosquitto logs (set to verbose) in order to get more insights about this. Apparently, the issue is between the device and the broker which somehow cannot correctly establish an MQTT session

I was using the wrong extension but the issue still remains. These are the relevant logs (I am now using my local mqtt broker with self signed SSL certs):

2023-12-11 19:39:16: New connection from IP:51725 on port 8883.
2023-12-11 19:39:16: Client fmware:randomstuff disconnected, not authorised.
2023-12-11 19:39:18: New connection from IP:51726 on port 8883.
2023-12-11 19:39:18: Client fmware: randomstuff disconnected, not authorised.

Of course I did create an user with the info given by npx meross info -g IP
Btw, where do I find the key for pairing? When not specifying one it fails with Error Unable to connect to device. I was using one created by the extension but I don't know if it's correct.

I also tried with the following docker configuration and container with authentication disabled but I still get the following error and then the device resets (If I query it fast enough I can see that the change has been made, and then it fails to connect and returns to pairing mode)
mosquitto_container  |<PHONE_NUMBER>: Client fmware: randomstuff disconnected: Protocol error.

docker compose
version: '3.5'

services:
  mosquitto:
    container_name: mosquitto_container
    image: eclipse-mosquitto
    volumes:
      - ./config:/mosquitto/config/
    ports:
      - '8883:8883'
    restart: always

mosquito config file
port 8883

cafile /mosquitto/config/certs/ca.crt
certfile /mosquitto/config/certs/server.crt
keyfile /mosquitto/config/certs/server.key

allow_anonymous true
require_certificate false

Using emqx I managed to make this happen (removing all authentication and having all users having all permissions)
2023-12-11T22:22:46.629134+00:00 [info] msg: authorization_permission_allowed, mfa: emqx_authz:log_allowed/1(507), peername: 192.168.X.Y:52372, clientid: fmware:randomstuff, topic: /appliance/deviceid/subscribe, ipaddr: {192,168,X,Y}, source: file, username: <<"M:A:C:A:D:R:E:S:S">>
2023-12-11T22:22:47.817932+00:00 [info] msg: authorization_permission_allowed, mfa: emqx_authz:log_allowed/1(507), peername: 192.168.X.Y:52372, clientid: fmware: randomstuff, topic: /appliance/deviceid/publish, ipaddr: {192,168,X,Y}, source: file, username: <<"M:A:C:A:D:R:E:S:S">>
2023-12-11T22:22:49.788103+00:00 [info] msg: terminate, mfa: emqx_connection:terminate/2(673), peername: 192.168.X.Y:52372, clientid: fmware: randomstuff, reason: {shutdown,ssl_closed}

So it still seems it likes to disconnect itself?

well, beside the authentication issues with mosquitto (the config looks good but maybe you have to fine tune the TLS and MQTT protocol level for mosquitto since you have a protocol error in the log - I guess the Meross could be working with 'legacy' settings like MQTT3.1 and TLS1.1 or so and maybe mosquitto has now stricter defaults)
getting to the working part with emqx I would need a complete dump of the payloads sent to those topics:

/appliance/deviceid/subscribe: this is a topic which is not subscribed by meross_lan since I don't expect this topic to be used in typical usage (but maybe new devices implement a different protocol 'handling'
/appliance/deviceid/publish: this is the topic which is used by meross_lan to listen for messages from devices and should actually be parsed

Also, regarding the 'deviceid' part of the topics: is it really only the deviceid (typical 16 bytes HEX) or does it like having a different format like 'userid-appid' where:

'userid' should be an integer (maybe HEX?) representing the account id in Meross cloud (but this should have been set by the meross setup utility and it likely defaults to 0 or '' (or None ?)
'appid' should be another 16 bytes HEX identifying an instance of the Meross app who's this topic is directed

Here we're going into real guessing since this topic should be used by the device when it replies to a message sent by a Meross app over the cloud MQTT brokers...that's why this isn't expected in meross_lan
I hope this is not too cumbersome since I'm really guessing a lot

well, beside the authentication issues with mosquitto (the config looks good but maybe you have to fine tune the TLS and MQTT protocol level for mosquitto since you have a protocol error in the log - I guess the Meross could be working with 'legacy' settings like MQTT3.1 and TLS1.1 or so and maybe mosquitto has now stricter defaults)
getting to the working part with emqx I would need a complete dump of the payloads sent to those topics:

/appliance/deviceid/subscribe: this is a topic which is not subscribed by meross_lan since I don't expect this topic to be used in typical usage (but maybe new devices implement a different protocol 'handling'
/appliance/deviceid/publish: this is the topic which is used by meross_lan to listen for messages from devices and should actually be parsed

Also, regarding the 'deviceid' part of the topics: is it really only the deviceid (typical 16 bytes HEX) or does it like having a different format like 'userid-appid' where:

'userid' should be an integer (maybe HEX?) representing the account id in Meross cloud (but this should have been set by the meross setup utility and it likely defaults to 0 or '' (or None ?)
'appid' should be another 16 bytes HEX identifying an instance of the Meross app who's this topic is directed

Here we're going into real guessing since this topic should be used by the device when it replies to a message sent by a Meross app over the cloud MQTT brokers...that's why this isn't expected in meross_lan
I hope this is not too cumbersome since I'm really guessing a lot

deviceid is a 32-char hex string like this<PHONE_NUMBER>135811010718e2e9f59506, which is the same as the UUID reported by npx meross info -> MQTT topics contains the deviceid
I received this message to /appliance/2308012511135811010718e2e9f59506/publish before it disconnected and reset itself (uuid have been substituted with the sample one as I do not know if they are sensitive)
{"header":{"messageId":"b7458e74746003e300dde9c18beb1d09","namespace":"Appliance.Control.Bind","triggerSrc":"DevBoot","method":"SET","payloadVersion":1,"from":"/appliance/2308012511135811010718e2e9f59506/subscribe","uuid":"2308082555235851080748e1e9d59306","timestamp":1702379017,"timestampMs":440,"sign":"d7d3b4f87a745eda63467a2fb4c2e322"},"payload":{"bind":{"bindTime":1702379017,"time":{"timestamp":1702379017,"timezone":"Europe/Rome","timeRule":[[1698541200,3600,0],[1711846800,7200,1],[1729990800,3600,0],[1743296400,7200,1],[1761440400,3600,0],[1774746000,7200,1],[1792890000,3600,0],[1806195600,7200,1],[1824944400,3600,0],[1837645200,7200,1],[1856394000,3600,0],[1869094800,7200,1],[1887843600,3600,0],[1901149200,7200,1],[1919293200,3600,0],[1932598800,7200,1],[1950742800,3600,0],[1964048400,7200,1],[1982797200,3600,0],[1995498000,7200,1]]},"hardware":{"type":"mss315","subType":"eu","version":"9.0.0","chipType":"rtl8720cm","uuid":"2308012511135811010718e2e9f59506","macAddress":"censored"},"firmware":{"version":"9.5.33","compileTime":"2023/09/04-10:16:24","encrypt":1,"wifiMac":"censored","innerIp":"192.168.X.Y","server":"agent.censored.com","port":8883,"userId":0},"matter":{"uniqueId":"1943CEC535C22B50","matterVendorId":4933,"matterProductId":40962,"matterDiscriminator":2310,"macNetworkInterface":"WIFI"}}}}

I have enabled debug logs for emqx, maybe this can help @krahabb
2023-12-12T11:30:01.198270+00:00 [debug] msg: raw_bin_received, mfa: emqx_connection:when_bytes_in/3(778), peername: 192.168.X.Y:58345, bin: longhexstuff-censored, size: 127, type: hex
2023-12-12T11:30:01.198493+00:00 [debug] msg: mqtt_packet_received, mfa: emqx_channel:handle_in/2(331), peername: 192.168.X.Y:58345, clientid: fmware:UUID_wDQF6pNfE5Vlf5HY, packet: CONNECT(Q0, R0, D0, ClientId=fmware:UUID_wDQF6pNfE5Vlf5HY, ProtoName=MQIsdp, ProtoVsn=3, CleanStart=true, KeepAlive=120, Username=MAC:AD:DR:EE:SS, Password=******), tag: MQTT
2023-12-12T11:30:01.198799+00:00 [debug] msg: insert_channel_info, mfa: emqx_cm:insert_channel_info/3(159), peername: 192.168.X.Y:58345, clientid: fmware:UUID_wDQF6pNfE5Vlf5HY
2023-12-12T11:30:01.198860+00:00 [debug] msg: mqtt_packet_sent, mfa: emqx_connection:serialize_and_inc_stats_fun/1(877), peername: 192.168.X.Y:58345, clientid: fmware:UUID_wDQF6pNfE5Vlf5HY, packet: CONNACK(Q0, R0, D0, AckFlags=0, ReasonCode=0), tag: MQTT
2023-12-12T11:30:01.245250+00:00 [debug] msg: raw_bin_received, mfa: emqx_connection:when_bytes_in/3(778), peername: 192.168.X.Y:58345, clientid: fmware:UUID_wDQF6pNfE5Vlf5HY, bin: mediumlonghexstuff-censored, size: 60, type: hex
2023-12-12T11:30:01.245419+00:00 [debug] msg: mqtt_packet_received, mfa: emqx_connection:handle_msg/2(575), peername: 192.168.X.Y:58345, clientid: fmware:UUID_wDQF6pNfE5Vlf5HY, packet: SUBSCRIBE(Q1, R0, D0, PacketId=2 TopicFilters=[/appliance/UUID/subscribe(#{nl => 0,qos => 1, rap => 0,rh => 0})]), tag: MQTT
2023-12-12T11:30:01.245538+00:00 [debug] msg: authorization_module_nomatch, mfa: emqx_authz:do_authorize/4(527), peername: 192.168.X.Y:58345, clientid: fmware:UUID_wDQF6pNfE5Vlf5HY, topic: /appliance/UUID/subscribe, ipaddr: {192,168,2,78}, module: emqx_authz_client_info, pub_sub: #{action_type => subscribe,qos => 1}, tag: AUTHZ, username: <<"MAC:AD:DR:EE:SS">>
2023-12-12T11:30:01.245625+00:00 [info] msg: authorization_permission_allowed, mfa: emqx_authz:log_allowed/1(507), peername: 192.168.X.Y:58345, clientid: fmware:UUID_wDQF6pNfE5Vlf5HY, topic: /appliance/UUID/subscribe, ipaddr: {192,168,2,78}, source: file, username: <<"MAC:AD:DR:EE:SS">>
2023-12-12T11:30:01.245717+00:00 [debug] msg: subscribe, mfa: emqx_trace:subscribe/3(79), peername: 192.168.X.Y:58345, clientid: fmware:UUID_wDQF6pNfE5Vlf5HY, topic: /appliance/UUID/subscribe, sub_id: <<"fmware:UUID_wDQF6pNfE5Vlf5HY">>, sub_opts: #{nl => 0,qos => 1,rap => 0,rh => 0,sub_props => #{}}, tag: SUBSCRIBE
2023-12-12T11:30:01.245926+00:00 [debug] msg: mqtt_packet_sent, mfa: emqx_connection:serialize_and_inc_stats_fun/1(877), peername: 192.168.X.Y:58345, clientid: fmware:UUID_wDQF6pNfE5Vlf5HY, packet: SUBACK(Q0, R0, D0, PacketId=2, ReasonCodes=[1]), tag: MQTT
2023-12-12T11:30:01.246198+00:00 [debug] msg: insert_channel_info, mfa: emqx_cm:insert_channel_info/3(159), peername: 192.168.X.Y:58345, clientid: fmware:UUID_wDQF6pNfE5Vlf5HY
2023-12-12T11:30:04.553785+00:00 [debug] msg: emqx_connection_terminated, mfa: emqx_connection:terminate/2(668), peername: 192.168.X.Y:58345, clientid: fmware:UUID_wDQF6pNfE5Vlf5HY, reason: {shutdown,ssl_closed}, tag: SOCKET
2023-12-12T11:30:04.554005+00:00 [info] msg: terminate, mfa: emqx_connection:terminate/2(673), peername: 192.168.X.Y:58345, clientid: fmware:UUID_wDQF6pNfE5Vlf5HY, reason: {shutdown,ssl_closed}
2023-12-12T11:30:04.554243+00:00 [debug] msg: emqx_cm_clean_down, mfa: emqx_cm:clean_down/1(689), client_id: <<"fmware:UUID_wDQF6pNfE5Vlf5HY">>

I've also tried to enable all TLS versions, but that did not change anything

Ok, it looks like the strange 'topic' in previous logs is just the one which the device subscribes and that's ok and expected
I think I might have a possible resolution since it looks like the "Appliance.Control.Bind" the device sends needs to be replied with a correct response. There where some reports in the past where privately mqtt binded devices where 'pushing' these messages until they had received a proper response but, nevertheless, devices were still able to work without disconnecting and resetting if any response were not received(they just kept spamming a bit the broker).
It might be newer firmwares are stricter on this transaction and they want a response in order to be sure the broker is correct.
Now the problem lies in the fact that meross_lan actually replies to this message (the reply is very dumb to be honest but it might work..we'll see) but only once the device is configured in meross_lan so, if we're in the initial phase of pairing like this, meross_lan doesn't handle this message for sure.
I could easily fix and deliver a patch and see if that works but I'm in the middle of nowhere with development so I need a bit of time to setup a dedicated branch. Keep in touch, I'll try to publish it asap since that could solve a lot of issues for the future too

Thank you for all the help! If you have the reply that I should send via MQTT I can try to bypass meross_lan and send it manually just to check if stays paired or there's more work needed on that end.
Of course I'm open to test everything as soon as it's ready ^^

the latest pre-release has a patch trying to fix this. Let me know if it's enough..else it will be hard!
With meross_lan installed in HA and the HA MQTT broker working, now the device should receive a reply when it attempts to publish the Appliance.Control.Bind message

@krahabb I have tried for 5 hours but I could not even manage for the payload to arrive anymore. I tried with legit certs and self-signed ones. I'm not expert enough to debug this even more since I have no ideas left :(

I'll try again tonight without using a key, as yesterday I seemingly had some success by not specifying one (that didn't work before and the pairing tool said that it failed to connect)
The "real world CA" SSL cert having some key issue is something I suspected as well. I have my own local CA that I can use, so I'll try again with that too (I did but had no luck yesterday)
Thank you for your help in the meantime!

I'm pretty sure the broker is expected to respond with SETACK with the same MessageId to Appliance.Control.Bind, though I cannot recall what the payload should be. Pairing to the official servers with a tool like https://github.com/bytespider/mqtt-debug may help see what that message maybe. https://github.com/krahabb/meross_lan/discussions/126
Whenever I had SSL issues, it was before any message was ever sent, so I feel like the issues with SSL are leading you astray.
Here are my settings for TLS in EMQX, which are working with my MSS310s (hardware v2)

I have good and bad news:
Good news: I have managed to get it connected to my self signed CA (so key generated by opnsense was fine) and publish stuff.
Bad news: it still disconnected
The pair process I used:

force reset via hand
opened the meross app
started the pair process
the matter ux opens and I scan the code
the pairing works but the device is not added to my account in cloud (even though by using npx meross info I see it connected to mqtt-eu-2.meross.com:443 and I had to use the key retrieved from my meross account tho to use npx meross info)
I used npx meross setup with the key
The below logs happened

I have empirically verified this work repeatedly, so now it's more of a matter of sending the right data to it? @bytespider @aicarmic
2023-12-15T21:42:38.037996+01:00 [debug] msg: raw_bin_received, mfa: emqx_connection:when_bytes_in/3(778), peername: <IP_ADDRESS>:52689, bin: 107D00064D514973647003C200780038666D776172653A32333038303835373132393230393531303830373438653165396435383434325F6D74507147776172627466757035426D001134383A65313A65393A64353A38343A34320022305F6265663034613338646366313063393866396430353134393532383430383931, size: 127, type: hex
2023-12-15T21:42:38.041230+01:00 [debug] msg: mqtt_packet_received, mfa: emqx_channel:handle_in/2(331), peername: <IP_ADDRESS>:52689, clientid: fmware:2308085712920951080748e1e9d58442_mtPqGwarbtfup5Bm, packet: CONNECT(Q0, R0, D0, ClientId=fmware:2308085712920951080748e1e9d58442_mtPqGwarbtfup5Bm, ProtoName=MQIsdp, ProtoVsn=3, CleanStart=true, KeepAlive=120, Username=MACADDRESS, Password=******), tag: MQTT
2023-12-15T21:42:38.042780+01:00 [debug] msg: authentication_result, mfa: emqx_authn_chains:authenticate/2(163), peername: <IP_ADDRESS>:52689, clientid: fmware:2308085712920951080748e1e9d58442_mtPqGwarbtfup5Bm, reason: empty_chain, result: ignore, tag: AUTHN
2023-12-15T21:42:38.044713+01:00 [debug] msg: insert_channel_info, mfa: emqx_cm:insert_channel_info/3(159), peername: <IP_ADDRESS>:52689, clientid: fmware:2308085712920951080748e1e9d58442_mtPqGwarbtfup5Bm
2023-12-15T21:42:38.045462+01:00 [debug] msg: mqtt_packet_sent, mfa: emqx_connection:serialize_and_inc_stats_fun/1(877), peername: <IP_ADDRESS>:52689, clientid: fmware:2308085712920951080748e1e9d58442_mtPqGwarbtfup5Bm, packet: CONNACK(Q0, R0, D0, AckFlags=0, ReasonCode=0), tag: MQTT
2023-12-15T21:42:38.080363+01:00 [debug] msg: raw_bin_received, mfa: emqx_connection:when_bytes_in/3(778), peername: <IP_ADDRESS>:52689, clientid: fmware:2308085712920951080748e1e9d58442_mtPqGwarbtfup5Bm, bin: 823A000200352F6170706C69616E63652F32333038303835373132393230393531303830373438653165396435383434322F73756273637269626501, size: 60, type: hex
2023-12-15T21:42:38.081964+01:00 [debug] msg: mqtt_packet_received, mfa: emqx_connection:handle_msg/2(575), peername: <IP_ADDRESS>:52689, clientid: fmware:2308085712920951080748e1e9d58442_mtPqGwarbtfup5Bm, packet: SUBSCRIBE(Q1, R0, D0, PacketId=2 TopicFilters=[/appliance/2308085712920951080748e1e9d58442/subscribe(#{nl => 0,qos => 1, rap => 0,rh => 0})]), tag: MQTT
2023-12-15T21:42:38.084607+01:00 [debug] msg: authorization_module_nomatch, mfa: emqx_authz:do_authorize/4(527), peername: <IP_ADDRESS>:52689, clientid: fmware:2308085712920951080748e1e9d58442_mtPqGwarbtfup5Bm, topic: /appliance/2308085712920951080748e1e9d58442/subscribe, ipaddr: {192,168,2,78}, module: emqx_authz_client_info, pub_sub: #{action_type => subscribe,qos => 1}, tag: AUTHZ, username: <<"MACADDRESS">>
2023-12-15T21:42:38.086452+01:00 [info] msg: authorization_failed_nomatch, mfa: emqx_authz:authorize_non_superuser/5(501), peername: <IP_ADDRESS>:52689, clientid: fmware:2308085712920951080748e1e9d58442_mtPqGwarbtfup5Bm, topic: /appliance/2308085712920951080748e1e9d58442/subscribe, ipaddr: {192,168,2,78}, reason: no-match rule, username: <<"MACADDRESS">>
2023-12-15T21:42:38.087810+01:00 [debug] msg: subscribe, mfa: emqx_trace:subscribe/3(79), peername: <IP_ADDRESS>:52689, clientid: fmware:2308085712920951080748e1e9d58442_mtPqGwarbtfup5Bm, topic: /appliance/2308085712920951080748e1e9d58442/subscribe, sub_id: <<"fmware:2308085712920951080748e1e9d58442_mtPqGwarbtfup5Bm">>, sub_opts: #{nl => 0,qos => 1,rap => 0,rh => 0,sub_props => #{}}, tag: SUBSCRIBE
2023-12-15T21:42:38.092153+01:00 [debug] msg: mqtt_packet_sent, mfa: emqx_connection:serialize_and_inc_stats_fun/1(877), peername: <IP_ADDRESS>:52689, clientid: fmware:2308085712920951080748e1e9d58442_mtPqGwarbtfup5Bm, packet: SUBACK(Q0, R0, D0, PacketId=2, ReasonCodes=[1]), tag: MQTT
2023-12-15T21:42:38.093766+01:00 [debug] msg: insert_channel_info, mfa: emqx_cm:insert_channel_info/3(159), peername: <IP_ADDRESS>:52689, clientid: fmware:2308085712920951080748e1e9d58442_mtPqGwarbtfup5Bm
2023-12-15T21:42:38.319633+01:00 [debug] msg: raw_bin_received, mfa: emqx_connection:when_bytes_in/3(778), peername: <IP_ADDRESS>:52689, clientid: fmware:2308085712920951080748e1e9d58442_mtPqGwarbtfup5Bm, bin: 32F60A00332F6170706C69616E63652F32333038303835373132393230393531303830373438653165396435383434322F7075626C69736800037B22686561646572223A7B226D6573736167654964223A223465653834613137343933373763393432366337666262393464366139333330222C226E616D657370616365223A224170706C69616E63652E436F6E74726F6C2E42696E64222C2274726967676572537263223A22446576426F6F74222C226D6574686F64223A22534554222C227061796C6F616456657273696F6E223A312C2266726F6D223A222F6170706C69616E63652F32333038303835373132393230393531303830373438653165396435383434322F737562736372696265222C2275756964223A223233303830383537313239323039353130383037343865316539643538343432222C2274696D657374616D70223A313730323637323935372C2274696D657374616D704D73223A33312C227369676E223A226163373066353966633766376339636364353939653530623331633735633430227D2C227061796C6F6164223A7B2262696E64223A7B2262696E6454696D65223A313730323637323935372C2274696D65223A7B2274696D657374616D70223A313730323637323935372C2274696D657A6F6E65223A224575726F70652F526F6D65222C2274696D6552756C65223A5B5B313639383534313230302C333630302C305D2C5B313731313834363830302C373230302C315D2C5B313732393939303830302C333630302C305D2C5B313734333239363430302C373230302C315D2C5B313736313434303430302C333630302C305D2C5B313737343734363030302C373230302C315D2C5B313739323839303030302C333630302C305D2C5B313830363139353630302C373230302C315D2C5B313832343934343430302C333630302C305D2C5B313833373634353230302C373230302C315D2C5B313835363339343030302C333630302C305D2C5B313836393039343830302C373230302C315D2C5B313838373834333630302C333630302C305D2C5B313930313134393230302C373230302C315D2C5B313931393239333230302C333630302C305D2C5B313933323539383830302C373230302C315D2C5B313935303734323830302C333630302C305D2C5B313936343034383430302C373230302C315D2C5B313938323739373230302C333630302C305D2C5B313939353439383030302C373230302C315D5D7D2C226861726477617265223A7B2274797065223A226D7373333135222C2273756254797065223A226575222C2276657273696F6E223A22392E302E30222C226368697054797065223A2272746C38373230636D222C2275756964223A223233303830383537313239323039353130383037343865316539643538343432222C226D616341646472657373223A2234383A65313A65393A64353A38343A3432227D2C226669726D77617265223A7B2276657273696F6E223A22392E352E3333222C22636F6D70696C6554696D65223A22323032332F30392F30342D31303A31363A3234222C22656E6372797074223A312C22776966694D6163223A2264323A32313A66393A31323A63363A3039222C22696E6E65724970223A223139322E3136382E322E3738222C22736572766572223A22686173732E6C6F63616C2E66756F2E6669222C22706F7274223A383838332C22757365724964223A307D2C226D6174746572223A7B22756E697175654964223A2242324631454237333838303333433738222C226D617474657256656E646F724964223A343933332C226D617474657250726F647563744964223A34303936322C226D61747465724469736372696D696E61746F72223A323630352C226D61634E6574776F726B496E74657266616365223A2257494649227D7D7D7D, size: 1401, type: hex
2023-12-15T21:42:38.322531+01:00 [debug] msg: mqtt_packet_received, mfa: emqx_connection:handle_msg/2(575), peername: <IP_ADDRESS>:52689, clientid: fmware:2308085712920951080748e1e9d58442_mtPqGwarbtfup5Bm, packet: PUBLISH(Q1, R0, D0, Topic=/appliance/2308085712920951080748e1e9d58442/publish, PacketId=3, Payload={"header":{"messageId":"4ee84a1749377c9426c7fbb94d6a9330","namespace":"Appliance.Control.Bind","trig... The 1243 bytes of this log are truncated), tag: MQTT
2023-12-15T21:42:38.324474+01:00 [debug] msg: authorization_module_nomatch, mfa: emqx_authz:do_authorize/4(527), peername: <IP_ADDRESS>:52689, clientid: fmware:2308085712920951080748e1e9d58442_mtPqGwarbtfup5Bm, topic: /appliance/2308085712920951080748e1e9d58442/publish, ipaddr: {192,168,2,78}, module: emqx_authz_client_info, pub_sub: #{action_type => publish,qos => 1,retain => false}, tag: AUTHZ, username: <<"MACADDRESS">>
2023-12-15T21:42:38.326338+01:00 [info] msg: authorization_failed_nomatch, mfa: emqx_authz:authorize_non_superuser/5(501), peername: <IP_ADDRESS>:52689, clientid: fmware:2308085712920951080748e1e9d58442_mtPqGwarbtfup5Bm, topic: /appliance/2308085712920951080748e1e9d58442/publish, ipaddr: {192,168,2,78}, reason: no-match rule, username: <<"MACADDRESS">>
2023-12-15T21:42:38.327725+01:00 [debug] msg: publish_to, mfa: emqx_trace:publish/1(74), peername: <IP_ADDRESS>:52689, clientid: fmware:2308085712920951080748e1e9d58442_mtPqGwarbtfup5Bm, topic: /appliance/2308085712920951080748e1e9d58442/publish, payload: {"header":{"messageId":"4ee84a1749377c9426c7fbb94d6a9330","namespace":"Appliance.Control.Bind","trig... The 1243 bytes of this log are truncated, tag: PUBLISH
2023-12-15T21:42:38.329697+01:00 [debug] msg: mqtt_packet_sent, mfa: emqx_connection:serialize_and_inc_stats_fun/1(877), peername: <IP_ADDRESS>:52689, clientid: fmware:2308085712920951080748e1e9d58442_mtPqGwarbtfup5Bm, packet: PUBACK(Q0, R0, D0, PacketId=3, ReasonCode=0), tag: MQTT
2023-12-15T21:42:38.329898+01:00 [debug] msg: mqtt_packet_sent, mfa: emqx_connection:serialize_and_inc_stats_fun/1(877), peername: <IP_ADDRESS>:35271, clientid: 1ENUSOneKubkEH2JLAukYy, packet: PUBLISH(Q0, R0, D0, Topic=/appliance/2308085712920951080748e1e9d58442/publish, PacketId=undefined, Payload={"header":{"messageId":"4ee84a1749377c9426c7fbb94d6a9330","namespace":"Appliance.Control.Bind","trig...  It's more difficult to replicate the guide @bytespider linked since matter pairing is different than usual)
1 +++
1 --> CONNECT clientId: fmware:2308085712920951080748e1e9d58442_5GD7D7x2c9W5L5eU username: macaddress password: thetas
1 <-- CONACK
1 ---

@fuomag9,
In the 'almost working' example, the device finally sends a couple of packets (also receives a reply from its 'Bind' push this indicates meross_lan latest release fix is working)
At one point it also sends a 'ConsumptionConfig' packet and then (soon after about 1 sec) disconnects and I've found documentation here where @arandall states this is usually replied by the meross broker with the same packet/payload.
Actually, meross_lan doesn't handle this packet so this could be another 'missing transaction' in the init process. As previously said, it could be latest firmwares are becoming stricter and stricter.
I'll (try) quckly publish a further fix to reply to this message and see if it finally fixes the whole process
I really hope we can solve this issue seeing your efforts! keep up!

There's a new pre-release which now also replies to the 'ConsumptionConfig' payload sent by the device.
Cross fingers ;)

There's a new pre-release which now also replies to the 'ConsumptionConfig' payload sent by the device. Cross fingers ;)

Things got a bit better, meross lan magically saw the device as soon as I pushed the npx meross setup --mqtt mqtts://hass.local.fuo.fi:8883 --wifi-ssid 'wifi' --wifi-pass 'pass' -g <IP_ADDRESS> -k myextractedkey command.
I could control it briefly (I don't know if it was using mqtt or http, since trying to force mqtt from the configure button did not seem to work) but then it disconnected again.  The 1299 bytes of this log are truncated)
2023-12-16T22:55:43.743695+01:00 [PUBLISH] fmware:2308085712920951080748e1e9d58442_dm1u3toPGXwyoY6K@<IP_ADDRESS>:58562 msg: publish_to, topic: /appliance/2308085712920951080748e1e9d58442/publish, payload: {"header":{"messageId":"9d3a4adc67fa496fb70d1d6d3134e774","namespace":"Appliance.System.Ability","me... The 1299 bytes of this log are truncated
2023-12-16T22:55:43.745323+01:00 [MQTT] fmware:2308085712920951080748e1e9d58442_dm1u3toPGXwyoY6K@<IP_ADDRESS>:58562 msg: mqtt_packet_sent, packet: PUBACK(Q0, R0, D0, PacketId=5, ReasonCode=0)
2023-12-16T22:55:46.142618+01:00 [SOCKET] fmware:2308085712920951080748e1e9d58442_dm1u3toPGXwyoY6K@<IP_ADDRESS>:58562 msg: emqx_connection_terminated, reason: {shutdown,ssl_closed}
2023-12-16T22:55:46.144503+01:00 [info] msg: terminate, mfa: emqx_connection:terminate/2(673), peername: <IP_ADDRESS>:58562, clientid: fmware:2308085712920951080748e1e9d58442_dm1u3toPGXwyoY6K, reason: {shutdown,ssl_closed}

:(
It looks everything is working as it should...the device replies to the discovery queries with the correct (expected) payloads..just it keep disconnecting about 4/5 seconds after connection.
This trace doesn't even include the 'ConsumptionConfig' packet (the device doesn't send it..maybe because it is busy replying to the discovery queries from meross_lan) so I guess it is not related to the issue
We're in a sort of dead-end right now, unless we could use the mqtt proxy and sniff an 'actual' binding-connection session to the legit Meross brokers and see what's happening there.
I've read back to see if someone else is using the mss315 and it looks there are some using them paired with the Meross cloud (and they show some issues anyway since they're able to only work with Matter or with meross_lan but not at the same time
Could it be these plugs cannot support both protocols at the same time so they (internally) disable one of them ?

Could it be these plugs cannot support both protocols at the same time so they (internally) disable one of them ?

I don't think this is the case, as stats are an advertised feature and pairing is done with matter, so they have to have both of them working at the same time for sure
I'll try to get the proxy to work tonight and report back

@krahabb I made the proxy work!
I've noticed something interesting, it changes its password after the first connection to the meross servers! Pairing was 100% done via the meross app. How I made the proxy work was via forcing a mitm rule on my router so it tought the meross server was the proxy :D
The rule:

The logs:
3 +++
3 --> CONNECT clientId: fmware:2308085712920951080748e1e9d58442_AXDtG3BYabrLUBe0 username: macAddress-censored password: 3137109_bf116898d25e09d3cd366e859c8be1f0
3 <-- CONACK
3 --> msg: 2 SUBSCRIBE /appliance/2308085712920951080748e1e9d58442/subscribe QoS:1
3 <-- msg: 2 SUBACK
3 --> msg: 3 PUBLISH /appliance/2308085712920951080748e1e9d58442/publish {
  header: {
    messageId: '0a387787f3e89aef7417c948b12aca10',
    namespace: 'Appliance.Control.Bind',
    triggerSrc: 'DevBoot',
    method: 'SET',
    payloadVersion: 1,
    from: '/appliance/2308085712920951080748e1e9d58442/subscribe',
    uuid: '2308085712920951080748e1e9d58442',
    timestamp:<PHONE_NUMBER>,
    timestampMs: 862,
    sign: '9d357a14573cc0aca90ffab6f42f9c08'
  },
  payload: {
    bind: {
      bindTime:<PHONE_NUMBER>,
      time: { timestamp:<PHONE_NUMBER>, timezone: '', timeRule: [] },
      hardware: {
        type: 'mss315',
        subType: 'eu',
        version: '9.0.0',
        chipType: 'rtl8720cm',
        uuid: '2308085712920951080748e1e9d58442',
        macAddress: 'macAddress-censored'
      },
      firmware: {
        version: '9.5.33',
        compileTime: '2023/09/04-10:16:24',
        encrypt: 1,
        wifiMac: 'wifi-macAddress-censored',
        innerIp: '<IP_ADDRESS>',
        server: 'mqtt.meross.com',
        port: 443,
        userId: 3137109
      },
      matter: {
        uniqueId: 'A87537B2D5654D9F',
        matterVendorId: 4933,
        matterProductId: 40962,
        matterDiscriminator: 2605,
        macNetworkInterface: 'WIFI'
      }
    }
  }
}
3 <-- msg: 3 PUBACK
3 <-- msg: - PUBLISH /appliance/2308085712920951080748e1e9d58442/subscribe {
  header: {
    messageId: '0a387787f3e89aef7417c948b12aca10',
    namespace: 'Appliance.Control.Bind',
    timestamp:<PHONE_NUMBER>,
    triggerSrc: 'CloudControl',
    payloadVersion: 1,
    method: 'SETACK',
    sign: 'fb53bed340f7e5c85ab57d7c1d7623b2',
    from: 'cloud/sub/kIGFRwvtAQP4sbXv/58c35d719350a689'
  },
  payload: {}
}
3 --> msg: 4 PUBLISH /appliance/2308085712920951080748e1e9d58442/publish {
  header: {
    messageId: '38742c0161d1bd5ef4e817b73f568866',
    namespace: 'Appliance.System.Report',
    method: 'PUSH',
    payloadVersion: 1,
    from: '/appliance/2308085712920951080748e1e9d58442/publish',
    uuid: '2308085712920951080748e1e9d58442',
    timestamp:<PHONE_NUMBER>,
    timestampMs: 634,
    sign: 'bdaeaf52606b6d30d1a28f47ff02b631'
  },
  payload: { report: [ { type: '1', value: '1', timestamp:<PHONE_NUMBER> } ] }
}
3 <-- msg: 4 PUBACK
3 --> msg: 5 PUBLISH /appliance/2308085712920951080748e1e9d58442/publish {
  header: {
    messageId: 'f958729d266e9d0a5ed743052cd39d9e',
    namespace: 'Appliance.Control.ConsumptionConfig',
    method: 'PUSH',
    payloadVersion: 1,
    from: '/appliance/2308085712920951080748e1e9d58442/publish',
    uuid: '2308085712920951080748e1e9d58442',
    timestamp:<PHONE_NUMBER>,
    timestampMs: 774,
    sign: 'd1dcb030b5bc4ee443d9e1e2ca5fd1bb'
  },
  payload: {
    config: {
      voltageRatio: 188,
      electricityRatio: 102,
      maxElectricityCurrent: 11000,
      powerRatio: 0
    }
  }
}
3 <-- msg: 5 PUBACK
3 <-- msg: - PUBLISH /appliance/2308085712920951080748e1e9d58442/subscribe {
  header: {
    messageId: 'f958729d266e9d0a5ed743052cd39d9e',
    namespace: 'Appliance.Control.ConsumptionConfig',
    timestamp:<PHONE_NUMBER>,
    timestampMs: 774,
    triggerSrc: 'CloudControl',
    payloadVersion: 1,
    method: 'PUSH',
    sign: 'd1dcb030b5bc4ee443d9e1e2ca5fd1bb',
    from: '/appliance/2308085712920951080748e1e9d58442/publish'
  },
  payload: {
    config: {
      electricityRatio: 96,
      maxElectricityCurrent: 17000,
      voltageRatio: 188
    }
  }
}
3 --> msg: 6 PUBLISH /appliance/2308085712920951080748e1e9d58442/publish {
  header: {
    messageId: 'd9200ee47f1b23bdd43c9670aa97bee5',
    namespace: 'Appliance.System.Time',
    method: 'PUSH',
    payloadVersion: 1,
    from: '/appliance/2308085712920951080748e1e9d58442/publish',
    uuid: '2308085712920951080748e1e9d58442',
    timestamp:<PHONE_NUMBER>,
    timestampMs: 803,
    sign: '63d341b0e14f7fa57adbba03d4c81d35'
  },
  payload: {
    time: {
      timestamp:<PHONE_NUMBER>,
      timezone: 'Europe/Rome',
      timeRule: [
        [<PHONE_NUMBER>, 3600, 0 ],
        [<PHONE_NUMBER>, 7200, 1 ],
        [<PHONE_NUMBER>, 3600, 0 ],
        [<PHONE_NUMBER>, 7200, 1 ],
        [<PHONE_NUMBER>, 3600, 0 ],
        [<PHONE_NUMBER>, 7200, 1 ],
        [<PHONE_NUMBER>, 3600, 0 ],
        [<PHONE_NUMBER>, 7200, 1 ],
        [<PHONE_NUMBER>, 3600, 0 ],
        [<PHONE_NUMBER>, 7200, 1 ],
        [<PHONE_NUMBER>, 3600, 0 ],
        [<PHONE_NUMBER>, 7200, 1 ],
        [<PHONE_NUMBER>, 3600, 0 ],
        [<PHONE_NUMBER>, 7200, 1 ],
        [<PHONE_NUMBER>, 3600, 0 ],
        [<PHONE_NUMBER>, 7200, 1 ],
        [<PHONE_NUMBER>, 3600, 0 ],
        [<PHONE_NUMBER>, 7200, 1 ],
        [<PHONE_NUMBER>, 3600, 0 ],
        [<PHONE_NUMBER>, 7200, 1 ]
      ]
    }
  }
}
3 <-- msg: 6 PUBACK
3 --> Packet {
  cmd: 'disconnect',
  retain: false,
  qos: 0,
  dup: false,
  length: 0,
  topic: null,
  payload: null
}
3 ---
4 +++
4 --> CONNECT clientId: fmware:2308085712920951080748e1e9d58442_v4wIIPnGNdMguiVa username: macAddress-censored password: DIFFERENT CENSORED PASSWORD!
4 <-- CONACK
4 --> msg: 2 SUBSCRIBE /appliance/2308085712920951080748e1e9d58442/subscribe QoS:1
4 <-- msg: 2 SUBACK
4 --> msg: 3 PUBLISH /appliance/2308085712920951080748e1e9d58442/publish {
  header: {
    messageId: 'c8ecc17370dca6b4397b3ea07be511c5',
    namespace: 'Appliance.Control.Bind',
    triggerSrc: 'DevBoot',
    method: 'SET',
    payloadVersion: 1,
    from: '/appliance/2308085712920951080748e1e9d58442/subscribe',
    uuid: '2308085712920951080748e1e9d58442',
    timestamp:<PHONE_NUMBER>,
    timestampMs: 474,
    sign: 'f22dfb46e7f40ea51264c67de83b5599'
  },
  payload: {
    bind: {
      bindTime:<PHONE_NUMBER>,
      time: {
        timestamp:<PHONE_NUMBER>,
        timezone: 'Europe/Rome',
        timeRule: [
          [<PHONE_NUMBER>, 3600, 0 ],
          [<PHONE_NUMBER>, 7200, 1 ],
          [<PHONE_NUMBER>, 3600, 0 ],
          [<PHONE_NUMBER>, 7200, 1 ],
          [<PHONE_NUMBER>, 3600, 0 ],
          [<PHONE_NUMBER>, 7200, 1 ],
          [<PHONE_NUMBER>, 3600, 0 ],
          [<PHONE_NUMBER>, 7200, 1 ],
          [<PHONE_NUMBER>, 3600, 0 ],
          [<PHONE_NUMBER>, 7200, 1 ],
          [<PHONE_NUMBER>, 3600, 0 ],
          [<PHONE_NUMBER>, 7200, 1 ],
          [<PHONE_NUMBER>, 3600, 0 ],
          [<PHONE_NUMBER>, 7200, 1 ],
          [<PHONE_NUMBER>, 3600, 0 ],
          [<PHONE_NUMBER>, 7200, 1 ],
          [<PHONE_NUMBER>, 3600, 0 ],
          [<PHONE_NUMBER>, 7200, 1 ],
          [<PHONE_NUMBER>, 3600, 0 ],
          [<PHONE_NUMBER>, 7200, 1 ]
        ]
      },
      hardware: {
        type: 'mss315',
        subType: 'eu',
        version: '9.0.0',
        chipType: 'rtl8720cm',
        uuid: '2308085712920951080748e1e9d58442',
        macAddress: 'macAddress-censored'
      },
      firmware: {
        version: '9.5.33',
        compileTime: '2023/09/04-10:16:24',
        encrypt: 1,
        wifiMac: 'wifi-macAddress-censored',
        innerIp: '<IP_ADDRESS>',
        server: 'mqtt-eu-2.meross.com',
        port: 443,
        userId: 3393429
      },
      matter: {
        uniqueId: 'A87537B2D5654D9F',
        matterVendorId: 4933,
        matterProductId: 40962,
        matterDiscriminator: 2605,
        macNetworkInterface: 'WIFI'
      }
    }
  }
}
4 <-- msg: 3 PUBACK
4 <-- msg: - PUBLISH /appliance/2308085712920951080748e1e9d58442/subscribe {
  header: {
    messageId: 'c8ecc17370dca6b4397b3ea07be511c5',
    namespace: 'Appliance.Control.Bind',
    timestamp:<PHONE_NUMBER>,
    triggerSrc: 'CloudControl',
    payloadVersion: 1,
    method: 'SETACK',
    sign: 'f8f0c47976d02d3e46f2a7892b9b825d',
    from: 'cloud/sub/fqskH99hHdHVyn6G/fc016b79c7290167'
  },
  payload: {}
}
4 --> msg: 4 PUBLISH /appliance/2308085712920951080748e1e9d58442/publish {
  header: {
    messageId: 'c5e648496e396596f32be4024ef10b9f',
    namespace: 'Appliance.Control.ConsumptionX',
    method: 'PUSH',
    payloadVersion: 1,
    from: '/appliance/2308085712920951080748e1e9d58442/publish',
    uuid: '2308085712920951080748e1e9d58442',
    timestamp:<PHONE_NUMBER>,
    timestampMs: 122,
    sign: '039c73e3453d9d21de04f1f3a78f29c5'
  },
  payload: { consumptionx: [] }
}
4 <-- msg: 4 PUBACK

I have managed to keep it connected to my mqtt server by not changing the domain and forcing the connection to my broker directly via mitm. I can see commands sent by the android app but I cannot add it to meross lan in this state

Wow..that's a lot!
It'll take some time to understand everything and try to figure out theat 'password change'
As a starter it looks as the first connection is very similar to the one on the private broker managed by meross_lan latest pre-release but I've seen some subtle differences that need to be addressed
In fact, the device doesn't disconnect immediately but waits and sends an 'Appliance.System.Time' payload almost 50 seconds after the last reply from the cloud broker (while sessions on the private broker always terminated soon after connection)
It appears as if the device (during this 50 seconds) queries something (I don't know what..or maybe the app was communicating locally with the device ?) and setup its daylight saving time offsets. After this time it sends these offsets to the cloud broker and then disconnects.
On the second attempt (when the password changed) the 'Bind' message already has the DST offsets in place.
So, either the app was locally communicating and setting up the timezone and DST or, somehow, the device recovered this info elsewhere and then pushed to the cloud broker
Password changed thoughts: the password is made up of the userid, the mac address and the device key so if it changes, some of these info should have changed. Or there's something new we really can't figure out
Tomorrow I will try to release another patch with better session management trying to better emulate what's seen in these traces which is very invaluable to me anyway. I'm not sure this will definitely solve the session establishment but...it will surely improve the compliance for local broker code

I have managed to keep it connected to my mqtt server by not changing the domain and forcing the connection to my broker directly via mitm instead. I can see commands sent by the android app but I cannot add it to meross lan in this state !

This is so exotic it is not supported: meross_lan could be able to talk to the device through the local broker but since the userid configured in the device is not '0' the code thinks the device is cloud paired (which is in fact:) and thinks it could only be accessed through the real cloud brokers so it doesnt route messages from the HA broker to the device and vice-versa
For sure you'd need to set the device key (meross_lan device entry config) to the same value as the one retrieved previously with the pairer app from the cloud account (or use the 'cloud retrieve' function in meross_lan). This way you should be able to at least talk via HTTP.
Then, to avoid meross_lan thinking the device is cloud paired you have to completely delete the (eventual) cloud profile you set-up in meross_lan (disabling it doesn't work). This way meross_lan will not find any match between the userid in the device and the cloud profile and so will revert to using the HA configured broker.

While inspecting the message exchange, the device (in the second transaction) has effectively changed its userid: that explains the mqtt password change

I'm pretty sure it's the meross lan app doing that! When doing the pairing via matter (which is the only way pairing can be done, as per the app instructions) after the device has been added to matter (it uses mqtt.meross.com:443) there's an in-app section where you have to press a button and "wait for competition" of the pairing.
I believe that is when it locally does stuff and changes it

For sure you'd need to set the device key (meross_lan device entry config) to the same value as the one retrieved previously with the pairer app from the cloud account (or use the 'cloud retrieve' function in meross_lan). This way you should be able to at least talk via HTTP.

That works (always did) but afaik there are some issues with the current statuses, the data is always 0

@krahabb OMG IT WORKS!!??

@fuomag9 ,
did it work after upgrading to latest Cloudy.5.beta.0 ? or dit it just start working somehow ?

Here is how I made it work:

use Cloudy.5.beta.0
get the device IP address
setup the device key obtained from the cloud in meross lan
setup a mitm rule like below to your mqtt server

open the meross app and start pairing via matter
when matter pairing is done, the meross app will ask for "finishing the pairing"
Configuration for the device will appear in meross lan
the meross pairing will not end and you can kill the app (but we don't care about that since the device will now work locally)

I've also added a rule to block out internet traffic for the device to confirm this just in case and the device continues working correctly (and forcing the protocol in the UI did not work before this anyway and I can see the MQTT requests in realtime)
I've also confirmed that the values for current can also be read and the smart plug reconnects even after removed from the wall plug
The npx meross setup tool has NOT worked in any way with any type of configuration for me, there's probably something that needs to be changed in the setup @bytespider

That's impressive!
I think this thread is showing a 'step-up' in the pairing procedure not seen before.
It puzzles me a bit the fact that this new 'matter pairing' procedure goes through 2 pairing phases: in your mitm-proxy attempts logs, where the device was going through this new standard pairing procedure, it clearly used 2 different user accounts (or 2 user ids associated with the same account)
thoughts
Going on, I think the root problem is in the inability to now setup the wifi from scratch (like it was before where the devices, once reset were setting up their own open ssid-AP). This leads to necessarily using the Meross app for pairing with all the consequences-issues.
I see anyway https://github.com/bytespider/Meross/issues/72#issuecomment-1859218764 seems to have found a workaround to the current @bytespider meross utility in order to only re-configure the broker once the device is Meross paired. This way, (it looks like working), after all of the official Meross pairing, the utility is able to just 'steal' the device from the cloud brokers and bind to the local one.
I don't know if you were following that issue/thread but, if you were just using the current meross setup utility, @M0NsTeRRR shows it is still not up to date with the scenario

I wasn't aware of bytespider/Meross#72! I'll try this evening to see what happens by only changing the MQTT endpoint and not the WiFi network, maybe we can remove the mitm rule 👀

Haven't time to full configure MQTT at home but after doing my step meross info show local broker so I assume it works :)

At this point, the @M0NsTeRRR trick shows we should be able (in meross_lan) to actually reconfigure the device broker at any time by just issuing the dedicated message/command.
This will open up to a nice feature where, having the device (Meross app paired) fully working in meross_lan eventually with its cloud profile but doesnt matter, we could reconfigure its broker to the HA mqtt by pressing a button in meross_lan.
Of course the HA mqtt need to fullfill all of the specific requirements needed for the device to succesfully bind but it will 'release' the need to use the @bytespider meross setup utility
The only drawback, I guess, would be that in case of failure binding the device could factory reset itself thus needing to be reconfigured from scratch in Meross app (or whatever)
I'll start experimenting: the covid is giving me plenty of time ;)

@M0NsTeRRR @krahabb
I have created a pull request for the meross tool with a fix for the MSS315, the mitm trick is not needed anymore! https://github.com/bytespider/Meross/pull/75
This is the current pairing guide for that device:

use the meross app (any matter app should work as well, but I've not tested it)
setup with matter
get the device IP address
when the matter setup has ended, do NOT continue the meross setup
use the meross tool (with my fork if the patch has not been integrated)
meross setup  --mqtt mqtts://yourmqtt:yourport -g deviceIP -k cloudkey --nowifi
the device will be found on meross lan
setup the timezone in meross lan otherwise the current data will not be shown (and ip address as I believe there's a bug that does not set it graphically rn?)

Has anyone gotten this to work with Mosquitto in home assistant? I've read through several issues here and I can't connect to mosquitto after setting it up. Mosquitto is throwing a TLS error about "no shared ciphers" when the plug tries to connect. Based on info I've read here I'm assuming it's a TLS version issue, but I haven't figured out how to change the version mosquitto expects. My plug is MSS315 hardware 9.0, firmware 9.5.29 and it has never been connected to the Meross app (I don't want to create accounts).

Has anyone gotten this to work with Mosquitto in home assistant? I've read through several issues here and I can't connect to mosquitto after setting it up. Mosquitto is throwing a TLS error about "no shared ciphers" when the plug tries to connect. Based on info I've read here I'm assuming it's a TLS version issue, but I haven't figured out how to change the version mosquitto expects. My plug is MSS315 hardware 9.0, firmware 9.5.29 and it has never been connected to the Meross app (I don't want to create accounts).

As stated above, device pairage has changed and currently you can't setup wifi without Meross app. You can still create a random account and follow my comment https://github.com/bytespider/Meross/issues/72#issuecomment-1859218764. Account deletion is an easy step (available in the app).

That's not the issue I'm asking about though. WiFi is set up and working, the issue is that it won't connect to the HA Mosquitto broker because of the TLS cipher incompatibility.

That's not the issue I'm asking about though. WiFi is set up and working, the issue is that it won't connect to the HA Mosquitto broker because of the TLS cipher incompatibility.

You either need to setup an older mosquito or use EMQX instead. Newer versions of mosquito do not allow : as a character in the username, which meross plugs use

PS : A PR has been made between my comment, you don't need to comment lines, just use the --no-wifi flag

--nowifi to be precise (I couldn't use --no-wifi in my PR since the library would parse that in a special way)

You either need to setup an older mosquito or use EMQX instead. Newer versions of mosquito do not allow : as a character in the username, which meross plugs use

I'm using Mosquitto 2.0.18 (HA add-onL 6.4.0) which is the latest version available as a HA add-on, it supports colons in the username, as I have tested experimentally with mosquitto_sub.
I used the --nowifi option to configure the, but as I said, this isn't the problem, I am configuring the plug just fine, but I'm not getting past TLS setup when it attempts to connect to Mosquitto due to:
2023-12-29 20:01:30: New connection from <IP_ADDRESS>:64507 on port 8883.
2023-12-29 20:01:30: OpenSSL Error[0]: error:1417A0C1:SSL routines:tls_post_process_client_hello:no shared cipher
2023-12-29 20:01:30: Client <unknown> disconnected: Protocol error

I've tried using custom settings to lower the TLS version 1.1 for Mosquitto, but it's not actually applying, I also need to try change the available ciphers since that's what it's complaining about. I'll Wireshark it to see what's in the client-hello when I get a minute.
This is why I was asking if anyone has actually managed it, to be sure I'm not doing anything wrong, but it appears the plug is just using TLS proto/cipher that mosquitto isn't allowing.

@override80 just provided some interesting information that the certificate maybe using a newer format other then RSA https://github.com/bytespider/Meross/issues/77

I haven't tested to see whether the plugs validate the server certs so I don't know whether self-CA or self-signed are an option.

They don't 👀 (I use a self-signed ca)

I haven't tested to see whether the plugs validate the server certs so I don't know whether self-CA or self-signed are an option.

They don't 👀 (I use a self-signed ca, and mitm also worked for the official server, so they don't validate it at all)

That's what I expected, and has been my experience with most "smart home" devices.
Cryptographically verifying TLS trust chains on embedded devices can be an issue due to limited resources, there are solutions, but that level of security needs to be a priority and it rarely, if ever is, for these types of consumer devices.

Switch to an RSA key-backed server cert for Mosquitto (and potentially HA if using a "standard" setup); a quick search suggests Let's Encrypt does support that, though a "downgrade" to an RSA key is not something I'd want to do for my certs. The Let's Encrypt add-on may not support this either (I haven't checked), so some changes may be required to it.

If you want to go this way, the addon supports this in configuration. I had to manually rename the letsencrypt/ folder in addons/data/core_letsencrypt/ before issuing the RSA certificate because the plugin does not handle a conversion - i had badically to force the release of a new certificate.

Switch to an RSA key-backed server cert for Mosquitto (and potentially HA if using a "standard" setup); a quick search suggests Let's Encrypt does support that, though a "downgrade" to an RSA key is not something I'd want to do for my certs. The Let's Encrypt add-on may not support this either (I haven't checked), so some changes may be required to it.
I'm curious, why would anyone use Let's Encrypt certificates for local communication? Surely your MQTT broker isn't publicly available.

It's not publicly available, but I use split horizon DNS; devices on my IoT VLAN, and devices I access the dashboard with, can access the MQTT broker using the same DNS name whether internal to my network or external.
Naturally, that means I share the same certificates for all off-box access to home assistant and its add-ons, such as Mosquitto.

Add an additional listener to Mosquitto specifically for the Meross plugs, using a different certificate, so that the standard HA TLS configuration can remain as-is; I haven't tested to see whether the plugs validate the server certs so I don't know whether self-CA or self-signed are an option.

I'd up-vote the per-listener option: it doesn't mess the whole broker setup and allows you fine-grained control over the different listeners configurations. It's like really having multiple brokers for multiple needs. It is also relatively straightforward to setup and I'm going with that since the beginning


Signal Generation Upgrades

Additional features for signal generation include:

geometrical spreading
placing multiple sources
add noise

The general usage can be found in the signal_generation/tests/test_signal_generation.py. Because these tests include plotting they are skipped by default. Use pytest --runplot to run these tests.
Especially the last test should be looked at, because it includes multiple receivers, added noise, and conversion.
I have tried messing around with correlation, but I have not gotten the expected results. So that's something to look into. There were some issues with using int vs float and possibly DC-offsets, but I have not spent much time on it yet.
The following plots are the ones generated from the tests.

Multiple sources, where one is placed further away and you can see the superposition setting in at about 410 samples:

One Source and multiple receivers with activated geometrical spreading and decreasing amplitudes:

Multiple receivers with added noise and unsigned integer conversion:

Merging this now, so I have to do less juggling with branches.


Add usable boolean property to stamp info response

See https://github.com/ethersphere/bee/pull/2063

Also add other fields when this PR is merged: https://github.com/ethersphere/bee/pull/2051


Update dankuzone_w_daic.toml

Description
All previous genesis validators should name their PRs "Update {validator_alias}.toml for tesntet-15" and provide links to previous PRs merged.
Previous PR: https://github.com/anoma/namada-testnets/pull/2205
If this is an UPDATE for a previous genesis validator
Checks are made against your net_address. If this has changed since the previous testnet, make sure you provide links of previous prs merged from your previous git username.
Thanks in advance!
Checklist before merging

[x] Only one toml is added in this PR
[x] The file being added is indeed a .toml file
[x] The toml being added is to the correct folder, and only to the correct folder
[x] The eth_hot_key and eth_cold_key are present
[x] The email, discord, elements telegram, and twitter fields are present and valid

Successfully validated transactions.toml file for commit hash b9a0ea6


added code analysis step

LGTM. Do we have team JetBrain account or i need to create my own?

I've created an account for myself to test with. Will look into getting a company account later


CORTX-32095: Problem: hax entrypoint reply may delay on restart

Hare sends OFFLINE event on whenever process restarts, it does not
check if the process is a hax or motr client process. If hax process
restarts, it sends FirstEntrypointRequest and will try to send offline
for itself, since no halink is established, the delivery will timeout
and can further delay the entrypoint processing. Which may cause other
side effects. There's no need to send OFFLINE for hax and motr client
processes.
Solution:
Skip Hax and motr client processes while sending OFFLINE for
FirstEntrypoint requests.
Signed-off-by: Mandar Sawant<EMAIL_ADDRESS>

please retest this

Tested with the ongoing IO with m0d failures and rgw failures and no issues observed.
[root@ssc-vm-g4-rhev4-0717 ~]# s3bench -accessKey=sgiamadmin -accessSecret=ldapadmin -bucket=test-40039-bucket-1-healthy-$(dat
e +%d%m-%H%M%S) -endpoint=https://<IP_ADDRESS>:30443 -numClients=10 -numSamples=100 -objectNamePrefix=object-degraded -object
Size=16Mb -skipSSLCertVerification=True -s3MaxRetries=3 -region us-east-1 -validate -skipCleanup
Write done in 16s with 0 errors
Read done in 9s with 0 errors
Validate done in 10s with 0 errors
With custom build, I have started a script which runs s3bench in parallel, wait for sometime io to complete than kill one of the ioservice - This happens in a loop.
so far test has completed few rounds and do not see any issue,
cortx-data-ssc-vm-g2-rhev4-3290-79ddd7768d-h6nkz 4/4 Running 4 (76m ago) 171m
cortx-data-ssc-vm-g4-rhev4-1669-5b4ff96464-t5gb9 4/4 Running 3 (8m20s ago) 171m
cortx-data-ssc-vm-g4-rhev4-1714-f854fb64c-44hhm 4/4 Running 1 (25m ago) 171m
cortx-data-ssc-vm-g4-rhev4-1715-869779dbbd-2vrfq 4/4 Running 4 (3m22s ago) 171m
cortx-data-ssc-vm-g4-rhev4-1719-69b59b9c6-l92jn 4/4 Running 1 (19m ago) 171m
cortx-ha-785fd4968f-r2bcg 3/3 Running 0 167m
cortx-kafka-0 1/1 Running 2 (174m ago) 175m
cortx-kafka-1 1/1 Running 2 (174m ago) 175m
cortx-kafka-2 1/1 Running 1 (174m ago) 175m
cortx-server-ssc-vm-g2-rhev4-3290-5849954ddf-q8q9q 2/2 Running 1 (108m ago) 169m
commit details  for reference:[root@cortx-data-headless-svc-ssc-vm-g2-rhev4-3290 /]# rpm -qa | grep cortx
cortx-provisioner-2.0.0-5045_325a3e0b.noarch
cortx-hare-2.0.0-6887_gitab286e2.el8.x86_64
cortx-motr-2.0.0-6887_gite1f5e80e.el8.x86_64
cortx-py-utils-2.0.0-6887_76bd9e4b.noarch


Update README.md

Changed "in a folder directly under C: and in a folder where your user have full access rights:" to "in a folder directly under C:, in a folder where your user has full access rights:"

 Thank you for your submission, we really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.You have signed the CLA already but the status is still pending? Let us recheck it.


Remove GaudiConfig in Stable Diffusion code snippets

What does this PR do?

This PR removes from optimum.habana import GaudiConfig in the Stable Diffusion code snippets in the documentation and README since it is not used in these examples.
Before submitting

[x] This PR fixes a typo or improves the docs (you can dismiss the other checks if that's the case).
[ ] Did you make sure to update the documentation with your changes?
[ ] Did you write any new necessary tests?

The docs for this PR live here. All of your documentation changes will be reflected on that endpoint.


Allow GroupHandler to set a formatter to all nested handlers

Hello,
I would like to know if it's possible to add such shortcut for the GroupHandler?
Thanks,

Why not I guess..

Thanks @Seldaek!

Should I port the change to the master branch?

No I'll merge 1.x into master myself it's easier to keep the branches consistent that way I think but thanks :)


Container live migration proposal

One of the questions we've been getting a lot is how can we support live migration. It's tricky, and the networking is probably the hardest part, but it would be interesting to see if it could fit into swarm.

I'm not sure where (or if) it might fit into the top level categories here, but some discussion of the docker level interface for interacting with checkpoints would also be great.


Artifacts on study list page do not match study

When I expand the options for Suzie Hong's study, Qiita ID 11259, it shows some ITS files that are not in the file tree.
Here's an image of the expanded files:

Here's the file tree:

I'm not sure what's causing the files to show up one place but not the other.  Thank you!

The list you are showing is the list of all BIOMs for all preparations in your study and the three visualization is for a single prep. Hope this helps and if it does, can you close this issue? Thanks!

Clarifying this issue, the problem is that the user only has access to 1 prep and it's seeing the artifacts for all preps.

I do only have one prep available on Qiita.  Here's a screen shot of that if it's helpful:


narsil: 1.3.0-187-g96d6b3bbd -> 1.3.0-234-g228c4f0cb

Automatic update generated by nixpkgs-update tools. This update was made based on information from passthru.updateScript.
meta.description for narsil is: Unofficial rewrite of Sil, a roguelike influenced by Angband
meta.homepage for narsil is: https://github.com/NickMcConnell/NarSil/
meta.changelog for narsil is: https://github.com/NickMcConnell/NarSil/releases/tag/1.3.0-234-g228c4f0cb
Updates performed

Ran passthru.UpdateScript

To inspect upstream changes

Release on GitHub

Compare changes on GitHub

Impact
Checks done

built on NixOS
The tests defined in passthru.tests, if any, passed
found 1.3.0-234-g228c4f0cb in filename of file in /nix/store/gsmfwza2lp000d306hw17yprj8rjq2mm-narsil-1.3.0-234-g228c4f0cb

Rebuild report (if merged into master) (click to expand)

2 total rebuild path(s)

2 package rebuild(s)

First fifty rebuilds by attrpath

narsil

Instructions to test this update (click to expand)

Either download from Cachix:
nix-store -r /nix/store/gsmfwza2lp000d306hw17yprj8rjq2mm-narsil-1.3.0-234-g228c4f0cb \
  --option binary-caches 'https://cache.nixos.org/ https://nix-community.cachix.org/' \
  --option trusted-public-keys '
  nix-community.cachix.org-1:mB9FSh9qf2dCimDSUo8Zy7bkq5CX+/rkCWyvRCYg3Fs=
  cache.nixos.org-1:6NCHdD59X431o0gWypbMrAURkbJ16ZPMQFGspcDShjY=
  '

(The Cachix cache is only trusted for this store-path realization.)
For the Cachix download to work, your user must be in the trusted-users list or you can use sudo since root is effectively trusted.
Or, build yourself:
nix-build -A narsil https://github.com/r-ryantm/nixpkgs/archive/a97827f878e603a8856233cdb9bbbd29e20d9790.tar.gz

Or:
nix build github:r-ryantm/nixpkgs/a97827f878e603a8856233cdb9bbbd29e20d9790#narsil

After you've downloaded or built it, look at the files and if there are any, run the binaries:
ls -la /nix/store/gsmfwza2lp000d306hw17yprj8rjq2mm-narsil-1.3.0-234-g228c4f0cb
ls -la /nix/store/gsmfwza2lp000d306hw17yprj8rjq2mm-narsil-1.3.0-234-g228c4f0cb/bin

Pre-merge build results
We have automatically built all packages that will get rebuilt due to
this change.
This gives evidence on whether the upgrade will break dependent packages.
Note sometimes packages show up as failed to build independent of the
change, simply because they are already broken on the target branch.
Result of nixpkgs-review run on x86_64-linux 1

1 package built:

narsil

Maintainer pings
cc @nanotwerp @x123 for testing.

[!TIP]
As a maintainer, if your package is located under pkgs/by-name/*, you can comment @NixOS/nixpkgs-merge-bot merge to automatically merge this update using the nixpkgs-merge-bot.

Add a :+1: reaction to pull requests you find important.

Works great on x86_64-linux @NixOS/nixpkgs-merge-bot merge

@NixOS/nixpkgs-merge-bot merge

Trying again, maybe some github downtime for actions or APIs.
@NixOS/nixpkgs-merge-bot merge


fixes galore

now streaming instead of fs.readFileSync
directory listings
index.html support
tap tests

Union broke since it doesn't have setHeader(). I checked out the git repo for union and tried to run the tests but those also fail so I'm writing off union for the moment.

 This looks like good stuff but Union support isn't something I'm willing to throw out.
I've made some efforts to improve union to bring its request and response objects up-to-snuff; I'm sure those will be finished in due time. I might sit on this PR until then.

I gave this a lookthrough, and I'm diggin' it. I merged this in, and got the ball rolling on bringing Union up-to-snuff. Basically, the problems with Union are two-fold:

getHeader, setHeader, etc. are unimplemented (It's been added to the gh-4 branch but hasn't been shown to work)
stream piping is broken (needs to get fixed)

Lack of streaming is a pretty egregious bug as far as union support goes, so I can't blame you there.


Compiled Bourbon CSS

Is there anyway to get compiled bourbon css only?. I don't wanna compile scss on my own. Just like bootstrap there should be precompiled bourbon.css, isn't it?

Hi @vs4vijay!
Bourbon is actually quite a bit different from Bootstrap, the biggest being that Bourbon out-of-the-box has zero CSS to compile. There is no output when you first include Bourbon, rather it now provides you with a series of tools (mixins, functions, etc.) to use within your project.
Hope that helps.


Question about converting pytorch-ada model.

Thank you for your excellent work!
Thus, I can use export_weights.py to convert offical implimation to your .pt format.
However, export_weights.py only support convert parameters of generator. Could you have any plan about releasing code for convert parameters of discriminter?

We took the conversion scripts from other repos and therefore have no intention to provide support for converting the parameters of the discriminator. You can possibly open an issue in the original repositories where the code was taken from and ask them there.


Update README.md

Made changes to the document by adding more emojis, shield badges, table for discord link and a ReadMe Typing SVG image: 'Welcome-to-Pathsphere'.

Issues Identification
Closes: #271
Description
Summary
Made the document by adding more emojis, shield badges, table for discord link and a ReadMe Typing SVG image of 'Welcome-to-Pathsphere'.
Types of Changes
Please check the boxes that apply

[ ] Bugfix (non-breaking change that fixes an issue)
[ ] New feature (non-breaking change that adds functionality)
[ ] Breaking change (fix or feature that would cause existing functionality to not work as expected)
[.] Documentation update (Documentation content changed)
[ ] Other (please describe):

Checklist
Please check the boxes that apply

[. ] My code follows the style guidelines of this project
[ .] I have performed a self-review of my own code
[. ] I have commented my code, particularly in hard-to-understand areas
[. ] I have made corresponding changes to the documentation
[. ] My changes generate no new warnings
[. ] My changes do not break the current system and pass all existing test cases
[. ] I have added tests that prove my fix is effective or that my feature works
[ .] New and existing unit tests pass locally with my changes

@Apoorva57 you can also commit suggestion just need the heading to be in bold


Keyboard Shortcuts and Controls Cleaning

[ ] Screenshot Shortcut

[x] CTRL/CMD-ALT-S
[x] Upload Screenshot
[x] Copy link to clipboard
Should there be a notification? (Notifications not working on Windows ). Or should we change the IPFS icon when we are uploading?

[ ] Upload File Shortcut
[ ] Download selected hash shortcut
[x] Clean controls

@diasdavid AFAIK, Electron can't get selected text on screen that's not inside electron's view due to security reasons. The same happens to files: I can't know if the keys were pressed when selecting files so I don't think it is possible to create those shortcuts right now, but I'll investigate a bit more.

@diasdavid could you take a look at the code? I'm thinking of merging this and do the other two shortcuts for later (when it's possible or when I find a solution).

Absolutely hate Jenkins. Build failed on Windows, but it's working. It was a download error.


Add ability to define device

https://github.com/microsoft/playwright/blob/master/docs/api.md#browsertypedevices

Added in 0.0.4


Problem logging in to Digital Twins Graph Viewer

Working through https://docs.microsoft.com/en-us/azure/digital-twins/quickstart-view-occupancy-dotnet I have got as far as provisioning the graph, having eventually succeeded in registering an app in Azure Active Directory to take care of the necessary authentication. The instructions for this were far from obvious! What I wanted to do next was to “view and modify” the spatial graph using the Azure Digital Twins Graph Viewer. I'm able to run that application in a container on my laptop, and can interact with it through my browser, at localhost, however I can not get it to sign me in – it just keeps telling me “you are not signed in”, repeatedly. I don't seem to be getting any error messages. What could be causing this?

Document Details
⚠ Do not edit this section. It is required for docs.microsoft.com ➟ GitHub issue linking.

ID: 40122dc8-6ffa-cc83-102b-e3207f35efad
Version Independent ID: 0e52b26d-c146-1412-f927-d761486f9571
Content: Quickstart: Find available rooms - Azure Digital Twins
Content Source: articles/digital-twins/quickstart-view-occupancy-dotnet.md
Service: digital-twins
GitHub Login: @alinamstanciu
Microsoft Alias: alinast

I wish I'd known this a couple of weeks ago, but I've just found out that the Chrome browser I was using has some problem with this app. Changing to Firefox I had immediate success. Edge also works

@johnnzy1 Thanks for the feedback! We are currently investigating and will update you shortly.

@johnnzy1 If you encounter this issue in future try to clear the browser cookies and cache. Also try in-cognito mode and see if that resolves your issue.
We will now proceed to close this thread. If there are further questions regarding this matter, please tag me in your reply. We will gladly continue the discussion and we will reopen the issue.


[release-1.15] Fix 0103 warning for non-injected pods on the host network

This is an automated cherry-pick of #40220

@istio-testing: The following test failed, say /retest to rerun all failed tests or /retest-required to rerun all mandatory failed tests:

Test name
Commit
Details
Required
Rerun command

integ-basic-arm64_istio_release-1.15
bfcc3ba604ef3328e915c8a67aca10bb0b48f51f
link
true
/test integ-basic-arm64_istio_release-1.15

Instructions for interacting with me using PR comments are available here.  If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. I understand the commands that are listed here.

@istio-testing: The following tests failed, say /retest to rerun all failed tests or /retest-required to rerun all mandatory failed tests:

Test name
Commit
Details
Required
Rerun command

integ-basic-arm64_istio_release-1.15
bfcc3ba604ef3328e915c8a67aca10bb0b48f51f
link
true
/test integ-basic-arm64_istio_release-1.15

unit-tests-arm64_istio_release-1.15
bfcc3ba604ef3328e915c8a67aca10bb0b48f51f
link
true
/test unit-tests-arm64_istio_release-1.15

Instructions for interacting with me using PR comments are available here.  If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. I understand the commands that are listed here.

/retest

/retest


[Bug]: Exception: {"error":"InvalidUUID","message":"Could not parse test_collection as a UUID"}

What happened?
I was trying to use the client-server in Chroma and facing issues while trying to add a collection or do anything with the collection created with Openai embedding
import chromadb
from chromadb.config import Settings
from chromadb.utils.embedding_functions import SentenceTransformerEmbeddingFunction
from langchain.embeddings.openai import OpenAIEmbeddings
import os

os.environ["OPENAI_API_KEY"] = ""
embeddings = OpenAIEmbeddings()
#embedding_function = SentenceTransformerEmbeddingFunction(embeddings)
client = chromadb.Client(
    Settings(chroma_api_impl="rest", chroma_server_host=" ", chroma_server_http_port="",anonymized_telemetry=False)
)

print(client.heartbeat())

client.reset()

collections = client.create_collection(
    name="test_collection",
    embedding_function=embeddings
)

# add some documents in the created collection

collections.add(
    embeddings=[
        [1.1, 2.3, 3.2],
        [4.5, 6.9, 4.4],
        [1.1, 2.3, 3.2],
        [4.5, 6.9, 4.4],
        [1.1, 2.3, 3.2],
        [4.5, 6.9, 4.4],
        [1.1, 2.3, 3.2],
        [4.5, 6.9, 4.4],
    ],
    metadatas=[
        {"uri": "img1.png", "style": "style1"},
        {"uri": "img2.png", "style": "style2"},
        {"uri": "img3.png", "style": "style1"},
        {"uri": "img4.png", "style": "style1"},
        {"uri": "img5.png", "style": "style1"},
        {"uri": "img6.png", "style": "style1"},
        {"uri": "img7.png", "style": "style1"},
        {"uri": "img8.png", "style": "style1"},
    ],
    documents=["doc1", "doc2", "doc3", "doc4", "doc5", "doc6", "doc7", "doc8"],
    ids=["id1", "id2", "id3", "id4", "id5", "id6", "id7", "id8"],
)

# search for similar documents

results = client.get_collection("test_collection").search("This is a test document")
print(results)

# delete the collection

Versions
python 3.9.7
Relevant log output
Exception: {"error":"InvalidUUID","message":"Could not parse test_collection as a UUID"}

@uzumakinaruto19 are you on latest or 0.3.22?
@levand is this related to our naming change the other day?

@uzumakinaruto19 are you on latest or 0.3.22?
@jeffchuber  latest

I get a similar error when doing ingestion:
    data: {
      error: 'InvalidUUID',
      message: 'Could not parse energizer-234 as a UUID'
    }
    ```

@uzumakinaruto19 have you figured it out?

I fixed it by basically installing additional packages from requirements.txt 😅

When using a REST server, this could certainly be caused by using an older version of the chromadb client with a newer version of chromadb server.

still got the error, even my Chromadb version is 0.3.22
 {"error":"InvalidUUID","message":"Could not parse my_collection as a UUID"}

Same issue here, rolling back to 0.3.12 did the trick !

Thanks @suyingtao I'll check with latest version !

confirm that @suyingtao 's solution works

Closing this as it is stale. Please let me know if anything else pops up here and we can re-open it.


Filter on home

AngularJS comes stock with really neat string filtering.
As a "heavy" user of MyUW, I found if I have more than 10 widgets on my home screen, things are hard to find quickly w/o doing a CTRL+F and searching for the string. Maybe that is just the CS person in me?
SO, I thought I would try adding in an alpha flag that lets me have my ctrl+f.

Add alpha settings page for /web (under /web/settings/web)
Adds flag for filter
Adds filter for widget and list view

Screenshots
New alpha settings page

Filter Button before click

Filter After Click of Filter

Animation of a filter

:+1: .  If/when this merges let's tee up a Story to get some user testing time on this, so that we can decide to :shipit: for real, not-hidden-by-flag.  But I love the flag approach initially to allow user testing it for reals in prod without committing to the feature yet.

Chatted with @keirserrie . Going to commit as its hidden anyway so he can play.

Here's an idea--start with buttons w/explicit text:

Pressing filter button takes over the entire area:

nice, we could even do a cute transition or something flashy.


reduce time spending in poll

based on: https://github.com/confluentinc/kafka-connect-jdbc/pull/677

@ivanyu one thing this changes that I accounted for in #59 is the message
log.trace("Waiting {} ms to poll {} next", nextUpdate - now, querier.toString());

is no longer accurate.  I might suggest using sleepMs (or adding both, as I did in #59, for clarity)

Good point @NJAldwin, thank you. Will be fixed in https://github.com/aiven/aiven-kafka-connect-jdbc/pull/64


Search only seems to find ancient posts

The search functionality doesn't seem to work properly right now.
I get some results for "Bioconductor" or "limma", but nothing for "DESeq2" or "biomart".

It looks like the results I get are all from posts at least 16 years old.

Thanks for letting us know, we had indexed a small sample to make sure things functions. All posts are now indexed and searchable.


Powershell Install doesn't respect spaces in path for VSIX install

𝗗𝗲𝘀𝗰𝗿𝗶𝗯𝗲 𝘁𝗵𝗲 𝗯𝘂𝗴
If you were to install into the following path C:\Example Folder when the powershell script starts the install of the VSIX it simply calls the location of the VSIX without quotations which then throws errors about the path.

post the console output

also the script is again public just in case some one want to fix it
https://github.com/eXpandFramework/XpandPwsh/blob/master/XpandPwsh/Private/Xpand/InstallXpand.ps1
you just download and run and let me know the fix or send a PR

Closing issue for age. Feel free to reopen it at any time.
.Thank you for your contribution.


Integrating FlashDecode_v2 to llama3 t3k

T3K Unit:
Post-commit:

New pipelines:
https://github.com/tenstorrent/tt-metal/actions/runs/10014023607

https://github.com/tenstorrent/tt-metal/actions/runs/10014033622

t3k frequent: https://github.com/tenstorrent/tt-metal/actions/runs/10041223682

t3k demo with new ground truth: https://github.com/tenstorrent/tt-metal/actions/runs/10045664115


Add endpoint to add a user

What was done:

Add the addPerson function (endpoint: /onboarding/user) to create a new user, it'll receive an userForm of PersonUpdateRequest type.
The updatePerson function will return an object so on the flexbase-web side I can update the user updated with the object returned.
Add tests for the addPerson function.

:tada: This PR is included in version 1.0.0 :tada:
The release is available on GitHub release
Your semantic-release bot :package::rocket:


iOS Accessibility - add headerBackAllowFontScaling option

On iOS, apps can support larger font sizes for accessibility.

React-native supports this out-of-the-box, which is awesome. But the navigation bar turns into kind of a UX disaster:

Looking at default iOS apps provided by Apple, they often don't scale the navigation bar, which makes sense given the limited real-estate, so it's OK to turn that off. Like for example, here's what the settings app looks like with font-sizes maxed out.

And react-navigation provides an option for turning off font scaling for the title, getting us closer to a usable navigation bar:
navigationOptions: {
        headerTitleAllowFontScaling: false,
}

But it doesn't have an option for the back button, which this PR addresses.
navigationOptions: {
        headerBackAllowFontScaling: false, // new!
        headerTitleAllowFontScaling: false,
}

I'm excited about getting this change into react-navigation. If there's anything I can do to help that process please let me know.

thank you @mikelovesrobots! we should make this default to false

once this PR lands can you open a PR to update docs on https://github.com/react-navigation/react-navigation.github.io please?

once this PR lands can you open a PR to update docs on https://github.com/react-navigation/react-navigation.github.io please?

Absolutely. I'll open a PR in a bit.

@brentvatne Here's a link to the documentation update:
https://github.com/react-navigation/react-navigation.github.io/pull/366
Looking at it, the back button now defaults to false (for font scaling), but the title defaults to true. Is it weird to have those two defaults out of sync? Feels weird to me.

good point, we should make title default to false  as well


fhir-smart not enforced for JSONPatch and FHIRPathPatch

Describe the bug
fhir-smart does appear to enforce JSONPatch and FHIRPathPatch requests. When using a JWT with ff94628809f34970a7a8199bccf2f23c as one of the patient_ids and a "patient/*.read" scope the following happens:
This PUT request gives a 403 as expected:
curl 'http://localhost:9080/fhir-server/api/v4/Patient/ff94628809f34970a7a8199bccf2f23c' -H "Authorization: Bearer $bearer" -H 'Content-Type: application/json' -d '{"resourceType": "Patient", "id": "ff94628809f34970a7a8199bccf2f23c", "gender":"female"}' -X PUT

However, if I do what is essentially the same request using JSONPatch, the change is allowed:
curl 'http://localhost:9080/fhir-server/api/v4/Patient/ff94628809f34970a7a8199bccf2f23c' -H "Authorization: Bearer $bearer" -H 'Content-Type: application/json-patch+json' -d '[{ "op": "add", "path": "/gender", "value": "female" }]' -X PATCH

With FHIRPathPatch the same can be observed.
I initially suspected that it was because org.linuxforhealth.fhir.smart.AuthzPolicyEnforcementPersistenceInterceptor does not have a beforePatch method, but after adding this method (with the same implementation as beforeUpdate) the problem persisted.
Am I missing something, or is this a bug in fhir-smart?
Environment
I'm currently still using 4.11.1. Looking through the changelogs and relevant code I don't believe this has already been fixed in the newer versions.
To Reproduce
Steps to reproduce the behavior:

Have a JWT with read-only access to a patient (I'm using "patient/*.read")
Perform a JSONPatch or FHIRPathPatch request for data belonging to the current patient.
The request will succeed.

Expected behavior
The request should not succeed unless the JWT has a write scope for the resource.

Generated a token with scope "patient/*.read" for patient_id 184f5967297-a894709d-f46c-4746-b4af-5d4498ea568e

The JSONPatch request for patient_id 184f5967297-a894709d-f46c-4746-b4af-5d4498ea568e resulted in a 403 error as expected.

https://localhost:9443/fhir-server/api/v4/Patient/1850f9523a4-c7c2cc41-6544-404b-843a-7620eac731d9
HTTP Method : PATCH
Content-Type : application/json-patch+json
[{ "op": "add", "path": "/gender", "value": "male" }]

The update Patient(id = 184f5967297-a894709d-f46c-4746-b4af-5d4498ea568e) request resulted in a 403 error as expected.

https://localhost:9443/fhir-server/api/v4/Patient/1850f68db41-47bef013-5630-4ec8-90a1-b0038a56353d
HTTP Method : PUT
Content-Type : application/json
{
	 "id" : "1850f68db41-47bef013-5630-4ec8-90a1-b0038a56353d",
    "resourceType" : "Patient",
    "active" : true,
    "name" : [ {
        "family" : "Doe2",
        "given" : [ "John" ]
    } ],
    "gender" : "male"
}


Do a roundtrip message transfer for test_send_recv_am

A roundtrip ensures the client receives the reply and thus prevents us from the checking for a transfer that didn't complete yet.

Thanks @wence- !

/merge


run_offline_lidar_obstacle_perception.sh is not working

We appreciate you go through Apollo documentations and search previous issues before creating an new one. If neither of the sources helped you with your issues, please report the issue using the following form. Please note missing info can delay the response time.
System information

OS Platform and Distribution : Linux Ubuntu 20.04
Apollo installed from : source
Apollo version : 6.0
Output of apollo.sh config if on master branch

Steps to reproduce the issue:

Please use bullet points and include as much details as possible:

(From the ${APOLLO_ROOT_DIR} directory)
./docker/scripts/dev_start.sh
./docker/scripts/dev_into.sh
cd modules/perception/lidar/tools/
chmod a+x run_offline_lidar_obstacle_perception.sh
./run_offline_lidar_obstacle_perception.sh

Error occurs like this.

Where is "offline_lidar_obstacle_perception" file?
If I have to build "offline_lidar_obstacle_perception.cc" file, how can I build?
Supporting materials (screenshots, command lines, code/script snippets):
Directory where run_offline_lidar_obstacle_perception.sh is located is like this

you can try mv BUILD_ BUILD , offline_lidar_obstacle_perecption does not build by default

@fergcd This tool is defunct and we will decide in the near future whether to fix it or provide a new tool. If there is an update, we will notify you as soon as possible!


cs-cz update and some corrections

im sorry that i didnt react earlier, im so overwhelmed about all those python 'batteries'..
sometimes im forgeting even to go to sleep :D

btw again: im the very noob on versioning source code, so please let me know if i'm doing something wrong or not as expected ;) thanks. Tom

oh i see now :D .. ten commits to change one file.. sry i hoped that some 'magic in the middle' will consolidate those .. it looks like its time for man git or stop pushing every letter.. lol

Hi thank you so much for the update. Can you please fix the conflict.


fixes #4128

adds a check for the possible overflow in Conformer::setAtomPos() and throws a ValueError on overflow.
Maybe it should be a PRECONDITION instead to be consistent? Seems like a ValueError though.

@bp-kelley : what do you want changed here?

It's more of a question than a change, but if we don't target 32 bits, then the change would be:
d_positions.resize( std::vector::size_type(atomId) + 1, RDGeom::Point3D(0.0, 0.0, 0.0));

It's more of a question than a change, but if we don't target 32 bits, then the change would be:
d_positions.resize( std::vector::size_type(atomId) + 1, RDGeom::Point3D(0.0, 0.0, 0.0));

Sure, but I don't see what the benefit in doing that is. It allows the resize to succeed in this one very specific case (where atomId == unsigned::max) but doesn't help anywhere else. I mean, I don't really care... I can make this code change, but I wonder if you actually think it's important or if you're just pointing out that there's an alternate solution?
If we want to actually allow 64 bit atom indices (something I really question) we need to change large chunks of the API and a bunch of code. And that's not this PR.


Updates the printed content from the config file

Using mpconfig.settings prints the config properly. The msticpy would not work in the Jupyter notebook.
Also changed from pprint to just using plain json.dumps.

/azpipelines run


Deleting a user throws an error due to the update_user_roles function

Hello!
First of, let me thank you for this great work, it helped immensely in setting up RBAC :)
While developing the user management part of my app I stumbled upon the following error: Deleting a user throws an error due to the update_user_roles function. This happens because I'm cascading the deletion of the user in the group_users table. This, in turn, triggers the update_user_roles function to update the user's roles, but it fails since it can't find the user. I believe a "User exists" check could be added to this function:
SELECT id
INTO _user_check_id
FROM auth.users au
WHERE au.id = _user_id;

IF _user_check_id IS NOT NULL  THEN

Oh that's interesting. I've only used soft-deletes for my users so far but I'll test this out and find a fix. Thanks for the report!

I'm having a hard time reproducing this. Can you let me know which version of the project you are using and provide a test example? If it's easier, feel free to set up a local supabase copy with migrations and dummy data that can reproduce when deleting.


Issue with sit and stare data

Hi, I am trying to work with some sit and stare data. However, the keywords and plots refer to the time axis as a spatial one. It would great if you could add some functionality that accounts for the different observation mode. Thanks!

Hello Richard,
Good point! I will work on getting the code updated to better support sit-and-stare. It should mostly be a matter of updating coordinate information, but I will need to make sure nothing funny happens with slicing or smoothing the data cube.

Hello Richard,
Just a quick update. We have not entirely forgotten about this issue. Unfortunately, the ability to cleanly specify partial spatial coordinate information was removed in NDCube v2.0. There are some workarounds by modifying the wcs object directly, but we have not found a proper solution that also allows for slicing the EISCube or exporting the results to a SunPy map. We will probably need to just write our own plotting routines to override the default plots, but have not had the time to do so yet.


Fix memory leak.

As you know, plain C has not RAII, so the structure created in
https://github.com/asashnov/tinycurl/blob/00b89ffaf753e024fbdb2dc0cacc679b99fb9901/tinycurl.cpp#L29
Is never deallocated by the underlying library. I opted in this pull request to let this structure as a private member and clean in the destructor:
https://github.com/phoemur/tinycurl/blob/b95a68f84ecc171638d00b5de688869f9d7493f3/tinycurl.cpp#L24
Also improved the resource creation in the constructor and better cleanup in this pull request.
This small change seems to make a huge difference, as you can see:
Valgrind before changes:
`
==3320==
==3320== HEAP SUMMARY:

==3320==     in use at exit: 96,824 bytes in 3,233 blocks

==3320==   total heap usage: 4,324 allocs, 1,091 frees, 391,637 bytes allocate

==3320==

==3320== LEAK SUMMARY:

==3320==    definitely lost: 0 bytes in 0 blocks

==3320==    indirectly lost: 0 bytes in 0 blocks

==3320==      possibly lost: 0 bytes in 0 blocks

==3320==    still reachable: 96,824 bytes in 3,233 blocks

==3320==         suppressed: 0 bytes in 0 blocks

==3320== Reachable blocks (those to which a pointer was found) are not shown.

==3320== To see them, rerun with: --leak-check=full --show-leak-kinds=all

==3320==

==3320== For counts of detected and suppressed errors, rerun with: -v

==3320== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0)

`
Valgrind After changes:
`
==3419==
==3419== HEAP SUMMARY:

==3419==     in use at exit: 528 bytes in 10 blocks

==3419==   total heap usage: 4,324 allocs, 4,314 frees, 391,637 bytes allocated

==3419==

==3419== LEAK SUMMARY:

==3419==    definitely lost: 0 bytes in 0 blocks

==3419==    indirectly lost: 0 bytes in 0 blocks

==3419==      possibly lost: 0 bytes in 0 blocks

==3419==    still reachable: 528 bytes in 10 blocks

==3419==         suppressed: 0 bytes in 0 blocks

==3419== Reachable blocks (those to which a pointer was found) are not shown.

==3419== To see them, rerun with: --leak-check=full --show-leak-kinds=all

==3419==

==3419== For counts of detected and suppressed errors, rerun with: -v

==3419== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0)`

I could not eliminate all leaks, though going from 96,824 to 528 bytes in use at exit semmed worth a pull request.
Thanks for your attention

Also noted that the remaining bytes left behind here allocated by curl itself through libcrypto:
CRYPTO_malloc (in /lib64/libcrypto.so.1.0.0)
So there's not much we can do about it.


SYNC: Synched with Luis upstream repo, resolving conflicts

python mlm_training.py -v run fine with sys.exit() in line 402

Introduce stylistic changes in your own commits if you want them. Or just turn off you formatter in VS code.

Also, ec63884 is duplicate of prexisting 5cc14b2a13da12be605a108dff03accec3ecdc27 and therefore cannot rebase. Either rebase your changes into current maste of this repo or figure something out with chatgpt that accomplishes the same thing.

noted

about the pre-existing commits, when we merge it (mlm_training) it has all of those conflicts...
anyways will fix em b4 tomorrow :0

about the pre-existing commits, when we merge mlm_training.py, it has all of those conflicts... anyways will fix em b4 tomorrow :0

If you guys can't make it you can still push your WIP into your own fork and I'll fix it. Just ping me please.  Remember what while you guys sleep I can work now.


Grpc.Tools attempts to run 64bit protoc even on 32-bit linux system.

"/var/local/git/grpc/test/distrib/csharp/DistribTest.sln" (default target) (1) ->
"/var/local/git/grpc/test/distrib/csharp/DistribTest/DistribTest.csproj" (default target) (2) ->
(_Protobuf_CoreCompile target) ->
  /var/local/git/grpc/test/distrib/csharp/packages/Grpc.Tools.1.19.0/build/_protobuf/Google.Protobuf.Tools.targets(263,5): error MSB6006: "/var/local/git/grpc/test/distrib/csharp/packages/Grpc.Tools.1.19.0/tools/linux_x64/protoc" exited with code 255. [/var/local/git/grpc/test/distrib/csharp/DistribTest/DistribTest.csproj]

    3 Warning(s)
    1 Error(s)

Time Elapsed 00:00:05.68
+ FAILED=true
+ '[' '' '!=' '' ']'
+ docker rm -f build_and_run_docker_ad5750a7-2495-4db7-9228-75d6a234defc
build_and_run_docker_ad5750a7-2495-4db7-9228-75d6a234defc
+ '[' true '!=' '' ']'
+ exit 1
FAILED: distribtest.csharp_linux_x86_jessie [ret=1, pid=187578, time=28.0sec]

CC @kkm000  this error happens when running inside an 32bit docker container on a 64bit machine,
which doesn't seem to be handled well by the platform detection code in
https://github.com/grpc/grpc/blob/4ef6a274271406f961f2fc9cc639ae204d4d128e/src/csharp/Grpc.Tools/Common.cs#L71

This is a bit related to https://github.com/grpc/grpc/pull/17437

Is this mono or dotnet?

Is 32-bit container even possible on a 64-bit host? I thought a container always uses the host's kernel. This is a container, not a VM?

It's mono.
A bit more background:
Well it's a 32bit linux libraries running on a 64bit linux. (you can get a docker image that has a 32bit installation of debian - obviously the 64bit protoc is not going to work there because all the system C libraries are missing and only 32bit libs are "installed" - a 32bit build protoc will work just fine, but we need to make sure to select it).

A 64-bit kernel can run 32-bit processes, so a "32-bit container" is just an image with 32-bit ld.so and executables. Just like running 32-bit process on a normal 64-bit machine. The os is still 64 bit, but there is no 64-bit ld.so. Weird. Wound the linux32 command help?
kkm@yupana:~$ docker run --rm -it i386/debian:9
Unable to find image 'i386/debian:9' locally
9: Pulling from i386/debian
3cf1c3e5c1c3: Pull complete
Digest: sha256:657c9a7aa7735b0f0273562c2f55e5dc1a3783ff70dbdb1a3c415d978f24c84d
Status: Downloaded newer image for i386/debian:9
root@bcb4d6cff153:/# uname -a
Linux bcb4d6cff153 4.15.0-45-generic #48-Ubuntu SMP Tue Jan 29 16:28:13 UTC 2019 x86_64 GNU/Linux
root@bcb4d6cff153:/# linux32 uname -a
Linux bcb4d6cff153 4.15.0-45-generic #48-Ubuntu SMP Tue Jan 29 16:28:13 UTC 2019 i686 GNU/Linux
root@bcb4d6cff153:/#

In the meantime I came up with this:
https://github.com/grpc/grpc/pull/18467/files#diff-3af54eacd0b2cf68b28672cd2651034dR91

Oh, and there is also RuntimeInformation.ProcessArchitecture. I do not know which one is which. I can only hope the Environment.Is32BitProcess (the only one existing before dotnet) mirrors this one.
Maybe we should always use the current process' architecture, for both Mono and dotnet, what do you think? The idea is If we are running inside an N-bit MSBuild, then the OS is capable of running N-bit processes. Should be true for any N, unless maybe it's a Mac. These can easily beat any math an logic, in my experience, so it's better to verify...
Is this Docker or lxc (or Google's own)? I remember there was a difference; AFAICR, lxc is capable of somehow virtualizing the container, essentially turning it into a little VM. I do not understand this mechanism. But all 32-bit Docker images invariably package linux32. What happens if you try running msbuild command with linux32 msbuild in the test? Or is it just not worth checking?

Looks like linux32 does not have much effect at all on my machine. I thought it was a real thing...
$ cat bitness.cs
using System.Runtime.InteropServices;
class _ {
  static void Main() {
    System.Console.WriteLine("OS={0} Process={1} Env.Is64Os={2} Env.Is64Proc={3}",
      RuntimeInformation.OSArchitecture,
      RuntimeInformation.ProcessArchitecture,
      System.Environment.Is64BitOperatingSystem,
      System.Environment.Is64BitProcess);
} }

Mono
$ file $(realpath $(which mono))
/usr/bin/mono-sgen: ELF 64-bit LSB shared object, x86-64, version 1 (SYSV), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, for GNU/Linux 3.2.0, <snip long build id>
$ csc bitness.cs
Microsoft (R) Visual C# Compiler version <IP_ADDRESS>916 (2ad4aabc)
Copyright (C) Microsoft Corporation. All rights reserved.

$ mono bitness.exe
OS=X64 Process=X64 Env.Is64Os=True Env.Is64Proc=True
$ linux32 mono bitness.exe
OS=X64 Process=X64 Env.Is64Os=True Env.Is64Proc=True
$ rm bitness.exe

dotnet
$ file $(realpath $(which dotnet))
/usr/share/dotnet/dotnet: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, for GNU/Linux 2.6.32, <snip>
$ dotnet new console -o .
. . .
$ rm Program.cs
$ dotnet run --runtime linux-x86
OS=X64 Process=X64 Env.Is64Os=True Env.Is64Proc=True
$ linux32 dotnet run --runtime linux-x86
OS=X64 Process=X64 Env.Is64Os=True Env.Is64Proc=True
$ dotnet run --runtime linux-x64
OS=X64 Process=X64 Env.Is64Os=True Env.Is64Proc=True
$ linux32 dotnet run --runtime linux-x64
OS=X64 Process=X64 Env.Is64Os=True Env.Is64Proc=True

Not as simple as I thought it would be. Only uname is easily fooled. Sheesh.
Looks like I need to do that in a container. Likely tomorrow, need to do something now.

Ah, nailed it for mono! I did not even know it had this mkbundle tool!
$ mkbundle --fetch-target mono-5.18.0-debian-9-x86
$ mkbundle --cross mono-5.18.0-debian-9-x86 --deps bitness.exe
From: /home/kkm/.mono/targets/mono-5.18.0-debian-9-x86
Using runtime: /home/kkm/.mono/targets/mono-5.18.0-debian-9-x86/bin/mono
     Assembly: /home/kkm/work/mklver/bitness.exe
     Assembly: /home/kkm/.mono/targets/mono-5.18.0-debian-9-x86/lib/mono/4.5/mscorlib.dll
     Assembly: /home/kkm/.mono/targets/mono-5.18.0-debian-9-x86/lib/mono/4.5/I18N.West.dll
     Assembly: /home/kkm/.mono/targets/mono-5.18.0-debian-9-x86/lib/mono/4.5/I18N.dll
systemconfig: /home/kkm/.mono/targets/mono-5.18.0-debian-9-x86/etc/mono/config
machineconfig: /home/kkm/.mono/targets/mono-5.18.0-debian-9-x86/etc/mono/4.5/machine.config
Generated a.out
$ file a.out
a.out: ELF 32-bit LSB shared object, Intel 80386, version 1 (SYSV), dynamically linked, interpreter /lib/ld-linux.so.2, <snip>
$ ./a.out
OS=X64 Process=X86 Env.Is64Os=True Env.Is64Proc=False

and in the same binary in a 32-bit container
$ docker container ls -l
CONTAINER ID        IMAGE               COMMAND             CREATED             STATUS                          PORTS               NAMES
709202a16a9f        i386/debian:9       "bash"              2 minutes ago       Exited (0) About a minute ago                       optimistic_hugle
$ docker cp a.out optimistic_hugle:/root/bitness
$ docker commit optimistic_hugle kkm/mono32
$ docker run --rm -it kkm/mono32
root@e861bfe55d34:/# cd root
root@e861bfe55d34:~# ./bitness
OS=X64 Process=X86 Env.Is64Os=True Env.Is64Proc=False

Looks like we can trust System.Environment.Is64BitProcess. I have only a 64 bit runtime currently, but if mono does it, then I have no doubt that dotnet will.
optimistic_hugle, huh! Not a dictionary word, but sounds indeed optimistic :)

Fixed by #18467.


how to refresh

I looking for a way to refresh the slider, is it possible ?
Scenario: I updating the value o input by javascript but the JRange don't listem to this change

this will work for you,
https://github.com/nitinhayaran/jRange/issues/5
Also could you please send me a pull request by writing the same in documentation. A lot of people are getting the same issue.

Thank you Nitin Hayaran!! That was exactly what I was needing
Sorry, I don't know how to use Git Hub yet to send this pull request.